[Bug 27689] New: Is PBKDF2's generateKey() UI step worthwhile?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27689

            Bug ID: 27689
           Summary: Is PBKDF2's generateKey() UI step worthwhile?
           Product: Web Cryptography
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: ericroman@google.com
                CC: public-webcrypto@w3.org

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 24 December 2014 02:39:20 UTC