Re: PBKDF2 questions

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

>
>
>
> On Wed, Mar 5, 2014 at 12:43 PM, Mark Watson <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 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.

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.)

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> 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> 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]
>>>> *Sent:* Wednesday, March 5, 2014 9:54 AM
>>>> *To:* 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
>>>>
>>>
>>>
>>
>