W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

RE: PBKDF2 questions

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Wed, 5 Mar 2014 23:12:12 +0000
To: Ryan Sleevi <sleevi@google.com>, Mark Watson <watsonm@netflix.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <acc3a3e78a074172a4cbb9b05dfbd781@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
+1 to Ryan. I agree that the UI issue is hard, and that very often sites will choose not to go that route if they want things like strong branding.

Regarding this question:

- do we need to place any requirements on the deriveKey parameters that the site can use to avoid it being easy to work backwards from derived keys to the password ?

Are you essentially asking for a minimum iteration count? I don’t see any other parameters that you can use to weaken the one-way nature of PBKDF2 short of picking horribly broken hashes.

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Wednesday, March 5, 2014 2:07 PM
To: Mark Watson
Cc: Vijay Bharadwaj; public-webcrypto@w3.org
Subject: Re: PBKDF2 questions



On Wed, Mar 5, 2014 at 2:01 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:


On Wed, Mar 5, 2014 at 1:46 PM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:


On Wed, Mar 5, 2014 at 12:43 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
I have another question about PBKDF2.

We have decided that generateKey will explicitly ask the user for a password. The advantage is that the UA can implement a non-spoofable UI and the user will have the advantage that the site will never see the clear password, only the derived key (for this reason, I required that extractable be false when generateKey is called here).

There are two issues (neither of which should block last call):
- do we need to place any requirements on the deriveKey parameters that the site can use to avoid it being easy to work backwards from derived keys to the password ?

No. The site is choosing it's own security parameters. The UA is making no statement about them, merely facilitating the 'hands off approach'

- it seems it is non-trivial for UAs to implement this in such a way that the UX will be one that sites will choose to use. A plain dialog saying "www.blah.com<http://www.blah.com> wants you to enter a password" is not very user-friendly. Sites will generally want to provide some prompt explaining what the password is for and also often sites want to place restrictions on password strength (minimum length, contains upper and lower case etc.). If the UA's native dialog doesn't have these properties, sites will likely choose to prompt for the password the old-fashioned way, to the user's detriment. Do we need to consider whether the site should provide prompt text, a strength test callback etc.

No. If a site wants to trade deniability for usability, it can.

The generateKey is not at all about improving security for users, per se. Sites can still misbehave. It's a way for sites or applications that want to be able to state "I didn't have the key" to be able to state so.

In which case, it better be difficult for them to obtain the password. If a site could trivially obtain the password, it's hard for them to credibly say "I didn't have the password" - or at least, that promise is no more reliable than if they did have the password in JS and claimed "I didn't send the password to the server" - you're just trusting them to be truthful.

Correct. You MUST rely on the site who gave you the code to execute to be truthful and honest. This is fundamental to the Web Crypto API.

This is NOT about providing an API that prevents sites from being dishonest. I'd rather tilt at windmills than try to do that.

This IS about providing an API that allows sites to say "I didn't ask for it" - and for people to audit the truthiness and security of that. And to reduce _their_ exposure to the secret.

That is, if I'm auditing code, and I see it call the API in a secure manner, I know I don't have to worry. This is _not_ about providing the user any assurances - we can't.


We want a site to be able to say "I can prove that I didn't have the password, because you can see that I used a UA method that the UA guarantees keeps the password from me.". So, then, the UA better be sure the site can't get the password by specifying weak parameters (weak hash, 1 iteration, specially chosen salt etc.)

I do not believe this is a valid or achievable use case.

If it was, we wouldn't be using PBKDF#2.


Equally, if we want this function to be attractive to sites, it had better be capable of offering a good UX or else noone will use it.

...Mark




...Mark



On Wed, Mar 5, 2014 at 11:52 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
Ok, I will specify with HMAC for the moment. SP 800-132 has a normative minimum output length of 112 bits, which the RFC does not have. Do we want that ?

...Mark

On Wed, Mar 5, 2014 at 10:01 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
I doubt anyone uses PBKDF2 with something other than HMAC. In fact SP 800-132 explicitly limits it to HMAC. So if you incorporate that limitation then maybe SP 800-132 is a better reference.

From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Wednesday, March 5, 2014 9:54 AM
To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: PBKDF2 questions

(1) I assume the correct reference is RFC2898
(2) Do we need to support PBKDF2 with pseudo-random functions other than HMAC ? Presently the parameters dictionary allows us to specify the pseudo-random function, prf, in contrast to HKDF where we are allowed only to specify the hash function to be used with HMAC

Restricting to HMAC is much simpler to specify. If we allow arbitrary PRFs, we need to define what properties they must have: support of sign operation and import of arbitrary size raw key. These requirements restrict us to HMAC anyway (from the existing algorithms).

Does anyone use PBKDF with a PRF other than HMAC ? What ?

...Mark





Received on Wednesday, 5 March 2014 23:12:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:21 UTC