Jump to content

RobMiller

Members
  • Content Count

    40
  • Joined

  • Last visited

Everything posted by RobMiller

  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
  16. Thanks! I finally got around to updating and yes indeed the email now uses the template properly. However the logo on the self destruct site did revert to the Password state logo and is still not using the proper branding. I had to again rectify this by copying our logo to C:\inetpub\Passwordstate\selfdestruct\images\logos.
  17. Sorry, I missed that 2nd reply. We are using the latest build. 7789. If we change the subject in the email template category " Self Destruct Message Email " then hit save, then hit "test e-mail" at the bottom, the test email comes through perfectly with our custom subject which is simply "Gwanda - Self Destruct Message". However after that, when you actually send a real password to someone, those emails default to the original subject "Passwordstate - Self Destruct Message". Sure a user can change it manually each time, and that works. But it doesn't accept our new default. Since it doesn't accept our new default, there is currently zero reason to customize that field in the email template. It doesn't do anything except for the "Test Email" button.
  18. Ok well I was able to fix the logo by just going to C:\inetpub\Passwordstate\selfdestruct\images\logos and renaming that logo as .old and putting ours there with the same name as the original logo. That fixed my logo issue and now we have our logo everywhere. If only we could get that subject line to work. I tell everyone to change it but you know.....
  19. Any update on this? Just noticed we the same issue. The subject is always "Passwordstate Self Destruct Message" even though we've changed it. Oddly, the test email properly uses our subject, but the actual real test of sending a password reverts to the old subject.
  20. I'll be honest I skimmed the emails from them. I received one yesterday: Okta’s service provides our customers with a secure environment that adheres to security industry leading practices. Okta has identified several Okta Application Network (OAN) applications which leverage SHA1 Digital Signature Algorithm and Digest Algorithms as part of the assertion. SHA1 is scheduled for deprecation by most major browser vendors later this year with SHA256 as the new standard. Okta will be converting these OAN, SAML applications to SHA256-based algorithms over the course of the next few months. This change only impacts the Digital Signature Algorithm and Digest Algorithms embedded within the SAML assertion. The certificate associated with an Okta tenant and shared with SAML service providers will not change as a function of this application change. Your organization has been identified as using one or more of impacted SAML applications and we are contacting you to alert you to the upcoming application upgrade. I keyed in on the last line, then I checked our PWS app and saw it was SHA1 which caused me to panic a bit. Perhaps we do have some more time? It sounds now like maybe they are converting their own app definitions and not simply killing all SHA1 apps. As long as you guys are aware that SHA1 is being deprecated soon and work to update it with SHA256 we should be ok I guess.
  21. SHA-1 is currently the only option for SAML with PasswordState. We have been told by our Auth Provider Okta that SHA-1 is being deprecated and we need to migrate to SHA-256 and they are discontinuing support for SHA-1 shortly. This is of huge concern as none of our techs will be able to access PasswordState once this goes into effect. When will PasswordState support SHA-256 instead of SHA-1? Thanks, Rob
  22. Any suggestions for best practices for this? It seems there is no built-in method to do this. We also use SAML for authenitcation. Ideally there would be a way where we could set a free view-only account that would be locked down that clients folder. The account would simply be a local account, with 2FA Google Auth available. Any ideas where to start? Is this functionality on the roadmap?
  23. I just want to say again how awesome support is for PWS. So quick even outside of their support hours! I'm all set. I don't know what went wrong initially but ultimately my main problem was that using SAML, I'm not used to seeing the FBA screen. I didn't even realize my account still had a password as with some SAML solutions, once you enable it the accounts no longer have passes. So I thought the upgrade was finished and it just dumped me back to an FBA screen making me think it was broke. I just had to set a password on my account that I knew in advance, then login with FBA to let it finish the upgrade, then SAML login worked again. Hope this helps someone else who uses SAML and ends up in a panic like I did. This was my first upgrade after switching to SAML a couple months back.
  24. I should have slowed down. Nothing was stopping me from maint mode. While I have no idea what happened, I'm back up and running and will try again tomorrow. I just panicked when I couldn't login at all, even with /emergency.
  25. Well I've gone ahead and reverted to a snapshot because I don't feel like dealing with this right now. Maybe someone can chime in with what they think went wrong so I can have a better go at it next time.
×
×
  • Create New...