Have you ever wondered why does most of the websites/web applications ask you to reset your password by sending you a link in the mail instead of sending your existing password in the mail?
Well, the very simple and straight answer to this question is because they do not have one. Most of the web applications which adhere to best security practices never store login passwords of their users anywhere to avoid any unauthorized access to the passwords.
But, This fact brings up another question that if the web applications do not store the passwords anywhere then how does they authenticate the users by asking them to enter the username and a "password"?
Actually, these web applications use a technique called Hashing to create a "digest" from the password and instead of storing bare passwords in their database they store the "digest" created from the password. When a user makes an login attempt the application takes the password, runs it through the same Hashing algorithm to obtain and digest and compares the computed digest with one stored in database for the entered user.
How hashing is Different From Encryption ?
On the surface hashing might seem very much similar to encryption, another widely used security technique for used for information security, in which using certain encryption algorithms actual information in plain text is converted to secret text called cipher text for keeping it secure. But both Hashing and Encryption are entirely different.Encryption is a two way technique where the plain information is encrypted to a cipher text to keep it secure from unauthorized access. But if some unauthorized hacker/eavesdropper gets the decryption key and decryption function of the algorithm used to encrypt the information, the information can be converted back to plain text.
Hashing on the other hand is one way technique where information is converted to a cipher/secret text called digest using hashing algorithms so that it can never be converted back to its original form. Even if some intruder/eavesdropper gets access to digest created from original text/information and even to the Hashing algorithm used to created that digest he will never be able to convert it back to original text.
So there is no way to recreate the original password from the digest even if some authorized person gets access to the digest created from the password.
Some popular hashing algorithm used to create digest from plain Text are MD5, SHA-0, SHA-1, SHA-2 etc.
The similar methodology is used to store other sensitive user information such as Credit Card Information, Bank accounts etc.
Some applications that uses the security questions as an option to reset the password in case you "Forgot password". The answers to these security questions are also saved in database only after creating a digest from those after hashing.
So there is no way to recreate the original password from the digest even if some authorized person gets access to the digest created from the password.
Some popular hashing algorithm used to create digest from plain Text are MD5, SHA-0, SHA-1, SHA-2 etc.
The similar methodology is used to store other sensitive user information such as Credit Card Information, Bank accounts etc.
Some applications that uses the security questions as an option to reset the password in case you "Forgot password". The answers to these security questions are also saved in database only after creating a digest from those after hashing.
How Digests are made more Stronger?
Although converting the passwords to digests and saving those in database instead of original password make them secure to unauthorized access. But there are some further improvements done by these web applications to make them more stronger.
While most of the websites use standard hashing algorithms. If any intruder/hacker somehow get access to the digest created from password and has access to those standard algorithms he can try generating and matching the digest for the password and hence can obtain that password by hit and trial method called Brute Force attack. To address this issue websites asked the user to make password larger in length and use a combination of Capital letters, small letters, special characters and digits. Using a mix of all these characters and larger in length increase the permutations and combinations for arrangement of these characters and makes the Brute Force attack slow. For Example a password with 12 characters having a Capital,small,special character and digits or say all the possible standard ASCII value will have 94^12 different possibilities, or 4759203148142533764751364 combination which a regular computer may take thousands years to crack.
But using standard hashing algorithms brings one more issues. The digest created from a particular word using standard hashing algorithm is unique. So instead of trying to reverse a digest to a password attackers maintain Rainbow Tables which contains pregenerated digests of possible dictionary words. For example MD5 digest/hash generated from string "password" would always be 48cccca3bab2ad18832233ee8dff1b0b. So if any user uses the string/word "password" as his/her password and attacker gets access to its digest he can easily obtain password from it using by looking up into the Rainbow Tables. To avoid this web application uses salt. Salt is just a very large random number generated in application while obtaining the digest from a password for the first time for a user and is concatenated with the password entered by user. The salt is then saved into the database along with the digest. Every time authentication is done and digest need to be created from the entered password this salt is fetched from the database, concatenated again with entered password and digest is calculated. If the digest matches with the one saved in the database, login successes otherwise it result sin failure. So if any attacker tries to lookup the digest in the Rainbow tables he will never get a match because now the digest is actually created from the password and a very large random number salt. So use of salt while creating a digest makes them secure from these rainbow tables.
But using standard hashing algorithms brings one more issues. The digest created from a particular word using standard hashing algorithm is unique. So instead of trying to reverse a digest to a password attackers maintain Rainbow Tables which contains pregenerated digests of possible dictionary words. For example MD5 digest/hash generated from string "password" would always be 48cccca3bab2ad18832233ee8dff1b0b. So if any user uses the string/word "password" as his/her password and attacker gets access to its digest he can easily obtain password from it using by looking up into the Rainbow Tables. To avoid this web application uses salt. Salt is just a very large random number generated in application while obtaining the digest from a password for the first time for a user and is concatenated with the password entered by user. The salt is then saved into the database along with the digest. Every time authentication is done and digest need to be created from the entered password this salt is fetched from the database, concatenated again with entered password and digest is calculated. If the digest matches with the one saved in the database, login successes otherwise it result sin failure. So if any attacker tries to lookup the digest in the Rainbow tables he will never get a match because now the digest is actually created from the password and a very large random number salt. So use of salt while creating a digest makes them secure from these rainbow tables.
0 comments:
Post a Comment