Don't require unlock to manage passkeys

[emlun]

This was originally necessary because we re-encrypted the key store to a session key on login and didn't keep the main key unwrapped in the session, therefore we needed to re-authenticate the user in order to unwrap the main key so it can be re-wrapped under the new PRF key.

Now we do keep the main key unwrapped in the session, so we no longer need to re-authenticate the user.

[emlun]

Note that this also removes the requirement to "unlock" before allowing to delete the account. Is that a problem?

[gkatrakazas]

That's a good question. It might be a good idea to keep this extra layer of security before allowing account deletion. Instead of having both an unlock/lock feature, we could simply require authentication (like unlocking) before proceeding to open the delete account popup.

[gkatrakazas]

Regarding best practices, should users be required to unlock their manage passkey section when they want to edit them?

[emlun]

It might be a good idea to keep this extra layer of security before allowing account deletion. Instead of having both an unlock/lock feature, we could simply require authentication (like unlocking) before proceeding to open the delete account popup.

Ok, I'll update the PR with something for that.

Regarding best practices, should users be required to unlock their manage passkey section when they want to edit them?

I've never seen this on any other site, it was just due to a technical limitation in the v1 and v2 encryption architecture that is no longer present in the v4 architecture. We need the mainKey in order to re-encrypt the wallet to the new passkey PRF key, and we didn't have mainKey cached in the session so we needed to re-authenticate in order to re-derive the mainKey. The v4 architecture eliminated the sessionKey and simply caches the mainKey instead (because after v3, the mainKey can be easily replaced), so now there's no longer any need to re-authenticate.

The closest thing I've seen is the "sudo mode" step-up authentication done before entering account settings on sites like GitHub, but that's more to do with its sessions being much longer-lived than anything particular about passkeys.