RobMiller Posted August 1, 2018 Share Posted August 1, 2018 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 Link to comment Share on other sites More sharing options...
support Posted August 1, 2018 Share Posted August 1, 2018 Hi Rob, Can you go to the auditing screen and have a look at what IP Address is being logged for the authentication attempt? Possibly it's the IP Address of your firewall or proxy - this is the only thing I can think of which would explain why this is not working. We'll also do some testing to see if the SAML Authentication option is interfering with this at all, and we'll let you know. Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted August 2, 2018 Author Share Posted August 2, 2018 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. Link to comment Share on other sites More sharing options...
support Posted August 3, 2018 Share Posted August 3, 2018 Hi Rob, We've just tested this with Build 8411, and cannot reproduce the issue you are seeing - we have the System Wide authentication option set to SAML, and then the Allowed IP Ranges set to Google Authenticator. If I come from an address outside of the allowed IP ranges, I get the Google Authenticator screen. Are these the only places you are setting the Athentication options - no User Account Policies, or personal Preferences? The Allowed IP Ranges feature should override these anyway? Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted August 13, 2018 Author Share Posted August 13, 2018 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: Link to comment Share on other sites More sharing options...
RobMiller Posted August 13, 2018 Author Share Posted August 13, 2018 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? Link to comment Share on other sites More sharing options...
RobMiller Posted August 13, 2018 Author Share Posted August 13, 2018 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. Link to comment Share on other sites More sharing options...
support Posted August 14, 2018 Share Posted August 14, 2018 Hi Rob, We're really sorry, as we didn't pick up initially that you are using forms-based authentication, and we were testing with AD Authentication. So we've been able to reproduce the same issue as you now, and have also fixed it for the next release. We'll post back here again when the new build is available, in about a week or two's time. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted August 24, 2018 Share Posted August 24, 2018 Hello Rob, Just letting you know this is now fixed as of build 8449 - released today. Thanks for reporting it to us Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted October 17, 2018 Author Share Posted October 17, 2018 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 Link to comment Share on other sites More sharing options...
support Posted October 18, 2018 Share Posted October 18, 2018 Hi Rob, If you close your Browser, and not just the tab, does that make any difference? Thanks Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted October 22, 2018 Author Share Posted October 22, 2018 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 Link to comment Share on other sites More sharing options...
support Posted October 22, 2018 Share Posted October 22, 2018 Hi Rob, I think the issue is your Step 5 above. I asked what happens if you close your browser, not close your tab. The only way to kill your sessions in IIS is to log out of Passwordstate, or close your browser altogether. Just closing the tab will not do this. Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted October 23, 2018 Author Share Posted October 23, 2018 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 Link to comment Share on other sites More sharing options...
RobMiller Posted October 23, 2018 Author Share Posted October 23, 2018 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. Link to comment Share on other sites More sharing options...
support Posted October 23, 2018 Share Posted October 23, 2018 Hi Rob, I do not believe this will work if all you're doing is closing the tab - sorry, but this is outside of our control unfortunately. It must be remembering so session variable, which is not being disposed of, as you are not logging out of Passwordstate. We'll take another look to see if there is something we can do about this, but at this stage we cannot guarantee it. Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted October 24, 2018 Author Share Posted October 24, 2018 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. Link to comment Share on other sites More sharing options...
support Posted October 24, 2018 Share Posted October 24, 2018 Hi Rob, Are you able to gain access to Passwordstate without some form of authentication i.e. SAML or Manual? We don't believe this is the case, so we do not agree with you that this is a glaring security hole - as it is currently, you need to be given access to Passwordstate, to your SAML provider, and to the Passwordstate "Application" in your SAML provider. As mentioned, we will look into this anyway, and hopefully find a solution for this very specific case. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted October 25, 2018 Share Posted October 25, 2018 Hi Rob, Just letting you know we've been able to fix this issue today, and it was caused by what we suspected of having some session variables live on the web server because sessions were not disposed of properly by simply closing the tab. We'll email you again when the new build is available with this fix in it. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted November 14, 2018 Share Posted November 14, 2018 Just a quick update to this - we are releasing a new build of Passwordstate today, build 8537, which addresses this issue. Thanks again Rob for bringing it to our attention. Regards, Support Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now