[Standards-JIG] JEP-0077: In-Band Registration

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Jul 17 17:00:07 UTC 2006


On Mon, 17 Jul 2006 17:33:30 +0200, Piotr Szturmaj <gacek999 at tlen.pl>  
wrote:

> Hi,
>
> JEP-0077 says that passwords are sent plain. Why not hash them and store
> hashes only? Plain text password is a big lack of security, any person  
> who
> have database access could read user's passwords. Also client application
> must store plain/encrypted password which can be readed anyway since it
> isn't one way encryption like hash.
>

Storing a hashed password on the server, only makes sense if in the  
authentication process you do not use a hashed value but the actual  
password. Think about it, if you store the hash on the server, and you  
only need a hash for authentication, you can just steal the hash. Keep  
thinking... for most login procedures, you have to send the plain text  
password, which is then hashed and compared with a hash that's stored on  
the server. Now imagine I steal the hash of your password on that server.  
Turning that hash into a password again, or one that gives the same hash,  
is one of the hardest problems in computer science. What you're saying is  
"eh skip that step, you don't need that to hack *my* account".

"Ah", you say.. "but if only the hash is stored, then you can't steal the  
password, and use the password for other accounts". True, but only if  
*they* don't implement this silly scheme either. In fact, many services do  
store the hash, which means if you steal that hash you could use it to  
login with your scheme.

It's all been discussed over 3 years ago (and let's hope it won't flare up  
again here, trust me, the idea's been put to death sufficiently), I can't  
find the beginning of this thread now, but I can point you to the end of  
it. It was called "edigest": http://www.google.com/search?q=edigest+jabber

conclusions:
- Storing a hashed password on the server, and using a hashed password  
during authentication is only security through obscurity (or "silly", if  
you like). It'll only last as long as you're the only one doing it, and  
while it closes some possibilities (again, as long as you're the only one  
doing it), it opens up a whole bunch of other ones.
- This can be helped by including realms in the hash (salting). Guess what  
SASL can do? :)
- If you absolutly do not want to store plaintext passwords, use SASL  
and/or require plain-over-TLS authentication (and registration, if you  
still allow it in-band). Or just plain if you're feeling lucky.

Of course, wether you're storing hashes or plain text passwords, you  
should always make sure they are protected. Typically you want to make it  
rather hard for most people to have unrestricted acces to your user  
database (I'd recommend encrypted storage).





More information about the Standards mailing list