Password Security: Salting, #1 – Password Storing
Security
Practically, all present applications use usernames and passwords to allow the access to systems.
Is also known that that information is of the most coveted by the informatic attackers. We as systems developers , have the moral obligation (and sometimes legal obligation too)to protect our users’ information. Previously, it was very common to find the data stored in flat text fields “UserName” and “Password” – the worst design in information security:
| ID_User | User | Password |
| 1 | janedoe | systempassword |
| 2 | janesmith | janesmith |
| 3 | johndoe | password |
| 4 | johnsmith | password |
An attacker who managed to obtain access to the data, could easily enter the system using another user’s identity. Nowadays, with the improvements in legislation and design of security in systems, it’s common to encrypt the password; so, if an attacker managed to get the information, he could not decipher the obtained data. Using MD5 to encrypt the sample data, we would have Password=MD5(password):
| ID_User | User | Password |
| 1 | janedoe | 67e375717d8d06e5ec5feac9b92e97a4 |
| 2 | janesmith | 1f51c87a47d5c4aacc042ba9945523ce |
| 3 | johndoe | 5f4dcc3b5aa765d61d8327deb882cf99 |
| 4 | johnsmith | 5f4dcc3b5aa765d61d8327deb882cf99 |
Pretty much impossible to decipher, right? Totally false… With the sophistication of the informatic attacks, nowadays a simple hash function to encrypt information as delicate as passwords is insufficient. Why? Most of the users choose passwords little less than safe(names, directions, dates, common words , even the username itself), only giving the attacker with access to the DB the hassle of a encrypted known word attack to get some passwords. In order to ease the work, the attacker could scan the passwords’ hash and detect repeated information. Centering his/her attention in those records with a known word attack. That is to say, if there were 10 users who use the word “password” as password, there would be 10 records in the DB with the value of “5f4dcc3b5aa765d61d8327deb882cf99″ (like johndoe and johnsmith in our example). And also, if there are several records with the same value, that is for sure a well-known word (how many people uses the company’s name as password for the Intranet)
Salting
To mitigate this danger, there is a technique called “Password Salting”. This technique consists of adding extra information relative to each user before encrypting the password. Then, when applying the hash function, the result is unique(*) for each user. In our example we will use the extra information in ID_User, getting Password=MD5 (password + ID_User):
| ID_User | User | Password |
| 1 | janedoe | 95ffe45aed7fa057c8b632cc184b7ce5 |
| 2 | janesmith | 8fd6b4806b109a7117faeb64ea810959 |
| 3 | johndoe | 819b0643d6b89dc9b579fdfc9094f28e |
| 4 | johnsmith | 34cc93ece0ba9e3f6f235d4af979b16c |
* “unique” in terms of our DB. It is known that MD5, having a finite number of outputs and an infinite number of inputs, has many hash string collisions . Nevertheless, for our practical example of user/password, we will allways get unique results.
With this method, we now see that we won’t find identical stored data, making the attack more difficult. Let us remember that no method is infallible and no system is inviolable, but taking actions as the one suggested here lessen the risks that we have in users’ data storage.
In the following article we’ll check password salting on the user’s side. As we know, the weakest link in security is the user, but with a little education from sys admins and responsibility on the part of the user, we can obtain an acceptable level of security. For the users, the article will try to improve your passwords used to access systems and to avoid that your information is accessed by unauthorized people.
Cheers!
even contests must be “rescheduled” for completion 
