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

[Steven Bellovin <[e-mail]>]

On Feb 9, 2012, at 7:35 PM, [e-mail] wrote:

> 
> 
> Steven Bellovin <[e-mail]> 写于 2012-02-09 20:32:07:
> 
> > I dealt with that in my note: how do you deal with multiple devices? 
> 
> Just copy and paste to all the devices, or retrieve the required long key from a USB key. 
> It is seldom required to change, so it does not bring much inconvenience, and just an option for users to choose.   
> 
Apart from the fact that I think that that's user-unfriendly, I still don't
understand what problem you are trying to solve.  


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


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