Authentication protocols that DO support hashed passwords

[Alan DeKok]

E.S. Rosenberg wrote:
> No new EAP on the block that handles passwords stored in salted hashes?

  Not really, no.  The reason is simple.

Q: How do you get a new EAP method to 10^9 existing devices?

A: You don't.

> I understand that, my question is more "How is it that the various
> RADIUS protocols can only work with cleartext passwords known on the
> RADIUS server side?"

  Because the RADIUS server gets given a hash by the client.  If the
RADIUS server can find a clear-text password in the database, it can
re-create the hash, and compare the two hashes.

  If the RADIUS server has a hashed password in the database, it can't
compare MD5(password) to SHA1(password).  The hashing methods are
designed to make that kind of comparison *impossible*.

> To me (someone who has been doing systemadmin/network admin/(web)
> development work) it seems like the most obvious thing in the world
> that I don't want my users passwords to be stored anywhere where
> me/any of my co-workers can get to them in cleartext and since root
> can get everywhere that means cleartext passwords belong nowhere.

  Your ideas are admirable, but unrealistic.

> Now I may be naive or have never tried to develop an AUTH protocol, so
> I am just very curious what the arguments are to store cleartext?

  See above.

  You *cannot* focus on one piece of the system.  "I want the passwords
stored in hashed form in the DB, NO MATTER WHAT EFFECT IT HAS ANYWHERE
ELSE IN THE NETWORK".

  You have to take ALL things into consideration.  The supplicant (end
user PC), database, authentication protocol, etc.  Then, choose the
least crappy method which satisfies all pieces.

  And the winner is usually clear-text passwords.

  Alan DeKok.