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

[Steven Bellovin <[e-mail]>]

I dealt with that in my note: how do you deal with multiple devices?

Sent from my iPad

On Feb 9, 2012, at 4:49 AM, [e-mail] wrote:

> 
> I understand the aim of your proposal, and similar ideas have also been proposed, such as pwdhash by Standford university, 
> a only  simple hash before sending passwoed can prevent more security loss when a server is broken, because it is human's weakness to have only a few sets of passwords, 
> even worse, the few passwords are often randomless for memory easiness. 
> 
> But only hashing password will not increase entropy, maybe an option can be added to your scheme that 
> another long and random key K can be stored exclusively in the user's device, 
> and the effective password equals hash of <password,user,service> and K? 
> 
> 
> 
> 
> Regards~~~
> 
> -Sujing Zhou 
> 
> Steven Bellovin <[e-mail]> 写于 2012-02-03 07:38:11:
> 
> > I'll be revising my draft soon.  For now, let me explain a few points.
> > 
> > First -- the primary goal of the draft is avoiding storage of cleartext
> > passwords, because even strong passwords are easily compromised if the
> > device or server is hacked.  A second goal is to conceal that the same
> > password is used for two different users or the same user on two different
> > services.
> > 
> > It's obviously true that attackers can still launch password-guessing attacks.
> > This does increase their work factor.  While the difference in work factor
> > may not be important for targeted attacks, it does help against broad-scale
> > attacks: can any single password be retrieved?  The way I look at it is
> > this: for a given effort, how many passwords can the attacker get?  If the
> > iteration count is doubled, the yield per given effort is obviously halved.
> > 
> > There are no large-scale precomputation attacks possible, because every
> > hashed password is unique for a given <password,user,service> triple.
> > 
> > I do not see how a random salt would help at all -- it still requires
> > about the same amount of computation per user per service per guess.
> > The essential difference between a random salt and my scheme is that
> > if I change my password to itself, with a random salt the hashed password
> > would be different; with my scheme, it would be the same.  The attacker's
> > effort would remain the same.  In addition, a random salt would hurt
> > usability and/or security.  For the former, consider that I (and many
> > other people) have many devices with stored passwords.  I personally
> > use three or four computers and two iToys to read mail.  So -- I set a new
> > password from one.  I now have to copy down that string and enter it
> > on five other devices.  Not very user-friendly.  Assume, then, that
> > the salt is sent as part of the protocol.  That not only hurts adoptability,
> > since the protocol would now have to have a way to transmit it at the right
> > point, after it knows the userid but before the authenticator is entered
> > (quick -- what will that do to, say, IKEv2?), it means that the user's
> > node would have to have the cleartext password available in order to
> > hash it with the salt.  But that defeats the purpose of my scheme.
> > HPW requires no changes to the protocol, and the only possible change
> > to the implementation is a longer input buffer.
> > 
> > Finally, I'm quite convinced that focusing on strong passwords is fighting
> > the last war (and, I might add, a war we've lost).  *NO ONE* is using
> > strong, unique, memorized passwords ubiquitously -- people have too many 
> > of them to remember.  By actual count, I have >100 web site passwords,
> > plus login passwords, root passwords, mail passwords, ATM PINs, phone
> > unlock codes, and more.  Sorry -- EBRAINFULL.  I think that far bigger
> > dangers are password reuse and node compromise.  HPW is designed to deal
> > with those threats.
> > 
> > "In a world of smart cards, hand-held authenticators, and zero-
> > knowledge proofs, it seems pointless to be worrying about poorly-
> > chosen passwords.  Were the world like that, we might agree.  Today,
> > it is not."  Mike Merritt and I wrote that about 20 years ago, in
> > the original EKE paper.  Fortunately, passwords are no longer in use, 
> > since they've been replaced by better technology, right?  Oh, wait.
> > 
> > 
> > 
> > On Feb 2, 2012, at 1:46 PM, Dan Harkins wrote:
> > 
> > > 
> > >  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
> > >> 
> > > 
> > > 
> > > _______________________________________________
> > > Cfrg mailing list
> > > [e-mail]
> > > http://www.irtf.org/mailman/listinfo/cfrg
> > > 
> > 
> > 
> >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> > 
> > 
> > 
> > 
> > 
> >