RE: PBKDF2 questions

I'd argue that extractable=false protects the site by assuring them that even injected script can't extract the user's password. It's a bit like the argument for unwrapKey.

I agree at a high level that WebCrypto in isolation provides assurances to the site not the user. But if the underlying platform (the UA and perhaps even the underlying OS and hardware) provides some level of trust then it should be possible for the total package to provide some (even if limited) user assurance. For instance, having the UA enforce SOP is in some way an assurance to both user and site, and it depends on the platform's goodness. So I support small affordances that allow the platform to do a better job if it wishes to, and I don't think we should do anything that blocks this (so for example I would strongly oppose requiring extractable = true for user-entered keys).


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



On Wed, Mar 5, 2014 at 3:12 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
+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.

Well, that would be my I-am-not-a-cryptanalyst guess, yes.

But if it is clear that the purpose of the mechanism is to protect the *site* not to protect the *user*. That is, so that the site developer can be sure they never knew the password (and so can't inadvertently reveal it, or perhaps avoid some other requirements that come with knowing passwords), then this point does not apply.

If that is the case, there is no need for the UI to be "unspoofable" as suggested in the original note, because there is no assurance being given to the user. It is also unnecessary to require 'extractable = false' for this case.

...Mark

...Mark



From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
Sent: Wednesday, March 5, 2014 2:07 PM
To: Mark Watson
Cc: Vijay Bharadwaj; public-webcrypto@w3.org<mailto: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