Re: [Cfrg] [saag] New draft: Hashed Password Exchange

[Steven Bellovin <[e-mail]>]

On Feb 1, 2012, at 3:13 AM, [e-mail] wrote:

> 
> Hi,all 
> 
> [e-mail] 写于 2012-01-07 17:03:25:
> 
> > 
> > 
> > On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote:
> > > Good point; let me think about it for -01.  An obvious solution is to send
> > > the hostname with the effective password.
> > 
> >   How is that different than using random salt then? If _something_ is
> > going to be sent shouldn't it be a uniformly random bitstring instead of
> > a hostname?
> > 
> >   A uniformly random bitstring would be more appropriate as a key to
> > HMAC than a highly structured string like a password too. Iterate
> > HMAC(salt, password | service-URI) instead of HMAC(password, service-URI). 
> 
> 
> 
> I think Dan's suggestion is reasonable, I checked the RFC 2104 and found the following section : 
> 
> "3. Keys 
> 
>    The key for HMAC can be of any length (keys longer than B bytes are 
>    first hashed using H).  However, less than L bytes is strongly 
>    discouraged as it would decrease the security strength of the 
>    function.  Keys longer than L bytes are acceptable but the extra 
>    length would not significantly increase the function strength. (A 
>    longer key may be advisable if the randomness of the key is 
>    considered weak.) 
> 
>    Keys need to be chosen at random (or using a cryptographically strong 
>    pseudo-random generator seeded with a random seed), and periodically 
>    refreshed.  (Current attacks do not indicate a specific recommended 
>    frequency for key changes as these attacks are practically 
>    infeasible.  However, periodic key refreshment is a fundamental 
>    security practice that helps against potential weaknesses of the 
>    function and keys, and limits the damage of an exposed key.)" 
> 
> 
> Since passwords are often not too long, and not so random, it is better 
> to hash it before using it as a key in a HMAC. 

Although hashing the password first certainly doesn't hurt, I read that
text as more related to brute force attacks against the key, rather than
to any limitation of the underlying function.  Hugo -- are you on this list?
Could you clarify?

		--Steve Bellovin, https://www.cs.columbia.edu/~smb