@Damariobros For best results, I think it may be best to change the title & focus of this feature request topic (or if necessary, start fresh with a new topic). Let’s revisit this part of our conversation:
And this:
Basically, I think that the best strategy would be to specifically request additional flexibility in the way that web vault protected actions are safeguarded when a user has logged in to the Web Vault using a PRF-capable passkey (i.e., with encryption enabled). You could use this for “recovery” purposes (if your master password is lost), but such a framework could also be used just for convenience. Thus, in my opinion, it may be distracting (or even counterproductive) to focus on the use-case of vault recovery.
My suggestion would be to change the feature request topic title to something like:
“Options for authorizing exports (and account/security changes) without master password, when logged in using passkey with encryption (PRF)”
I can make this change if you wish, or you may prefer to start a new feature request topic with a title closer to what I have suggested above.
Uhh, I seem to not be allowed to edit the title anymore. I don’t see an edit button. I think I’m time limited on edits to my own posts. You’ll have to put the edit in for me.
Change it to “Options to allow PRF Passkeys to authorize actions and account/security changes protected by Master Password”
Why would the passkey used to authorize those protected actions have to be a PRF one?
It wouldn’t have to be, no. Protected user actions, whether protected with password or (for users without passwords) OTP, are a form of authentication. Thus, even passkeys that do not support encryption, or PRF capable passkeys on non-PRF capable platforms, could be used to authenticate the user to perform sensitive actions.
… but not a master password change, right? (since that would change the encryption of the vault) (Edit: I was wrong – see this post by @Quexten )
I guess the idea was 1) that a PRF-login-passkey would be equivalent to having the master password and 2) that, as I wrote before, I think only a PRF-passkey would also make it possible to initiate a master password change (or I’m wrong about that) - and if I’m not wrong about that second point, then that was a part of the initial request by @Damariobros, to have some kind of “account recoverability”, if the master password would be lost. (PS: Seems I was wrong - thanks to @Quexten for his explanation!)
But good question - and as @Micah_Edelblut already stated, probably for most things, a non-PRF passkey would be enough… though I hope, that wouldn’t give a false sense of security then, if one had a non-PRF passkey, and would think that would be enough to also change a “lost” master password, only to find out then, it isn’t enough … (PS: I just remembered: without the master password, you couldn’t even log in with a non-PRF passkey in the first place, so that should already be a “hint”… )
You don’t need a PRF credential to perform a masterpassword change. The client already has the account symmetric key (“userkey”) loaded in memory. A password change without key rotation merely replaces stretchedMasterKey(UserKey) with strechedMasterKeyNew(UserKey), and updates the authentication hash. Both can be derived from the new masterpassword alone. Even a password change with key rotation does not need a PRF-login-passkey; it’s a bit more complicated here, but all required keys are already in memory when you have an unlocked vault.
The only thing that the old masterpassword is used for, is as an authentication factor for protecting sensitive account actions. It is not required in the cryptographic changes happening during a password change or key rotation. As micah points out, this can be replaced with email otp, or (any) passkey.
@kpiris@Quexten@Micah_Edelblut The Feature Request was worded (after some discussion) to mention the PRF capable passkeys, because to my understanding, without such a passkey, it would not be possible to log in to the account to perform any of the master password protected actions (exporting, security changes, etc.) to begin with.
The idea was that after a successful initial login, the user should have options to choose alternatives to the master password for authorizing the protected actions. One such alternative could be a non-PRF passkey.
I guess I don’t understand how the account symmetric key would get loaded into memory if the user did not log in to the Web Vault using an encryption-capable passkey. If I have misunderstood the technical constraints, please clarify — in which case I will be happy to modify the title and scope of this feature request.
Edit: Perhaps the assumption is being made that the user is already logged in by one method or another, and then wishes to authorize various protected actions using one of the alternative authorization methods (non-PRF passkey, biometrics, pins/codes, etc.) — in which case the original login method is irrelevant? If this is the case (i.e., if all protected actions that currently require verification by master password entry could in principle be performed using alternative authorization methods — or even with no additional verification!), then it does make sense to omit the reference to PRF passkeys in the topic title & description.
My message above assumes that you have a logged in and unlocked vault. If you are logged out, you need any means, prf, login-with-device, trusted-device-encryption or master password to log-in and unlock. Once in the unlocked state, my above claim applies.
So yes, if you are fully logged out, a passkey without PRF would not be enough to get into an logged in and unlocked state.
I feel that in this case, removing PRF from the title is warranted; the request is "from an unlocked state, I can use a passkey (PRF or not) to authorize setting a new password. Login-with-prf in the web vault is already supported.
Thank you for clarifying. I will modify the topic title, but before I do so, it would help to have your perspective on the following, as a developer:
I can define this feature request either as a broad proposal to allow multiple verification options (passkey, biometrics, OTPs, fixed codes/passwords, or even a simple Yes/No affirmation) to authorize the protected actions (in a vault that is already logged in and unlocked), or I can limit the feature request scope to only include passkey authorization as an alternative to master password entry for protected actions.
In your opinion, would there be any significant differences in the feasibility of implementing the proposal, depending on whether the alternative verification method consists of passkey authorization or something else)? Basically, I want to frame the feature request in such a way to improve both its appeal to the user community, and its chances of getting implemented.
There might be a middle ground, consisting of “all the existing login and unlock options”. The advantage being that these bits already exist in the code base and therefore have the possibility of reuse.
Also worth considering if this would dovetail into reenabling UV for “use a passkey in the vault to login to somewhere else”, which was disabled at least in part because having the master password as the only option was too burdensome.
Just worth mentioning as you are crafting the feature request, we likely would not implement all unlock options for verification, since some (PIN and biometric) are done locally and aren’t really re-authenticating you in any way (to the server).
It certainly makes sense to me that biometrics would not work for server-based activities, such as master password change, but seems like it could be an option for local activities, such as export from the desktop app. … noting that this is tagged “app:all”, not “app:web-vault”
Regarding PIN and biometrics, I think there are already two other feature requests for replacing some master password (re-prompt) actions with PIN/biometrics:
(BTW, I’m not sure, those two feature requests are that much different… (apart from the second one also mentioning PINs))
PS: … and I meant by that: it’s probably still best, to focus on “passkeys” for this feature request – also to avoid (further) “duplicates” with the other existing feature requests.
Does the master password entry (say when exporting the vault) actually re-authenticate you to the server? I thought that this was just a UI guardrail, like the master password reprompt for protecting individual vault items.
Or are there two classes of master password protected actions — some that are only a UI-level check, and others that require re-authentication to the server? If so, which actions require re-authentication?
This request is confusing. After a first read-though, it seems it is an ancient feature request thread asking for biometric unlock, which was implemented in 2020–2021. I don’t know why the thread is still open.
This is primarily a local operation, but falls back to validating with the server when there is no masterpasswordhash stored locally to compare the input with.
And, I guess, anticipating some follow up questions. It’s not to say we couldn’t use PIN or biometrics for verification of sensitive actions, but it might not be considered best practice since these are not authentication methods.
… (PS: I just remembered: without the master password, you couldn’t even log in with a non-PRF passkey in the first place, so that should already be a “hint”…