Subject: [Cfrg] New draft: Hashed Password Exchange

From: Steven Bellovin <[email-masked]>
Date: Wed, 4 Jan 2012 16:41:55 -0500

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

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 4 Jan 2012 17:56:08 -0500

Good point; let me think about it for -01.  An obvious solution is to send
the hostname with the effective password.

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:
>> _______________________________________________
>> saag mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 4 Jan 2012 18:36:34 -0500

Not with HMAC -- we do it all the time with, say, ESP-NULL.

On Jan 4, 2012, at 6:02 57PM, Joe Touch wrote:

> 
> 
> On 1/4/2012 2:56 PM, Steven Bellovin wrote:
> Yes, I considered that, but then you're sending cleartext that was part of the hash; I thought that was frowned upon...
> 
> Joe
> 
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 05 Jan 2012 09:12:56 +0200

Hi Steve,

thanks for the new draft. A few comments:

* The argument against using a random salt is somewhat unconvincing: "it 
would have to be known to the user as well as
the server, and users typically have multiple devices on which they 
enter passwords." Since we assume computing power on the client side, 
there's no reason why we cannot have the server send the salt to the 
user instead of having it stored client-side. I do agree though that the 
benefits of a random salt added to this scheme are minimal.

* Arbitrary non-ASCII passwords must be supported. I suggest to remove 
the under-specified bullet about "canonicalizing the entered password" 
and adopt text similar to (from RFC 6124):

This protocol supports internationalized, non-ASCII passwords.  The 
input password string SHOULD be processed according to the rules of the 
[RFC4013] profile of [RFC3454].  A password SHOULD be considered a 
"stored string" per [RFC3454], and unassigned code points are therefore 
prohibited.  The output is the binary representation of the processed 
UTF-8 [RFC3629] character string.  Prohibited output and unassigned code 
points encountered in SASLprep preprocessing SHOULD cause a 
preprocessing failure and the output SHOULD NOT be used.

* The text implicitly assumes that we are "sending the effective 
password over the wire." This is obviously not the case if strong 
password-based methods of the EKE family are used.

* "If effective passwords are used only for the usual password 
verification and not for cryptographic purposes, they should be treated 
with the care used for ordinary password, i.e., salted, hashed, etc. " I 
can see the value of hashing here, but not of salting.

Thanks,
     Yaron

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

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Thu, 5 Jan 2012 11:28:12 -0500

Steve,

How would you compare your proposed localizing-by-URI approach with
localizing-by-host (or by "SNMP engine") approach proposed in RFC 3414
http://datatracker.ietf.org/doc/rfc3414/ ?

Some questions to consider.

You propose "localization" by service - i.e., by hostname + port. How many
passwords per user would a server store? How critical is your requirement
that "no two [effective] `passwords for different services [on the same
host] should be the same for the same user"?  A benefit of not localizing
based on the whole service would be the ability for a multi-named server 
based on some rules that are out of scope for this email  choose the
"dominant" name and localize users' passwords to it, thus storing one
password per user on this server; avoiding the potential ambiguity that Joe
Touch pointed out.

Is HMAC an overkill in this case, considering that inverting a decent hash
didn't work even for the long-deprecated MD4 (we seem to worry here about
non-invertibility/one-way-ness, not collision resistance)? Or did you choose
it because it's the best keyed hash construct we have?  Note that the
brute-force attacks would be the same for both plain hash and HMAC (with
HMAC offering one more hash run per iteration).

Regarding salt  couldn't it be used on the server only? Treating the
"localized password" as the pre-salted password in the original Unix scheme,
then salting it before comparison? Obviously this is not the method to use
in protocols that employ the password derivative as a cryptographic keyŠ

Oh, and since this proposal seems to be addressing the same problem in a
somewhat similar way  perhaps it would make sense to include a reference to
RFC 3414 (section 2.6 Key Localization Algorithm)? :)

Tnx!
-- 
Regards,
Uri      [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 7 Jan 2012 01:03:25 -0800 (PST)

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

  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.

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