Jump to content

parrishk

Members
  • Content Count

    74
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by parrishk

  1. Good morning, It seems that the "Confirm Have I Been Pwned Status" button is not successfully hitting the API (image below). This is allowing weak/compromised passwords to be saved... I do not believe it is an API rate limit issue as I am able to run a report on compromised passwords fine, I just can't use the button on the password page. Any tips on troubleshooting? I have checked the error console but nothing is listed there. Thank you!
  2. Ha! Found the culprit. It looks like there were two "Connect-Src" declared in the Content-Security-Policy header...not sure if this was on your end or my end as I already had some CSP headers in place before Passwordstate began implementing them. Removed the second (CSP will only look at the first declared and ignore any additional) and all is good. Was: 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 Changed to: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; img-src 'self'; connect-src 'self' api.pwnedpasswords.com; font-src 'self' fonts.gstatic.com fonts.googleapis.com; form-action 'self'; connect-src api.pwnedpasswords.com
  3. Hello, I was not sure how to describe this request in the title... Basically, looking for the feature to require two-factor authentication for all users but give the user the choice on which second factor they use. For example, a user must use AD Authentication and one of the allowed second factor options (Google Auth, Yubikey, etc). Possibly even have the option to support two second factor options. Google Auth and Yubickey (with only one being required at the time of authentication). Does this make sense? Thanks,
  4. parrishk

    More Authentication Options

    Has anyone else found a need for this feature?
  5. parrishk

    haveibeenpwned report

    Oh gotchya. Yeah I can see that being a benefit when the password DB gets that large...
  6. parrishk

    haveibeenpwned report

    Hi @Azkabahn You do have the option to run the report on a per-list basis. Have you tried running it against individual password lists? - Kyle
  7. Hi! That is correct. The report does indeed return passwords that are bad. Thanks,
  8. Hello! Does the HIBP report on the screen Administration -> Reports return records for the report, is does it return no records? This DOES work. I am able to return reports globally and per password list Are you using any reverse proxies or load balancers We DO use a reverse proxy to access the server from the outside. Thank you.
  9. Ulf, what about when running HIBP reports. Does that work? It does for us...just not the button next to the password field.
  10. Hello, Thank you for your response. Answers to your questions follow: What Build of Passwordstate are you using 8679 What Browser Type are you using Firefox Chrome Brave Internet Explorer Is your Passwordstate-Gateway Windows Service started Yes What sort of certificate did you export to use with the Gateway - is it a trusted certificate, or is it a self-Signed certificate Publicly trusted certificate from GoDaddy With the URL you're using for Passwordstate, is the DNS entry for this from internal DNS, or external? If external, you may need to open access on your firewall to get to the Gateway's default port which is 7273 Internal address is resolvable. Same as primary Passwordstate URL. If you go to the screen Administration -> Remote Session Management and click on the 'Browser Based Gateway Settings' button, if there is a URL specified in the 'Gateway URL' field, please clear this, Save the change, and then test again This is cleared. From your Passwordstate web server, do you have network connectivity to the Host? You can run the following PowerShell command to determine this (change host name and port as appropriate) - test-netconnection hostname.domain.com -port 3389 Test succeeded. Also tested port 7273 with success. Do you have any firewalls enabled on your Passwordstate web server? If so, you may need to allow access on Port 7273 For the time being, firewall is not on. Thank you.
  11. Hello, Build is 8679. So far, this has occured every time since we updated to the version that supports this feature. I can run a report within Passwordstate to check against the API and that works fine. I can also query the API directly (outside of Passwordstate) without issue. Thank you.
  12. Hello, Seeking advise on what I am trying to accomplish. Thankful for the recent addition of HIBP and the value it provides moving forward but I am looking at: Running a report to list all accounts that have a "bad" password and is already stored in the DB Searching all accounts by password. For example, if we found out that Password123 is "weak"...how do I search for all accounts with the password "Password123" so they can be addressed? Thanks!
  13. Hello, I have walked through each of the troubleshooting steps. Nothing mentioned above has resolved the issue. Certificate is loaded, service is running, port is listening, etc. When attempting to launch a session from multiple different browsers and are displayed with "Please wait while connecting..." indefinitely. What is the next step to troubleshoot? Thank you!
  14. parrishk

    Search for Compromised Passwords

    Thanks! This works perfectly.
  15. 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?
  16. 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
  17. parrishk

    HTTP Security Headers

    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
  18. 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.
  19. parrishk

    Title in Google Authenticator

    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=Password´╗┐state 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
  20. parrishk

    Title in Google Authenticator

    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.
  21. parrishk

    Title in Google Authenticator

    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
  22. parrishk

    kubernetes

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

    Have I Been Pwned? Integration

    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
×