parrishk

+1

What are looking to achieve? Manage Kubernetes creds or run Passwordstate in Kubernetes?

Good morning all, @Ulf has a good point. Having the ability to set an initial password even if it is bad. This would prove useful during imports. Maybe even add an indicator making this bad password standout. Red text, red background, ticking time bomb..., etc. Yes, this may leave a little extra opportunity for people to ignore the warning and defeat the purpose of the HIBP API but if we can't do an import of pre-existing passwords we would have to turn HIBP off anyway... Anyway, this is an excellent feature. Thank you for taking the time to integrate it. We have it on and have no issues or "bad passwords", thus far! Thanks

+1

Good morning, We would be interested in a feature to allow an option for "Remember Me on This Computer for X Days" in regards to entering in a multi-factor authentication token. This is common for most services that allow MFA so that the user is not prompted for a token each time they log in. This can be tedious when logging into PasswordState numerous times a day. As a Security guy I can live with it, but I can see the benefit of it. Details: A new computer/browser will always prompt for MFA. Option to specify timeout (Hours, Minutes, Days, etc) before prompted again.

Good morning, We have a similar approach to Sarge. Regular backups are key. If the server were to go down we could have a fully functional replacement up in a very short amount of time. In a catastrophic failure (to the infrastructure) we have full copies of the database in an offsite location along with the "emergency password" if needed. Both of these should be separated.... Luckily, we haven't had to actually go through the process but it is in place if needed. Kyle

Hello Sarge, I would say the primary goal for this would be to reduce the risk of Cross-site Scripting (XSS) attacks on the site. This isn't really specific to Passwordstate but should be a best-practice for any web application/service. In the end, your are identifying "approved" sources for scripts, fonts, styles, etc that can run on your site. If something tries to run not whitelisted then it will prevent the script from running. These XSS attacks may originate from malicious browser extensions, users or other vulnerabilities within the site. Scott Helme has a great writeup on each of these headers if you want to read more into it. https://scotthelme.co.uk/hardening-your-http-response-headers/ I hope that helps!

Good afternoon, I recently implemented OWASP's HTTP Security Headers Best Practices on our Passwordstate install. This may be something you want to consider implementing out of the box to further increase the overall security of the platform when deployed. From what I can see, the following settings would work for most installs. Sure, there will need to be some tweaks for those that have additional requirements/integrations. Here is a link to OWASP's HTTP Security Header Best Practice: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Best_Practices Scott Helme's SecurityHeaders.com checker: https://securityheaders.com Here are the settings I found to work: Strict-Transport-Security: max-age=31536000 X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Referrer-Policy: strict-origin Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; img-src 'self'; connect-src 'self'; font-src 'self' fonts.gstatic.com fonts.googleapis.com; form-action 'self'; connect-src api.pwnedpasswords.com Feature-Policy: accelerometer 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; payment 'none'; usb 'none' The one thing that caused some flags was the "unsafe-inline" and "unsafe-eval" in the CSP policy. This is something that would have to be reworked on your end... I hope others find this useful as well. Kyle

Hey! I think there are two approaches here. You can look into Yubikey specifically and use their "Yubico OTP" feature which is supported by each of their devices. Or, you can look into the "FIDO U2F" which is beginning to be adopted by a wide range of vendors and platforms. Each of the Yubikeys support FIDO U2F. I am thinking this may be the better option because you will not be limiting it to just "Yubikey" and will have the process in place to accept any number of FIDO U2F devices in the future. https://www.yubico.com/solutions/fido-u2f/ https://fidoalliance.org/specifications/overview/

+1 for Yubikey support! Looks like support is available for Chrome, Opera, and Firefox (must manually be enabled by user) and plans for Windows 10 (Edge) coming.

Hmm...maybe temporarily disabled the "prevent bad passwords" options during the onboard process. Or is this a recurring process to the same list?

Thank you for sharing the path. This may be something we look into doing internally. However, after further review of HIBP V2 I did not realize that they implemented the K-Anonymity approach. This greatly reduced my concern with sending hashes to HIBP. Taking the first 5 characters of the hash, returning the matches and then comparing them locally was a great approach. Testing out the feature now! Thanks!

Since you already have the feature in place...what are the chances of allowing a "custom" API? Basically, thinking about the idea of creating our own internal REST API using the HIBP DB. We would then need to specify a custom url to check bad pw. Would that be something you could look into?

Good morning all, I think this feature is excellent! While looking into the self-hosted/downloaded version of the DB would require extra work and resources I think it is the best approach. Yes, the passwords/hashes are "Securely" sent up to HIBP it could still pose concern for some companies. Every password that we create is sent to the "cloud" to see if it is vulnerable??? This wouldn't be received very well from some people...even though there isn't much of a concern here. The database so far doesn't seem to be updated too frequently. The last published dump was in March. Overall, yes, we are all for this ability! Let us know if you need any more info, recommendations, etc. Thanks for all your work with PWState!

Hi, While I can agree that this "should not need to be done all that often" it seems that is the case here. Typically, this is because of people switching phones. That is why I think it would be beneficial to be able to use the API. Writing a custom Powershell function would allow us to simply specify the user needing reset without modifying the script each time. Just a thought but if it is not on the roadmap then I will just have to use the GUI :-) Thanks for getting back to me!