Re: PBKDF2 questions

On Wed, Mar 5, 2014 at 3:12 PM, Vijay Bharadwaj <
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]
> *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> wrote:
>
>
>
>
>
> 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.
>
>
>
> 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> 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
>
>
>
>
>
>
>
>
>
>
>