This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27689 - Is PBKDF2's generateKey() UI step worthwhile?
Summary: Is PBKDF2's generateKey() UI step worthwhile?
Status: RESOLVED MOVED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-24 02:39 UTC by Eric Roman
Modified: 2016-05-24 00:12 UTC (History)
3 users (show)

See Also:


Attachments

Description Eric Roman 2014-12-24 02:39:18 UTC
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
  <input type=password />
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.

Cheers.
Comment 1 Mark Watson 2016-05-24 00:12:42 UTC
Moved to https://github.com/w3c/webcrypto/issues/71