Authentication is the important matters when the template was protect by the password. Before go more deeply on salting method that is known as the best way to strengthen the password, let's focus on some definition related to this field. For the normal login system, users have to insert their username and password to login the system. Actually the password entered by the user is known as clear text password. This clear text is the unencrypted characters create by the user itself. Hashing is a process that follows a mathematical formula to convert a user's password or clear text into an encrypted alphanumeric value. Despite its harder-to-crack encryption, hashing has security weaknesses. Salt is a metaphorical term for a random array of characters that will be attached to a password to strengthen it against hackers. Salt also can be concatenated with the hash becoming Salted Hashing. Salted Hashing is a technique to make passwords harder to crack. It consists of adding a salt value to a password, and then hashing it.
Stored passwords for logins should be hashed and salted. Hashing is a one way mechanism to produce a practically unique value based on the given input [4]. This is useful since the authorized user can store the hash (and validate the password whenever needed) without storing the actual password [4]. The same input will always produce the same hashed value which is useful for validating password logins but it is also problematic since people could determine that Fred's password must be the same as Andrew's password since they have the same hashed value [4]. This can be taken to an extreme where you roll up the matching hashes across thousands of passwords and can therefore use a common password list to start identifying passwords - think someone looking at system User table with thousands of records looking for hashed passwords with the same value [4]. The solution is salting which means adding a known random value to each password before hashing it - this makes all the hashed values unique and prevents cross-referencing or dictionary attacks [4]. For the better understanding about clear text, hashing, and salted hash, some examples of scenario listed below:
Let say in one system database has a password table that is an electronic dataset of columns and rows listing each user's ID and password, when a user attempts to log in, the system compares the ID and password the user enters with the values in the password table. If they match, the system admits the user [3].
Table 1: Password Table
The risk inherent to a password table is that it could be compromised. For example, a hacker could gain unauthorized remote access to it or it could be intentionally divulged to an outsider by, perhaps, a terminated system administrator [3]. To illustrate this, assume that AIA Bank requires its employees to use passwords that consist of at least five numbers and uppercase or lowercase letters. The bank maintains these passwords in a password table. Table 2 shows the three primary password formats available to system managers, and indicates the relative risk associated with each method [3].
Table 2: Password Format Risk Exposure
Clear-text passwords as in Table 1 illustrates; this unencrypted format plainly reveals the system passwords to anyone who views the table [3]. System administrators should ensure their staffs understand the danger and inadvisability of storing passwords in clear text format [3]. Basic hash encryption involves encrypting passwords before storing them in a table. One common technique involves the use of a mathematical hashing formula, which converts a user's password into an encrypted alphanumeric value [3]. Table 3 below illustrates the process of hashing. Assume AIA Bank employee Betty chooses password "Giants". As an example, the hashing process converts "Giants" into "66tt" .
Table 3: Process of Hashing
With hashing, only the user knows his or her password. The system administrator will know only the hashed value of the user's password. And if a hacker somehow were to learn that hashed value, he or she wouldn't be able to "reverse-compute" the password [3]. If a user forgets his or her password, he or she can request a temporary one, which the system administrator can send to the e-mail address specified in the user's system profile. To guard against misuse of the temporary password by an unauthorized person, the system should require the user to answer a previously agreed-upon question. For example, after the user keys in the temporary password, the system could ask him or her to provide his or her mother's maiden name [3]. At this point, the system also should require the user to choose a new permanent password. But while basic hash encryption makes passwords harder to crack, it is not a serious challenge for many hackers [3]. That's because basic hashed values can be vulnerable to hacker attacks employing rainbow tables, which are lists of the pre computed hashed values of thousands of words that employees may have chosen as passwords [3].
If a hacker obtained a copy of the password table as shown in table 4 below, the hacker could compare it to a rainbow table, searching for matches.
Table 4: Hashed Password Vulnerable to Rainbow Tables
The bank's password table as in Table 4 contains a hypothetical hashed value of each password in the clear text table in Table 1. In Table 4 also has a sample of rainbow table. A hacker would compare these two tables, seeking matches. If a match is identified, the hacker could deduce the employee's password. In this case, the hacker would see that "66tt" is the hashed value of Betty's password, "Giants". To make matters worse, the hacker also would see that Jenny's and Tom's hashed password values are "66tt" too, meaning their clear-text password also "Giants". Armed with that information, the hacker would easily be able to log into Betty's, Jenny's, and Tom's accounts.
Because of the hacker can easily guest the hash and the initial password, the hash encryption should be salted. Salted Hash encryption involves the use of what is popularly known as a salt string. A salt string is a random array of characters created and then attached to a user's password before hashing it [3]. This extra step; adding salt will exponentially increases the difficulty of cracking the password [3]. With unsalted hashing, there's a good chance one of the hacker's rainbow tables will contain a match for the password he or she is trying to deduce [3]. But when the password contains salt, which the rainbow table probably won't contain the odds of a match diminish, and the hacker is likely to be slowed down and stumped [3]. Once a hacker realizes your system uses salted hashing, the hacker probably will move on, searching for a system not protected by salt [3]. Table 5 illustrates the use of salt in hashing system.
Table 5: Salted Hash - The Best Defense
From Table 5, AIA Bank employee Betty uses "Giants" as her password. When she creates it, the system will generate a random string, for example "454px", and add it to the beginning of her password, which will become "454pxGiants". The system then will hash that value, converting it to "zz79xt964" and placing the result in the password table, as shown in Table 5. Although Betty, Jenny, and Tom have the same clear-text password; "Giants", each of them has a different salted hashed version of that password.
