Re: username in clear...

[David Jablon <dpj@xxxxxxxxxxxxx>]

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:

At 01:23 PM 4/3/01 +0100, Stephen Farrell wrote:
>
>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. 

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.

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

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
>the issue is whether there's any benefit in omitting some bits of
>the hash or not.)

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.

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

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.

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

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

>Stephen.
>
>-- 
>____________________________________________________________
>Stephen Farrell         				   
>Baltimore Technologies,   tel: (direct line) +353 1 881 6716
>39 Parkgate Street,                     fax: +353 1 881 7000
>Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
>Ireland                             http://www.baltimore.com

-- David