A password is an extremely sensitive and given coveted by pirates, irrespective of the application that uses it. When the password becomes known to a third person, then the latter can for example take ownership of rights in an application and compromise its normal operation.
We’ll be covering the following topics in this tutorial:
What is a password?
Metaphorically, a password can be seen as a key opening a / door (s) to the one who holds it. Thus, this user appropriates additional rights that others do not have. It then up to him not to disclose it to the privileges conferred upon him are not diverted by a third person with bad intentions.
When / passwords must be saved in an information system (database, configuration files, …), it gets more complicated. Indeed, security is hanging by a person but is now based on the security of the information system itself (physical access credentials to connect it) and how these are stored passwords in SI.
Security passwords in an information system
It is evident that increased protection of passwords in the information system must be established. Storing passwords in clear text in the information system becomes impossible. What for ? Take the typical case of a database that stores user IDs of an extranet a company. This implies that a security policy at several levels of rights.
A technician will not have the same privileges on the application that her supervisor. The latter will also have the same rights as the HR director or CEO. In this application, the password is the guarantor of the security of data. We must therefore protect it diligently. A use of encryption becomes indispensable.
Why encrypt sensitive data in an SI?
The answer is simple. This is to keep confidential the password that has been assigned to the user out of the application. It there’s also a part of ethics since even responsible for the application should not to know the personal login users. This does not concern him. Returning to our example.
Who says extranet also said access to the application from the Internet. It is then advisable to encrypt data over a secure HTTPS connection and protect the application against possible hacker access. Say this extranet has been poorly written and it includes a SQL injection flaw. An attacker could then retrieve the passwords stored in the database and enter the application without problems with the identifiers of the CEO. If passwords are encrypted, the hacker will have even more trouble finding their correspondence in the clear. In this example, the attack comes from outside but what is so weak system is right inside of it?
Indeed, suppose that we should maintain the database by connecting directly above. The company who published the application sends its data base administrator intervention. This technician intervenes on site but makes no part of society that uses the application. Yet she will manipulate the database. Ie it can probably see everything in it is inside … including logins. If the passwords were stored in clear, he could appropriate the access of any user on the extranet application … Still, nothing prevents to create a new user with all rights directly into the database. We will see later that a traditional encryption is not enough to strengthen the security of a password.
There are many. This can range encryption algorithms (which can be decrypted with the algorithm and the proper key) to the hash algorithms. Rather, it is the latter that we tend to use today. Indeed, a hash algorithm to encrypt a string with no possibility of reverse operation. The result of the hash generally produces a single chain and of fixed length. This is the case for example with MD5 and SHA1 algorithms. Thus, during an authentication phase, no longer compares two passwords in clear but two password hashes.
Password Hasher MD5
Example of hash with md5 ()
$md5 = md5 ('m9tS3Q6ll9');
The variable $ md5 then contains a unique string composed of hexadecimal characters and a length of 32 characters.
Hasher a word to pass with SHA1
Example of hash with SHA1 ()
$sha1 = sha1 ('m9tS3Q6ll9');
The variable $ sha1 here contains a unique string composed of hexadecimal characters and a length of 40 characters.
Why simple hashes are not enough?
This method can effectively encrypt strings but remain “crackables”! ” Really ? Yet it was written earlier that we could not achieve the reverse !!! ” Effectively ! Nevertheless there are on the Internet “rainbow tables” (dictionaries) able to turn around the light chain md5 (), a sha1 () or other standard hash algorithm. No need to remind that conventional passwords root type superadmin, foo … exist in these dictionaries. As long as the original password is a dictionary word, it is likely that we can find it in a rainbow table from its hash.
Hasher passwords with ‘salts’
This technique consists of the concatenation of one or more keys (also called “salt”, “seed” or “seed”) the password and the hashed string created. Of course, the / keys must remain secret in an application configuration file. A simple example of password hashes from two seeds.
Password Hash with salts
// Declare the constants
define ('PREFIX_SALT', 'Ram');
define ('SUFFIX_SALT', 'Raj');
$hashSecure = md5 (PREFIX_SALT.'m9tS3Q6ll9'.SUFFIX_SALT);
In this example, we will finally MD5 hasher with the following string: Ram9tS3Q6ll9Raj
So the MD5 of this string will be completely different from the one MD5 password.
What then is the advantage of this technique?
This technique can not easily recover the original password in plain text in a rainbow table from MD5. Security password so is the complexity and confidentiality selected key.
Returning to our example, starting by considering that the passwords are hashed this time with this method before being stored in a database. The malicious technician working on the database can try to crack the passwords from a rainbow table, it will not succeed because it does not know the seeds used and employed encryption method. Similarly, if it recognizes the format of MD5 passwords, and it saves the password in this format, it will not work at the time of identification. Indeed, the hash of the concatenation of the password entered and two seeds will not match the hash he recorded just before the database.
Can this technique be used outside the passwords?
The answer is yes! This technique is used to encrypt the information placed in a hidden form field or a cookie. The technique of seed serves in particular to verify the integrity of data recorded between each page. This means that if the hash does not match the expected hash is that the client has changed the information on her side to try to chip away your application. It will be possible to apply the appropriate treatment: error message, ban the user for a while …