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

[Steven Bellovin <[e-mail]>]

Thanks.  As you imply, my scheme does nothing about guessing attacks on
the wire, from either passive eavesdropping or MITM.  It wasn't intended
to, and of course that's been a subject of research for 20 years by
many people including me.  I'd missed 6124.  The purpose of my document
is more to address the concerns raised in 8.5 of that document.

On Feb 8, 2012, at 4:31 45AM, Yaron Sheffer wrote:

> Hi Steve,
> 
> to answer your parenthetical question, no, this scheme with a salt added would not fit well into IKEv2, because the user ID is sent along with the user-side authenticator. But then again, this scheme (with or without a salt) is not secure when used in IKEv2-PSK, for the same reasons that a plain password must not be used as an IKEv2 PSK, i.e. it is vulnerable to a dictionary attack by a MITM attacker.
> 
> Another alternative in IKEv2 is to use a password with one of the "secure EAP methods" listed in Sec. 4 of http://tools.ietf.org/html/rfc5998. These methods either use a long shared secret in lieu of a password, or are zero-knowledge password proof mechanisms. For the latter, storing a password hashed per your proposal may be valuable, and in fact a similar option is mentioned in http://tools.ietf.org/html/rfc6124#section-5.1.
> 
> Thanks,
> 	Yaron
> 
>> 
>> Message: 1
>> Date: Thu, 2 Feb 2012 18:38:11 -0500
>> From: Steven Bellovin<[e-mail]>
>> To: Dan Harkins<[e-mail]>
>> Cc: [e-mail], "[e-mail]"<[e-mail]>
>> Subject: Re: [Cfrg] ????: Re:  ????: Re:  [saag] New draft: Ha  shed
>> 	Password Exchange
>> Message-ID:<[e-mail]>
>> Content-Type: text/plain; charset=iso-8859-1
>> 
>> 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.
>> 
>> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
> 


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