Re: [saag] New draft: Hashed Password Exchange

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<smb <at> cs.columbia.edu>
> To: Dan Harkins<dharkins <at> lounge.org>
> Cc: cfrg-bounces <at> irtf.org, "cfrg <at> irtf.org"<cfrg <at> irtf.org>
> Subject: Re: [Cfrg] ????: Re:  ????: Re:  [saag] New draft: Ha  shed
> 	Password Exchange
> Message-ID:<9E8EB80F-5D1E-4C68-8D52-4B2432DBF15D <at> cs.columbia.edu>
> 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.
>
>