Re: [Cfrg] ´ð¸´: Re: ´ð¸´: Re: [saag] New draft: Ha shed Password Exchange

["Dan Harkins" <[e-mail]>]

  The issue is that hashing a password doesn't make it "random"
(while it might make it "long"). So no, an ordinary hash is not
enough. As I suggested, I think a non-secret salt exchanged in
the protocol can be used as a key to a HMAC and the password can
be included in the data to be HMAC'd.

  Dan.

On Wed, February 1, 2012 5:22 pm, [e-mail] wrote:
> Well£¬ it is the requirement of the HMAC for key being long and random.
> Then in the case of the draft, ordinary hash is enough I guess?
>
>
> Regards~~~
>
>
> [e-mail] дÓÚ 2012-02-01 23:49:13:
>
>> My take on this is: if you believe that a hash-function is a good
>> randomizer and can be used in cryptographic key generation process ¨C
>> then  it does not matter whether what you feed as a "key" input to
>> HMAC is uniformly distributed or not (because of HMAC internal "hash
>> spins"). And if you are uneasy on how really random your hash output
>> is ¨C then a lot of the currently used mechanisms and primitives need
>> revisiting.
>> --
>> Regards,
>> Uri Blumenthal                            Voice: [phone]
>> Cyber Systems and Technology  Fax:    [phone]
>> MIT Lincoln Laboratory
>>
>> From: "[e-mail]" <[e-mail]>
>> Date: Wed, 1 Feb 2012 03:13:07 -0500
>> To: Dan Harkins <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, Steven Bellovin
> <[e-mail]>
>> Subject: [Cfrg] ´ð¸´: Re: [saag] New draft: Hashed Password Exchange
>>
>>
>> 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.
>>
>>
>> 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
>> > [¸½¼þ "smime.p7s" ±» ÖÜËÕ¾²00132831/user/zte_ltd ɾ³ý]
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>