Subject: username in clear...

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2001 13:23:01 +0100

Yesterday, I suggested the more-or-less the following to 
Radia, Charlie and Tom, (and since they didn't quite decide I 
was crazy:-), it might be worthwhile considering incorporating 
something like this into the framework/protocol as we go forward.

> I was thinking again about the username-in-clear problem (where
> I type my password in the wrong box) & wanted to check with you
> to see if something works.
> 
> In PDM, your first message is: version||"Alice"||2**A mod p
> 
> If I were to replace the string "Alice" with the low order
> 32 bits of h("Alice") would that be ok and would it solve
> the problem?
> 
> I'm assuming that 32 bits are enough to identify Alice to a single 
> credential server - in the event of a collision, the credential server 
> checks all colliding entries in turn.
> 
> Secondly, if this trick works, could it also apply (or something
> similar) to the other authentication schemes, so that we have a
> way to address the username-in-clear problem generally? I'd
> guess it should, say sending h("Alice")%(2^32) at the start
> of SRP.
> 
> I realise that this results in Alice always emitting the same
> string, so its not a privacy feature, just addressing the
> stated problem of password-in-username-field. 
> 
> If this works, I much prefer it to the "special character" fix 
> suggested earlier.

Basically, they all said "32 bits, yuk" (paraphrasing:-) and
argued to use the full hash instead. Radia said:

> But to make your suggestion a general purpose thing, I'd advocate sending
> the whole 128 bits of the hash. Then there would be no collisions. There's
> no reason to worry about the size. Perhaps one could argue that it
> gives too much information...narrowing down the password to a single choice...
> in the case where the user typed the password instead of name. But
> I'd argue that cutting down the password space by 2**32 is as good
> as yielding the password.

(Though I'm not entirely sure what the last sentence means. I guess
the issue is whether there's any benefit in omitting some bits of
the hash or not.)

Tom pretty much agreed with Radia and also said:

> Perhaps TLS with ADH and authenticated Finished messages would be worth
> looking into as a way to deal with this general issue.  At least there,
> you can't snoop the username without actually interfering in a
> detectable way.

Charlie also pointed out another drawback:

> The only
> downside that comes to mind is that the server can't canonicalize
> the name by mapping all characters to upper/lower case, accept
> Lnicknames, do "sounds like", delete leading/trailing/doubled
> spaces, etc. That's probably acceptable in a lot of circumstances.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: David Jablon <[email-masked]>
Date: Tue, 03 Apr 2001 10:40:27 -0400

Stephen,

The hashed username idea sounds a little like "poor man's"
privacy and security.  But since it costs so little, it might not be
such a bad idea.  :-)

Essentlially you're taking a step towards treating the user name
like a password, but in the way that old systems dealt with passwords --
facing the same "low-entropy" problem.  In particular, it still permits
brute force attack and traffic analysis to discover the name, and
protocol-level replay for on-line guessing.

Some comments embedded:

>> stated problem of password-in-username-field. 

What is the "stated problem"?  Is there some consensus on the
sensitivity status of usernames?  It seems like it could include both
privacy and security issues.  But either way, replacing the username
with a synonym for the name doesn't seem like a strong solution.

>> as yielding the password.

Yes, a small hash result would be useful only when you *want* collisions,
which would keep the hash alone from revealing the input.
This trick has been used in some poor-man's password systems.
But it doesn't seem to apply here since you want to uniquely determine
the name to make it easy to find in the DB.

>(Though I'm not entirely sure what [Radia's] last sentence means. I guess

Radia may have considered that the number of actual names in the DB,
or even a plausibly guessed set of names, is small, and perhaps much
smaller than 2**32, and thus it will produce very few collisions.

You also need to retrofit any existing name DB into a hashed-name DB,
which is probably not a big problem.

Also, for what it's worth, you can keep doubly-hashed names in the DB,
and let the server re-hash the singly-hashed names as they come in.
This keeps a stolen DB from immediately revealing clear-text
names, or even the singly-hashed values on the wire.

>> you can't snoop the username without actually interfering in a

Tom's alternative uses anonymous public-key exchange to protect
the name in transit, which stops all the above attacks in the case of
mostly-passive eavesdroppers.  (I say "mostly" because the eavesdropper
would later try to masquerade as the client if he could.)
This is generally a more thorough approach.

An ADH pre-exchange also seems about the best that you can do without going
to the next level -- requiring pre-authentication of the server by the user.
That would seem to require the client have server keys or root certs,
and more participation by the user.

>> spaces, etc. That's probably acceptable in a lot of circumstances.

And even though the server can't, the client can canonicalize if needed.

>Stephen.

-- David

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2001 16:07:17 +0100

Hi David,

> privacy and security.  But since it costs so little, it might not be

The intent is not to support privacy, nor "security" of usernames,
rather to handle V11 from the requirements document:

"V11.    User enters password instead of name."

If you send straight usernames in clear, then you also send passwords 
when V11 happens. With the hash, at least the sniffer folks can't
see that its happened (unless they have a list of all hashed usernames
or similar).

Stephen.

---

From: David Jablon <[email-masked]>
Date: Tue, 03 Apr 2001 11:51:14 -0400

Stephen,

Oops, that means quite a few of my comments were off-the-mark,
even if username privacy is a nice side-benefit.  Sorry about that.

The case where a password is sent in the username field by mistake
is even more compelling for a stronger initial public key exchange,
whether anonymous or not.  But I would also hope the client UI would be
designed to make this case extremely unlikely.

And now I see how the intentionally small hash idea may
in theory have some merit, in the case where the space of enrolled
usernames is a lot smaller than the guessable password space.
But it seems hard to quantify this in a way that gives a universally
acceptable specific small size.

-- David

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2001 16:56:57 +0100

Hi David,

> designed to make this case extremely unlikely.

Agreed. If we can encrypt there's no need for this. Not sure yet if
we'll be able to or not.
 
> acceptable specific small size.

Yep. Though I suspect Radia & Tom were right in a sense, if the
password's typeable, then you can probably tell when you've 
guessed right even with only 32 bits of the hash (anyone know if
that's true - my arithmetic stinks;-).

Stephen.

---

From: David Jablon <[email-masked]>
Date: Tue, 03 Apr 2001 12:21:29 -0400

> that's true - my arithmetic stinks;-).

Of course it all depends on your environment and methods for training
users, etc.  But the few empirical studies that I've seen found a "sweet spot"
in the password space with a significant portion of accounts crackable with
a 30-to-40 bit effort.

-- David