Secure SHA an Enhanced Hashing Mechanism

In recent times, though most applications emphasize its users on keeping strong passwords through stringent password policies, these strong passwords would be effective if and only if they are maintained securely at the back-end. In simpler words we can say, it is of no use having your precious valuables deposited in a bank locker that has no proper security measures to safeguard it for you. Have we ever wondered are our passwords stored securely at the back-end? It is not only an end user's responsibility to use strong passwords, but also the application's responsibility to securely safeguard user's strong passwords.
Though most of us know that the simplest and a safe way of securely storing passwords at the back-end  is by means of Hashing (a one-way crypto operation of transforming the clear text password to a fixed-length cipher text with the help of standards-based hashing algorithms say, SHA-1), there are also few drawbacks associated with this mechanism.
As all widely used hashing algorithms (SHA-1 / SHA-2) are bound to give a fixed output, therefore one can get to know that the clear text password will always generate a base-64 encoded SHA-1 hash of "W6ph5Mm5Pz8GgiULbPgzG37mj9g=". Then every time an intruder sees this encoded value in the back-end, he can compute that the clear text value associated with this hash is "password". Therefore, if a dictionary of pre-hashed values is created that maps to the clear text used to generate the hashes, it can be used to quickly break any commonly-used passwords.
This can be minimized with the introduction of Salt (a unique value pertaining to the user (say, user id) that is added to the clear text password and this combination (clear text password + salt) is then hashed resulting in an unique hash for every user).
Secure SHA (SSHA) is an enhanced secure feature to this salted hash technique in which we get more additional security by introducing a random value as the salt instead of the static salt discussed above.
The way SSHA can be implemented is explained in the following steps:

  • Generate 8 bytes of random data (salt)
  • Append the salt bytes to the bytes of the clear text password
  • Generate the SHA-1 digest of clear text password + salt
  • Append the salt bytes (generated in step 1) with the SHA-1 digest
  • Base-64 encode the resulting SHA-1 digest + salt and store this combination in the back-end

During future verifications, the application can validate the user supplied password in the following way:

  • Fetch the Base-64 encoded string from the back-end
  • Base-64 decode the string to get the SHA-1 digest + salt combination
  • Remove the last 8 bytes from the decoded value to get the salt
  • Append the salt bytes to the bytes of the user supplied clear text password
  • Generate the SHA-1 digest of clear text password + salt
  • Compare the resultant hash against the hash value obtained in step 3 (the remaining bytes after removing the last 8 bytes) and if both values match, authentication can be termed successful.
Rate this article: 
0
No votes yet
Article category: 
Keywords: 

Comments

I'm struggling to understand what's new about this... as far as I know this has been in use for several years.

Server side password storage has gone way beyond this, and if you don't even mention bcrypt, leave alone scrypt or PBKDF2, you're not even scratching the surface.

A good starting point is to google for "password hashing competition" and go through the PDFs etc on that page to get an idea of what is REALLY needed in today's environment.

This scheme still leaves two holes open. The clear text password can be sniffed over the network. Someone could capture network packets and replay them to gain login access of another user.

I had implemented an enhanced version of this for TCS Bancs Core Banking, where I used the user id as the salt to be added to the clear text password. The resulting hash was stored in db. But neither the clear text password, nor this hash went over the network, to prevent above problems. The scheme used one more dynamic salt, valid for only few minutes, to compute one more hash, that travelled on network. Login was 2-step process, get random salt from server, and then send login request. Server would have an expiry time for random salt for the user. Server would compute second hash using salt and the hash from db and compare with the one given in login request.

Change password process was also similarly modified.

Pages