Password Storage

H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Nov 26 18:01:39 PST 2015


On Fri, Nov 27, 2015 at 12:17:32AM +0000, brian via Digitalmars-d-learn wrote:
> I'm starting to build a small web-based application where I would like
> to authenticate users, and hence need to store passwords.
> 
> After reading this:
> http://blog.codinghorror.com/youre-probably-storing-passwords-incorrectly/
> and many other posts that I zombie-surfed to from that page, I'm now
> fearful of doing this badly. :(
> 
> My reading of that post was that I should be storing things as:
> 
> hash = md5('salty-' + password)
> 
> So when a user tries to authenticate, I need to:
> 1) validate the user id
> 2) find the unique "salt" I generated for that user when they registered
> 3) pre- or post-pend the salt to the password entered (apparently there is a
> difference??)
> 4) md5 the lot
> 5) check this md5(salt+password) against what I have stored.
> 
> So for each user, I need to store in my database:
> UserName/UserID
> Salt
> Hashed_Password
> 
> Can the developers in the room confirm if this is the correct approach?
> Are there examples of betters ways of doing this?
[...]

For authentication, the password shouldn't even be sent over the wire.
Instead, the server (which knows the correct password) should send a
challenge to the client (i.e., a large random number produced by a good
RNG -- which is different each time the user authenticates). The client
should then prepend this challenge to the password typed in by the user,
and compute the hash of the result. This hash is sent back to the
server, which does the same computation on its own, and checks whether
the two hash values match. Provided you're using a good cryptographic
hash, the only way the client will be able to provide the right answer
is if the user actually knows the password. At no time is the password
ever sent over the network, encrypted or not.


--T


More information about the Digitalmars-d-learn mailing list