Jump to content


  • Content Count

  • Joined

  • Last visited

About RobMiller

  • Rank
    Advanced Member

Recent Profile Visitors

854 profile views
  1. You guys have a glaring security hole and I can’t even get you to understand it, much less care enough to fix it. I have tried very hard to explain the issue. I have made a video, showing how using an incognito Chrome session with no sessions variables saved, even with Okta showing that Okta has never been logged in with this browser, that a user can bypass your authentication subnet restrictions and login even without knowing their password to PWS. I guess I will have to open a support ticket as I’m not posting the video here.
  2. Let me rephrase the example above: Locate a computer in a disallowed subnet Reboot that computer, log in to Windows Open Chrome, sign into Okta but not PWS Click the PWS chiclet in Okta A 2nd tab is spawned for PWS, PWS correctly identifies you are off-site, doesn't log you in with SAML, prompts for forms based auth At this forms based authentication prompt, do not authenticate with your username and password, instead, simply close this tab. At this point, you are now on a computer, that has been rebooted, and you have never authenticated to PWS in this Windows session Now on tab 1, the Okta tab, click the PWS chiclet again, it will spawn tab 2 with PWS again, but this time, instead of PWS prompting you again for forms based auth, as it should since you did not authenticate in the previous step, PWS will log you in with SAML, even though it's not supposed to. I could reset the PWS password of a user, not tell it to them, then have them start at step 1 above, and they will still be able to access PWS from an off-site desktop computer.
  3. You are realizing that no one is ever authenticating in the above example correct? Why close the browser if I never authenticated to PWS? I understand that would matter if I previously authenticated, but that is not the case here. Users right now, off-site, in a disallowed subnet, can completely bypass the authentication requirements of PWS while never authenticating even once using the assigned auth. I'm sorry but I can't help but feel you are not understanding the situation. Closing a tab instead of a browser should only matter if I somehow authenticated in that browser previously. The users are never authenticating, they don't even need to know their password. They could not know the pass, be using a brand new out of the box PC, log in to Windows for the very first time, all while in a PWS restricted subnet, and still authenticate via the default auth mechanism by closing a tab instead of authing normally. Would it help if I made a video of this behavior? I could do that. Rob
  4. Nope. Steps to reproduce using Chrome: 1. Close all instances of Chrome, starting fresh 2. Open Chrome, sign into Okta 3. Click the PWS chiclet 4. A 2nd tab is spawned for PWS, PWS correctly identifies you are off-site, doesn't log you in with SAML, prompts for forms based auth 5. At this forms based authentication prompt, do not authenticate, instead, simply close this tab 6. On tab 1, the previous Okta tab, click the PWS chiclet again, it will spawn tab 2 again, but this time, instead of prompting you again for forms based auth as it should since you did not authenticate in previous step, it will log you in with SAML, even though it's not supposed to So you see, even using a fresh browser with all instances closed, and never authenticating with forms based auth while being at an off-site location, it will allow you to use default auth on the 2nd attempt. Definitely looks and acts like a bug. So as of now, I still can't force off-site users to auth a different way, as they can simply bypass it by closing the first tab, and clicking it again. Rob
  5. Thank you. I'm on 8501 now. It does work, but there appears to be a security glitch. I only have a single public IP on the allowed list now. If I use SAML from another IP, Passwordstate correctly ignores it and presents me with forms based auth. However, if you simply close that browser tab, and try SAML again, the next time it opens up it will auth you via SAML. One of my staff brought this up. It's only presenting the alternative auth once, then if you try the default auth, it will let you use it the second time. We've tested this repeatedly. Thanks, Rob
  6. If I set the Authentication Option for outside the range to "Deny Access Altogether", then it does work and block me. So it is 100% detecting that I am coming from an outside IP and following that alternative action. However as soon as I turn it back to Forms + Google Auth, even from an old browser like IE, with no Okta plug-ins installed, and set to an in-private browsing window, going to my Passwordstate URL still results in it prompting me to login to Okta. It simply forwards to our Okta URL prompting me to login to Okta to access Passwordstate. So since this happens on systems with no plug-ins (even my phone), it's definitely Passwordstate that is forwarding that to Okta, instead of failing over to Forms and Google. Since Passwordstate does in fact block the same IP when set to block, that tells me that the problem definitely resides in Passwordstate somewhere.
  7. Well, I upgraded to 8411. No change at all. No matter what I do, it uses SAML for authentication. Not sure where to go from here. Should I open a support ticket?
  8. I don't know. I can't ever get it to do anything but SAML. I have no User Account Policies, and no personal preferences. I will try to update to 8411 shortly to see if that is it. Here are my relevant settings:
  9. I even dropped it down to a single public IP address that is allowed, it still does it, even when I look at the auditing and can confirm logins are coming from another IP that is not listed. It seems to be something with SAML. Perhaps there is a bug where if you are using SAML as the default, it can't use anything else. It definitely doesn't work.
  10. V8.3 (Build 8361) Currently we are only using SAML2 with Okta. Everything works fine. Our Web Site Allowed IP Ranges under System Settings was blank allowing login from anywhere. I need to open this up so different accounts can use different authentication types. I added a subnet to 'Web Site Allowed IP Ranges' and then changed the auth for items outside this subnet to Forms and Google Auth. If the Passwordstate web site is accessed outside of one of the IP Ranges listed above, force the user to authenticate using the following method: Authentication Option: Forms and Google Authenticator My issue is that no matter what, Passwordstate attempts to use Okta to login. Even though I am logging in from an IP not in the list, it still uses the default authentication method which is SAML. It doesn't drop back to Forms like it's supposed to. I've rebooted the server to no avail. How do I make this work? Thanks, Rob
  11. Edited~~ Actually I should probably just make a new post in the version 8 section. I will do so now.
  12. I'm not talking about the self destruct feature. Talking about the MSP features allowing customer login to view passwords assigned to their site.
  13. If we are currently authing via SAML, is it possible to set customers with a standard login? Is it possible to set them up to require 2FA via Google Auth or whatever?
  14. Actually it does look like this is there now. I need to check this out.
  15. We can wait, I have a good workaround. If you do make a cloud based version, I really hope you keep feature parity with the self-hosted option! We won't store our password data in a public cloud. Only our own. I'd hate to see the self-hosted option moved down in priority. Thanks! Rob
  • Create New...