parrishk

While looking through the HTML source I noticed that each user's "HiddenGoogleSecretKey" is displayed in plain text. Sure the admin already has privileged access to the system and "could" change/reset this value but I think it would be best practice for only the end-user to ever have access to the secret value. Was this intended or is there not a concern for this value being visible to administrators?

This is great news! CSP is the most involved of the headers to implement because it "could" prevent parts of the site from functioning/loading. Best option is to set it to "report only" and begin to whitelist the resources as needed. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only. Once these are good you can remove the report only option. Thanks for the update! Kyle

Hello, I tried to see if this issue has already been brought up but did not find anything. It has been brought to my attention, the following scenario: A user browses a website, lets say "https://portal.office.com" where they have a password entry saved in their private password list. We also have a high number of shared passwords that have the same URL. When the user browses "https://portal.office.com" the auditing log shows that the user "retrieved password" for every password we have in the database using that URL. I feel that this process should be revised (assuming it has not been yet as we have yet to update to the latest version). There shouldn't be an audit entry stating that the password was retrieved unless it was actually pulled and used. Maybe pull a list of titles/usernames and audit that but not the actual password unless it is intended to be used by the end user. This fills up the auditing log and could cause for some confusion when a user is showing tons of password pulls when they did not intentionally do so. Has anyone else run into this? Thank you.

Jasper, I'm not sure if they will want to add an option to do this...but it could be handy for those that want to customize it. In the meantime, you can create your own barcode via the following format: otpauth://totp/Passwordstate?secret=XXXXXXXXXXXXXXXX&issuer=Passwordstate Just grab the secret from your authentication options page and run it through a QR generator. I made a simple PowerShell module to generate custom QR codes... https://github.com/arnydo/qrgenerator/blob/master/invoke-qrgenerator.ps1

Hey! I will do some testing but it was either the "issuer" or the "label" that was missing and some authenticator apps did not show "Passwordstate". Ill see which one it was and report back.

Hey Jasper. I brought this up quite a bit ago but didn't see any updates yet. It looks like they are not including the "Issuer" parameter when generating the QR codes. Some authenticator apps use this for the Title. Others just use the Label. I have been generating my own QR codes for a separate application and this works as expected. The URI should be similar to: otpauth://totp/Passwordstate:SmithJ?secret=JBSWY3DPEHPK3PXP&issuer=PasswordState https://github.com/google/google-authenticator/wiki/Key-Uri-Format

+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/