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