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

[[e-mail]]

Hi, Steven,




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


Regards~~~

-Sujing Zhou

> 
>   That said, goal 4 in the draft-- "By iterating a sufficient number of
> times, dictionary attacks can be made arbitrarily expensive"-- seems a
> bit misguided. The Amazon cloud service has been used to launch an
> off-line dictionary attack against the WPA-PSK protocol which uses 
PBKDF2
> (HMAC-SHA1) with 4096 iterations to obfuscate a password. This attack
> checks 24,000,000 candidate passwords per minute at a cost of $0.28.
> That's more than 1,600,000,000 iterations per second for about 1/2 a 
cent.
> So I don't think increased iteration makes dictionary attacks much more
> expensive.
> 
>   Which begs the question, how is this proposal different than PBKDF2?
> That the "salt" is a service URI?
> 
>   regards,
> 
>   Dan.
> 
> > On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote:
> >
> >> Hi, Steve,
> >>
> >> This doc doesn't appear to address the case where a host has multiple
> >> DNS names, which could make it difficult to incorporate the hostname
> >> into the transform. I.e., I could contact a mail server at an IP 
address
> >> that represents any of dozens of DNS names - how does the server know
> >> which one I used so it can match without exhaustively trying all its
> >> equivalent names?
> >>
> >> Joe
> >>
> >> On 1/4/2012 1:41 PM, Steven Bellovin wrote:
> >>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt:
> >>>
> >>> Abstract
> >>>
> >>>    Many systems (e.g., cryptographic protocols relying on symmetric
> >>>    cryptography) require that plaintext passwords be stored.  Given 
how
> >>>    often people reuse passwords on different systems, this poses a 
very
> >>>    serious risk if a single machine is compromised.  We propose a
> >>> scheme
> >>>    to derive passwords limited to a single machine from a typed
> >>>    password, and explain how a protocol definition can specify this
> >>>    scheme.
> >>>
> >>>
> >>>       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> saag mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/saag
> >>
> >
> >
> >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
> >
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>