Hacker News new | past | comments | ask | show | jobs | submit login

Seems that in many cases you get a choice between security over the wire or security in storage, but not both. By this I mean if you use a challenge response authentication algorithm then you often don't have any choice but to store the password in cleartext. Then authentication can be done even over an unencrypted channel without revealing the password.

The compromise seems to be to store the password with a oneway hash then use an encrypted channel such as TLS to send the full password for each authentication. There is still the possibility of intercepting the password at the end of this encrypted channel before the password is compared to the stored hash.

So both models have weaknesses, it just means you have to focus your security efforts into a different area. For the first, it might be somewhere deep in the backend, for the second you'd be paying attention to the front end where you accept the TLS (e.g. https) connection.

This has certainly been the case with for example PPP where you had a choice between PAP (secure storage, but sent in plain text) or CHAP (insecure storage but not sent over the wire in full). Jabber/XMPP servers also traditionally store in plain text but passwords aren't sent for each login. Though it seems that HTTP Digest auth does allow storage of passwords in a hash without transmitting the full password.

Then even with challenge response algorithms if someone is able to monitor a number of authentications then they may be able to gather enough information to pose as that user without actually knowing the password.




If I understood you correctly - there doesn't need to be a tradeoff between wire and storage security.

You could use a oneway hash at the client side as well.

If you don't want to divulge what's the hash in your database, you can add another oneway hash for whatever reaches the server.

The challenge-response can also be based on hashes.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: