parrishk

Good day! I was recently configuring remote session launcher and was unable to due the Content Security Policy not allowing "psrsl://*" on the 'default-src'. Once I added this to the header it worked as expected. My question is, can you provide a list of default headers that are now included in Passwordstate and should psrsl://* be included by default?

+1 this would be an excellent feature.

Seeking thoughts on the idea of providing "recovery codes" for a user to use in the event that their MFA option does not work, is lost etc. Typically, a web service will allow the saving of a set of recovery codes (typically 5-10) that can be used once to gain access to their account.

Perfect. It was a little bit of a roundabout way to accomplish it but it works! Just tested and was able to get it working as desired. Thank you for the feedback.

That is close. This setting would work if we could set a policy to require MFA and provide the user the options they can chose. As long as MFA is used that is what my concern is.

Bumping this request again. I had thought this would have been a more popular feature request. Just to summarize... I think it would be beneficial to enforce MFA but leave the user the option to choose which form of second factor they use (Google Auth, Yubikey, etc). Is this an option already (that I have somehow missed) or can it be considered for implementation? Thank you.

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.go

Has anyone else found a need for this feature?

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

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

Hi! That is correct. The report does indeed return passwords that are bad. Thanks,

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,

Just sent over the logs. Thank you.

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.

Ulf, what about when running HIBP reports. Does that work? It does for us...just not the button next to the password field.