Sahbi

I think it could be useful to be able to manually add a password through the browser extension, most likely simply bound to the current domain/URL. Example case: you're currently on a site and the extension didn't auto-prompt for saving a new password, because it didn't detect a successful login. This most usually seems to happen on sites that handle the login completely via AJAX. I think it's because the extension looks for the HTTP 200 response code for the page's top frame, but AJAX logins usually cause a redirect (3xx code, which might get detected) or possibly directly change window.location. Trying to account for all of these edge cases will most likely result in way too many prompts for things that weren't actual logins, so simply being able to add an entry manually once in a while seems perfectly acceptable. On your next visit to the site it should still be able to autofill the password since the website's domain/URL still matches what is set on the entry. Other cases include sites with basic authentication prompts. I realise the extension won't be able to autofill such a password since there's no HTML to interact with, but at least the password can be stored in Passwordstate for safekeeping. Plus (at least on my Firefox), I can interact with the extension's search function to retrieve the stored password without problems (i.e. the login popup doesn't get dismissed).

To make the app server work you have to pin its certificate through the main Passwordstate service, which currently seems to use the certificate itself. I'm using Let's Encrypt for my certificates, so that means every few months I have to clear the pin, re-query for the new cert and tell all users to re-pair their apps. And even if you use "real" certs that have a validity period of a couple years, once that expires you'll have exactly the same problem. I propose that instead of generating some form of hash of the certificate, Passwordstate should use the SPKI fingerprint instead. As far as I know this is dependent on the private key, so as long as that doesn't change the output will be the same. This is how HTTP Public Key Pinning works as well, as to not to break all clients that have already cached the previous pin when the cert rotates. Many Let's Encrypt clients (or ACME in general) can be told to reuse an existing private key.

Well I was thinking along these lines: Admin sets a policy for "any MFA required". This could either be literally any, or a list of allowed methods like Josh-Hemphill said. The latter is probably preferred by most though. Admin changes the system authentication settings to hide undesired methods. I'm not 100% sure if you can hide the default forms based auth, but a new account would use this initially regardless. The first logon would always be without MFA because A) I don't think *all* MFA methods can be pre-supplied, so you can't really require MFA at this point and B) Passwordstate doesn't even know their preference yet. After logging in Passwordstate can just set a flag in the account "like initial logon completed". Admin creates an account, supplies password to the user. User logs in. They should now go to their account settings and set up their preferred MFA method and set it as default. This default method should probably be a required field instead of being able to leave it on "inherit system setting" (nor forms auth), that's the entire point of being able to require "any" method (we don't *know* everyone's preferences, hence the system setting will not work for some). On the next logon Passwordstate will simply check their preference and direct them to the according screen. Alternatively, at step 5 you could automatically redirect them to their account settings and display a message like "MFA is required by company policy, set it up now". Maybe you could even prevent them from leaving there until they set up at least 1 method and change their default preference. Admins should have a way to let them recover their account if they forget to set up MFA though, perhaps a checkbox in the admin user settings like "redo initial setup on next logon". Then it will just restart at step 4. That would still leave the choice up to the user though, so you can't really rely on that. What I mean is, as long as you can't enforce "any" MFA the user might just leave it as-is because it's more convenient. You do require user action at *some* point though, I don't see any way to prevent that. Just have to make it very clear to them to set up MFA when supplying the account, otherwise they won't be able to log in a second time. Another benefit of being able to require "any" method is that you could use e.g. TOTP as fallback when your primary method temporarily isn't available, because with the current account policies you can only specify 1 method if I'm not mistaken. Of course this would require modifying the login process some more, since you'd need to be able to "cancel" the current method and use a different one. Of course this would be just an addition, it's not the core of the problem.

Currently the User Account Policies only allow you to enforce one specific method for 2-factor authentication, such as Duo or TOTP. This means that you'd have to keep track of every individual user and their preferred method, then create separate policies for every "group". This is quite a hassle, so perhaps a better option would be to enforce using any method. The dropdown list could simply include something along the lines of "anything besides Ignore". For the very first logon, Passwordstate can simply use the global default setting (e.g. TOTP), or if the admin has overridden it in some way then use that method instead. Afterwards the user can simply change it to something else, as long as it's not "Only Forms Based".