[Standards-JIG] Re: JEP-0077: In-Band Registration
gacek999 at tlen.pl
Mon Jul 17 18:56:37 UTC 2006
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.
- This is partially good, e.g storing hash instead of plain text.
What you're saying is
"eh skip that step, you don't need that to hack *my* account".
- I see this step as a good approach.
"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.
- Yes, this cannot be avoided, but it is better than stealing the plain
password. Additionally other services can use different hashes with
different salt. Even if all will use MD5, salting XMPP with "JABBER" should
avoid using the same hash elsewhere.
"- 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."
- Indeed :)
"- 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."
- I forgot to say my client establishes TLS layer and authentificates by
SASL (DIGEST-MD5) anyway in In-Band Registration password must be sent
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).
- What about this:
- Client hash each password and then send it to server. Client also store
hash on disk for automatic login.
- Server threats received hash as password like it always does.
- Server hash password with some salt (salt depends on implementation) and
store it in DB.
In conclusion we have:
- even if someone steal hash from DB he cannot supply it for
authentification - it wont work, and by design he can't retrieve original
- since there are no plain text passwords sent between client and server
only user knows the password, even if someone steal hash from user he cant
retrieve the password
- password steal case is limited to user's machine, if someone has access to
it, he obviously could steal it, and there is no way to avoid that (to
harden hash storage it could be encrypted and/or stored in hidden places but
it is up to client implementation)
Comparing to existing approach we increase the security much.
gacek999 [at] tlen [dot] pl
More information about the Standards