How passwords work maintaining your online security

One key element ensuring the security of your personal data both on the Internet and offline, is the password. Indeed, this precious password helps protect access to accounts you own on various websites and your computer. The security measures implemented to protect them are rarely very extensive.

After you have explained the working principle of identification by password, we will try to show you how websites can do to protect your passwords, by presenting some methods used by developers. After that, we will give you some tips to try to better protect your passwords on your side.

Operating principle of identification by passwords

Before discussing about the security of passwords, we must understand the functioning of the latter. When you register on a site which needs a username and password,  the registration script is added in the database, a line containing the username, email address and password that you have selected. Subsequently, when you try to login, the login script compares the information you have entered in the login form to those found in the database site. If they coincide, you login to your account, otherwise, it will refuse the connection.

Suppose you create an account on  a online service with the nickname “username” and password “password”. If you provide the information on the login form, with the nickname “username”, the script will try this case in the database and find it. To pass the stage of the connection, it will now compare the password that you have entered with the one that is stored in the database, then connect to your account if the result is positive. Otherwise, it will redirect to another webpage, saying “Login failed!” ; custom text and graphics are often added.

To take a more concrete example is that of an online bank account. If you try to open, you need both the number of the account or special number and a key or code associated with it. If a wrong key used with the account or special number, resulting in an inevitable failure. Often a Java script spy the system configuration and I.P. address too. Entering a wrong combination for predetermined number (generally three) of time may require an offline request to reset the combination; generally the key is changed.

How sites try to protect passwords

It is the first record in the database that determines whether your privacy is insured or not. Indeed, when the recording script stores your information in the database, including your password, it has two choices: store it as is, or to encrypt it.

What is the advantage of encryption?

It is very simple: imagine a malicious individual is able to access the database of a site on which you are registered. If your password was not encrypted, the hacker could then retrieve it and use it on all the sites on which you are registered with the same password. How would he find the sites on which you are registered you ask doubtfully? A little research on Google with your email address or nickname, and voila! Worse, suppose you have registered with your Gmail address and you have used the same password in both places: the hacker could then access your email account with impunity.

The goal, you have now understood, is to increase the security of your password. For this, before saving it in the database, the script will encrypt it. Thus, if a user came to access the database, it would not get your password in the clear, but in encrypted form: therefore unusable, apparently.

Now, you have grasped the value of encryption, you will wonder how the login script compares the encrypted password (which we will refer as hash afterwards) and that the user enters when wants to connect or login. Indeed, the user is not aware of the encrypted password and probably not even if the site is encrypted or not, it will capture the original when attempting to connect. If you understand the operating principle of the system of identification that we explained earlier, you guess the problem: the original password entered to the field is not equal to the encrypted password known to the database. It is equivalent.

Precisely because of this encryption almost all websites can not remember your real password, when they or you lose it and you or they have to generate a new one for you. Indeed, the hash functions operate in one direction. Therefore, if a site is able to return forgotten to you, it is usually does not encrypt passwords in its database, you can then worry about the security of your data.

To summarize: The security of passwords is largely based on their encryption in the database.

An algorithm to encrypt your passwords: MD5

The trick to circumvent this problem is simple: the login script will encrypt the password entered by the user before comparing it to that stored in the database. Using the same methodology as in the recording.

On many sites, it is the encryption function (or rather hash) MD5 is used. Its function is simple: it transforms an initial string (the password “password”), a new string of 32 characters (128 bits); assumed to be unique. With this algorithm, the password “qwerty” is transformed into “ab4f63f9ac65152575886860dde480a1.

Thus, with this system, if a malicious individual is able to access the database of a site on which you are registered, it can retrieve the encrypted password and not the original, it could not be used directly on sites where you would have also used. Nice, right?

Not much, actually, since the use of this simple algorithm, although very (too) common, is unfortunately far from being truly effective.

Among other things:

• In theory, decrypting a MD5 hash is impossible, but in theory only. Indeed, MD5 is widely used (and it is an understatement), many reverse dictionaries exist. Thus, as a reverse telephone directory, you enter the password encrypted, and the dictionary will return the original password, provided he knows it. Therefore, most generic passwords, common and short (“qwerty”, “hello”, “123 »…), can be decrypted in the blink of an eye.
  Specifically, it does get the same encrypted string from two different strings. To take a concrete example, if “qwerty” and “azerty2” gave both the hash “ab4f63f9ac65152575886860dde480a1” might consider this a collision. The risks to your data is more limited, but a collision may still allow someone to access your account even though it has not entered the correct password. One chance in several million, the collision was still difficult to implement.
• Imagine that one of the sites on which you are registered is a hacking website. Assume also that another site on which you are registered with the same password uses the same type of encryption. In both cases, the encrypted passwords stored in the databases of the two sites are identical. Suppose further that the good website uses the method of identification by cookies. It would then the hacker to create a cookie containing the encrypted password to connect to the good website. It sounds extreme, but it is a real danger.

To summarize: MD5 is a first line of defense, far from being infallible.

Other algorithms to encrypt your passwords

Given the limitations of MD5, many sites are beginning to abandon it in favor of algorithms considered more reliable. Thus, the use of SHA1 begins gradually to take precedence over that of MD5, because collisions are more difficult and dictionaries of passwords still not provided because they are new.

But is it enough? No, because if it were yesterday deemed reliable, it is already beginning to show its limits, the same as MD5.

And it is an infinite circle: newcomers, such as SHA256 (which now preferred), SHA512 or Whirlpool no, no, no washing machines , All provide additional security, since the number of characters in the encrypted string is still increasing. Imagine if becomes qwerty “f2d81a260dea8a100dd517984e53c56a7523d96942a834b9cdc249bd4e8c7aa9 (SHA256) rather than” ab4f63f9ac65152575886860dde480a1 (MD5), because of its size, the collision risk is lower because there are more possible combinations. Moreover, attempts to attack by brute force will be very long because it is less easy to overcome a code of 32 characters to 64 characters!

It should normally not save the password in the cookie (or anywhere else in the end), or even his hash.
The idea is that when the connection is made at random character string (or a token “token” which is stored in the database (the line corresponding to the user) and in the cookie.
When automatic login, it compares the token of the cookie to that of the database to enable or disable automatic login.
Any new connection creates a new token and thus automatically expires the old. In this way, a token in a cookie remains valid until the logs have been another post.

Yet, they still eventually lose their effectiveness over time, since most algorithms are used, plus dictionaries of passwords becomes available.

To summarize: MD5, SHA1, SHA256, SHA512, Whirlpool … In the end, what matters is not the algorithm that problem, but rather the inherent limitations of the art encryption. It is therefore interesting to introduce an additional method to protect passwords on a site.

The static grain of salt

The idea to improve the security of passwords is therefore to use a grain of salt (also called “salt”).

When saving your password in the database, recording the script performs two actions before storing your information in the database:

• It will add a “secret code” after the password is common to all users and stored in the PHP code. For example, it will add a grain of salt “_NA” after the password, which will “password _NA.
• The script will then perform the step of encrypting the password changed. Here, it will encrypt “password _NA” in MD5 and store it in the database, which will “ed50abc53d3f1b481bfc6641349afbb4” instead of “ab4f63f9ac65152575886860dde480a1” without salt.

The benefits here are numerous, as they make up for the shortcomings of almost all encryption methods that we raised earlier:

• Even if one of the websites on which you were registered with the same password used the same type of encryption, the password stored in its database would be more healthy identical to that recovered on the basis of the pirated website. Therefore, even if the site not hacked using the identification method by cookie, the hacker could not access it using a cookie made.
• The use of reverse dictionaries of passwords becomes more complicated. Indeed, it is less likely that they have the case “ssapdwor_NA” and “password”. With a grain of salt original, the possibility that the dictionary has this password is diminished.
  In the event of an attack by brute force or if the password is included in the dictionary, the attacker would get the password as amended: “ssapdwo_NA. The problem for him is that he would not know what a grain of salt, so it could not use the password, except if he could locate and remove the salt.
• Finally, the grains of salt used to fight against the shortcomings of your own passwords, they are too common or too short. Dictionary reversed, “password” is indeed found without problem, whereas “ssapdwo_NA” will not be bound.

To summarize: In a frightening efficiency, grain of salt is yet little used because so little known. Of course, if the attacker also gains access to the file server side which contains salt, it becomes aware of it, so the coverage will be less effective.

The grains of salt dynamics

With grains of salt, one can go even further! The ultimate weapon is in fact using a second grain of salt, this dynamic time. That is to say that we will use a secret code unique to each user that will be affixed to the password. One can, for example, generate one automatically, or you may use the date of registration of the user, then store it in the database.

When saving your password in the database, recording the script will then perform three actions before storing your information in the database:

• It will add a “secret code” after the password is common to all users and stored in the PHP code. Thus, as earlier, it will add a grain of salt “_NA” after the password, which will “qwerty _NA “( ab4f63f9ac65152575886860dde480a1)
• The novelty is that it will then affix the second grain of salt before the password. Here, suppose our staff is named “User”, the password will become  “User _NA qwerty “.
• The script will now take the step of encrypting the password changed. Here it goes then encrypt “User _NA qwerty” and save it in the database, which will be “56570953e016a8cdcde313bfe8152ff4”.

We can guess you are concluding: it is useless, because if a hacker gains access to the database, he will discover the dynamic salt! Certainly, but it complicates his task seriously, and that is reason enough to master in place: we do not he will still simplify the task, this task!

In addition to the benefits of the static salt, it provides additional (or improved):

• Here, using a dictionary of passwords is ineffective in 95% of cases. Indeed, due to the accumulation of a grain of salt static and dynamic atypical another, there is very little chance he has an entry corresponding to hash hacked.
• The attacker is obliged to establish a specific procedure for each user whether to decrypt the password. You can imagine the effort!
• This dynamic salt can ensure that no member has the same password that you encrypted. Indeed, with these encryption functions, if both users have chosen the same password, the hash of the two users is identical. It does not necessarily security problems, but not necessarily very significant, since, if you know the password unencrypted one of two members, you are able to know that second! Here, since the grain of salt is unique to each user, each has a different hash. It is even almost impossible that two members have the same hash!

To summarize: The use of grains of salt associated with the encryption password is a formidable weapon for the security of your data.

How to protect your side

On your side, you have few options that allow you to limit the damage and to ensure maximum security in your assumption that a database of a site on which you are enrolled had to be hacked.

On the one hand, it is important to try not to use the same password everywhere. We know this is easier said than done, and we know what we mean: if we really did, we would end up more! The idea is therefore to have three passwords: one aimed at critical sites (bank, mail account), password “trash” for sites where you have not enough trust, and one for sites with important or anywhere.

Secondly, choose a password original (not the name of your dog, your date of birth), neither too short nor too long. In addition, do not use common passwords (“qwerty”, “123”, “hello”, “password”, “Pa$$w0rd”…). The ultimate weapon is to combine numbers and letters, the ultimate being to add special characters (*, ^, @, or even vary #…), uppercase and lowercase letters.

In fact, we hesitate to list these measures in the previous section, because they can sometimes even be implemented on the server side. Indeed, some sites may require you to choose a password combination of numbers and letters, or making a minimum of characters. It’s annoying sometimes when you need to find a new password, but that is for our good!

Finally, of course, but do not register on sites that you do not trustworthy, or else, take their trash a password, as advised earlier.

To summarize: A password original and different for different sites is an ideal solution to make your passwords more secure.

Is the protection really possible?

You will therefore understand, even taking all precautions to have a strong password, registration on a site does not properly secure your data can be fatal. You should know that many sites use a simple MD5 hash, which is yet more unreliable. Worse, some sites (shops sometimes, even!) Do not encrypt your passwords! So why not conduct your own investigation, using the method described earlier (form recovery password). You can have fun guessing what encoding the site uses by reviewing your cookie, and more specifically the password field in it (if it’s 32 characters, it’s SHA1/MD5 , 64 characters: SHA256, 128 characters: SHA512/Whirlpool).

Despite all the precautions on the server side and user must be aware that the security of your passwords will always be fallible. Indeed, if a malicious individual can not recover passwords from the database, it inevitably will use other methods. For example, it is possible for someone to access your password when transiting, non encrypted on your browser to the server during registration or login, for example (it is still possible to prevent it with a SSH tunnel ).

Similarly, many sites (if not almost all) send your password in plain text email when you register. Again, your password could be recovered during the transit of mail.

Worse yet, it is even possible that unscrupulous webmasters choose to use their databases to try to recover the gold mine. Imagine a bad webmaster. Suppose that one of its members register on the site with his Yahoo account and the same password: this is the jackpot, because it can then access the victim’s email account with disconcerting ease!

You will therefore understand that the protection of passwords on the Internet is done at all levels. It is especially important to remember that the ultimate weapon is not and that’s even proper to it: no system is foolproof. Caution is called for.