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

[zhou.sujing at zte.com.cn]

Hi, Steven,




cfrg-bounces at irtf.org 写于 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
> >>> saag at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/saag
> >>
> >
> >
> >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > saag at ietf.org
> > https://www.ietf.org/mailman/listinfo/saag
> >
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg at irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>