2067167 - LoginHelper.requestReauth() locks the key token out from under concurrent logins-store work

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[Florian Quèze [:florian]]

LoginHelper.requestReauth() (toolkit/components/passwordmgr/LoginHelper.sys.mjs:1633) re-authenticates by locking the internal key token and unlocking it again: await token.logout(), then await token.login() to prompt. Nothing can decrypt in between. With the Rust logins backend (default since bug 2053724), every store operation already in flight then needs the primary password, and the store's own authenticator would open a second modal prompt on top of the one NSS is showing.

Bug 2056050 stopped that second prompt by having the authenticator decline while a re-auth is in progress, but the racing store operation still fails, which is why that bug cannot close. browser/components/aboutlogins/tests/browser/browser_osAuthDialog.js still fails password revealed after PrP auth, password hidden again and reveal checkbox should be checked after PrP auth -- the reveal cannot complete while the store cannot decrypt -- plus an uncaught rejection out of AboutLoginsInternal.observe() -> #reloadAllLogins() -> sendAllLoginRelatedObjects(), none of which catch. For a user, a store write racing the re-auth is refused.

Re-authentication should not lock the token out from under concurrent work. Two shapes:

1. Verify instead of relock: re-auth means "prove you still know the primary password", not "lock the token and unlock it again". nsIPKCS11Token has no verify-only primitive today (login, logout, changePassword, reset, isLoggedIn, hasPassword), so this needs a new one, e.g. Promise verifyPassword().
2. Route requestReauth() through RustLoginStorageAuthenticator.getPrimaryPassword, which already exists to obtain the primary password when the Rust backend is active: one prompt, one owner, no locked window.

Either removes the need for the decline added in bug 2056050.

Comment 1

[Johannes [:joschmidt]]

Could this be related to https://bugzilla.mozilla.org/show_bug.cgi?id=2067678? I wonder if we could fix this on the Rust side

Comment 2

[Florian Quèze [:florian]]

(In reply to Johannes [:joschmidt] from comment #1)

Could this be related to https://bugzilla.mozilla.org/show_bug.cgi?id=2067678? I wonder if we could fix this on the Rust side

I don't know. This bug's description was written by Claude as part of investigating bug 2056050. It seemed reasonable enough that I submitted it, but I don't know myself anything more than what's written here, sorry.