Bug 27689 - Is PBKDF2's generateKey() UI step worthwhile?

[mwatson2]

Bug 27689:

I am interested to hear how other implementors have tackled PBKDF2's generateKey().

I haven't thought it though in detail, but I have concerns on whether the UI step in PBKDF2 generateKey() step is actually worth the implementation complexity.

A web application could easily build its own UI to prompt the user for a password (with HTML/CSS/Javascript), and then importKey() + deriveKey() for doing PBKDF2.

The rationale then behind using generateKey() is to allow the user to instead enter their password in a trusted, User Agent provided UI. In this manner the JavaScript does not have direct access to the user's password's bytes. And moreover the generated key is unextractable.

My concern with this generateKey() approach is:

(1) An evil script intent on getting the user's password can still do so handily by deriving bits. Since the PRF and salt used by PBKDF2 are under their control, a pre-generated table of passwords and their accompanying PBKDF2 output makes this a very simple search problem.

(2) In order for generateKey()'s UI to provide a security benefit, users must be trained to recognize the UI as trusted, and ONLY enter passwords in this UI. It is hard enough getting users to recognize the HTTPS lock icon, I am doubtful we can get them to apply yet another such scheme. This reminds me of HTTP authentication which prompts dialogs at random times, and around which there is not much user understanding. An evil page could just as easily create their own prompt for a password and users likely wouldn't be the wiser.

As far as the implementation goes, some practical considerations are:

(a) What is the expectation around WebWorkers? As specced, WebWorkers can call crypto.subtle.generateKey(). Seems like an anti-pattern for WebWorkers to be able to trigger UI (although perhaps this is already possible with XHR and HTTP auth?)

(b) Should the UI block the script's execution? (Either main thread or web worker thread). If no, then some additional teardown complexities are needed to make sure the dialog is dismissed when the page is navigated away from. If yes then WebWorkers could block the main page.

(c) What WebCrypto error should be thrown on cancellation (if the user dismisses the dialog). Presumably an OperationError.

(d) Mechanism to prevent abuse in popping such UI repeatedly, otherwise we have yet another "alert()" style annoyance.

(e) If there are iframes, any one of them could be popping the password UI. Need to attribute which one prompted the dialog.

For these reasons I think the user experience would be better served by having web-applications provide the UIs to request the password themselves, and let it work with password auto-fill, browser extensions, accessibility support etc all in the normal manner.

If protecting the password bytes from the running script remains a concern, perhaps there is a solution to be had using standard HTML elements like

If a mechanism were added to make its value unreadable by scripts, and yet transferable to importKey(), and also signalled as trusted by the browser, then, yeah.

Maybe that is crazy talk.
Maybe everything I wrote is crazy talk.

[mwatson2]

PBKDF2 generateKey is agreed to be removed (see #23).