Salted hash implementation in Login, in nutshell
The best approach would be
hashing the passwords, instead of encrypting them as key management becomes an
issue.
Benefits of passwords in form of
salted hash:
·
Real passwords are
never stored/ displayed/ logged in the system
·
Salts makes dictionary attack very impractical as it’s very difficult to generate re-computed hash table as salts are random
·
It’s easier to
implement as no need of key management
A general approach would be like
this (when storing):
·
Generate a long
random salt using cryptographically strong functions such as SecureRandom in
Java, when user is first time registering himself
·
Use the above salt
and hash it with the user’s chosen password using standard and strong hashing
algos like SHA 256
·
Now strore the
Username, salted hash and respective salt in DB
When retrieving (authenticating
user):
·
When the user
submits his username-password, retrieve the user’s corresponding salt
·
Concatenate the salt
with the user supplied password and apply the same hashing algo (SHA 256) and
compute the salted hash
·
Now compare the
newly computed salted hash with already stored salted hash against the username
·
If they match, let
him in otherwise throw a generic login error, such as ‘Invalid Credentials’
Client side vs. Server side:
·
Always do hashing on
server side, irrespective of client side hashing
·
The issue with
client side hashing is , even it’s not in clear text, it is as good as a clear
text password
·
If you do client
side hashing, you need to depend on Javascript, which sometimes is disabled by
user, or some browsers may not execute properly
·
Client side hashing
is not replacement for TLS/ SSL. Protect all sensitive pages, such as login
page over SSL
Constraint:
·
You may not be able
to recover user’s original password, if user forgets it as the passwords are
not in clear text. You can just users to update with a new password
Comments