What is salt when it comes to password encryption?

Salt is used to prevent two identical passwords from producing identical hashes - which would greatly facilitate the work of attackers.

The use of encryption in password protection occurs through a hash - or "shuffle" function (for more details on the question " How to securely hash passwords? "). A one-way function # turns the password into one value so that if an attacker obtains a copy of that value he can not at first discover the original password easily. This is useful because in most cases the attacker only has a copy of the DB, obtained through an SQL Injection or some poorly managed backup or something. In order to actually gain access to the system it still needs to log in normally, and for this the original password is required (the hash alone does not work, the system does not accept the hash as a credential).

Getting the password from the hash is difficult, but not impossible: multiple systems are hacked around the world, and most users not only choose weak passwords like reusam password in various services different. If every time a password washed it would produce the same value, then a discovery of a password / hash relationship made on a system could be used to attack any user using that password in any system! There are even sites like this that have billions of hashes already "broken", allowing see a password (or other data) from your MD5 hash (and MD5 was already very popular as a password hash, there are still some who use it for lack of knowledge of better hashes).

As forcing users to adopt more complex passwords is not an easy task, an alternative is to make the same password entered on different systems and / or by different users generate not the same hashes but different hashes. This prevents pre-computed hashes from being used in the new attacks, requiring that the work to break them is done all over again every time you want to discover the password of a single user. The technique of salt consists of simply prefixing the password with a random data before it is hashed. This salt is created during the registration of the password, and then stored next to it in the BD (it is not necessary that the salt be secret, only that it is single [with high probability]). >

On the correct way to use them, this depends a lot on the case, and there are situations where misuse of them can cause problems. However, all modern algorithms designed specifically for password protection already incorporate the use of salt in themselves, so just pass the salt as a parameter when requested (if requested - some algorithms already generate the salt for you) and let the algorithm itself takes care of the details. For more information, see the related question quoted above .

Furthermore, avoid exposing the salt of any user publicly, but do not worry too much about it if such exposure is unavoidable (eg, when salt needs to be sent to the client, as in SRP ). Prefer a random, fairly long salt rather than an easily predictable salt (eg the user ID at the bank or even your username ). And every time a user changes their password, change the salt as well - especially important if you change your password to another one that you have used previously.

    

Salt is the addition of characters, words, terms or even numbers that give a certain randomness to the algorithms and help make them indecipherable.

  

To illustrate, I will consider here the reversal of the text (ABC -> CBA) as a type of encryption, only to demonstrate what happens to SALT in order to facilitate human understanding. In the real world, it is not humans who do this work, they are algorithms based on mathematical models.

Based on the above example, imagine a password "123456" using this algorithm (poorly by the way) you would get "654321".

With a known password and its encrypted result, you can identify which algorithm was used to generate it. The complexity of the algorithm and the password are determinant in the time needed to break it. Until now, mathematically any password can be broken, however it is important to emphasize that in many cases if it would take hundreds or thousands of years, therefore, it is assumed that these passwords and algorithms are safe.

While in the real world do not use simple algorithms like that, it's not just humans trying to break these encryptions, specialized algorithms also do this dirty work, so the need arises to make those passwords safer.

The salt consists of adding characters, words, terms or even numbers that randomize the result of encryption and help make it more complex. They are usually added before encryption, and can be fixed or random.

Considering the same algorithm, let's take the example: Senha: 123456 Salt: 20170323 Senha+Salt: 12342017032356 Senha Criptografada: 65323071024321

You can create random, dynamic salts that do not even need to be stored. You can use data from the record itself to determine a salt (date of registration, or date of creation). All this helps increase randomness and thus helps to hinder identification of the pattern used to encrypt something.