What is salt when it comes to password encryption?

Asked

Viewed 6,306 times

11

Searching on cryptography, in some cases is used salt, as some people probably know. In English translation I know it is salt, but within the scope of software development I did not understand very well.

What is salt when it comes to password encryption? How can it be used if feasible?

  • 2

    Would not be duplicate this one?

  • @diegofm is not duplicated, but apparently has something to do with reply. I’ll read it there, because as you said yourself, the article is very big. So maybe this question is more specific about salt.

  • see http://answall.com/questions/2402/like-fazer-hash-de-passhas-safesafety and https://code.tutsplus.com/pt/tutorials/understanding-hash-functions-and-keeping-passwords-safe-net-17577

  • Possible duplicate of How to hash passwords securely?

2 answers

12


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

The use of encryption in the protection of passwords occurs through a function of hash - or "shuffling" (more details on the question "How to hash passwords securely?"). One single-hand function transforms the password into a distinct value, so that if an attacker obtains a copy of that value he cannot at first discover the original password with ease. This is useful because in most cases the attacker only has one copy BD, obtained through an SQL Injection or some poorly managed backup or something. To gain actual access to the system it still needs to log in normally, and for that the original password is required (the hash alone does not serve, the system does not accept the hash as credential).

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

How to force users to adopt more and more complex passwords is not an easy task, an alternative is to have the same password registered on different systems and/or by different users generate not the same hash, but different hashes. This prevents pre-computed hashes from being used in the new attacks, requiring the work to break them to be done all over again each time you want to discover a single user’s password. The salt technique consists of simply prefixing the password with 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 is 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 the protection of passwords already incorporate in themselves the use of salt, so just pass the salt as a parameter when requested (if requested - some algorithms already generate salt for you) and let the algorithm itself take care of the details. For more information, see the related question cited above.

Furthermore, avoid publicly exposing the salt of any user, but do not worry too much if this exposure is inevitable (e.g.: when salt needs to be sent to the customer, as in the protocol SRP). Prefer a fairly long random salt rather than an easily predictable one (e.g., the user ID in the bank or even your own username). And every time a user changes his password, also change the salt - important especially if the user changes his password to another one that he has used before.

3

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

To illustrate I will consider, here, the inversion of the text (ABC -> CBA) as a type of cryptography, only to demonstrate what happens with SALT in a way that facilitates human understanding. In the real world, it’s not humans doing this work, it’s algorithms based on mathematical models.

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

With a known password and its encrypted result, it is possible to 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 today, mathematically any password can be broken, however it is important to note that in many cases it would take hundreds or thousands of years, so it is assumed as safe(as) these passwords and algorithms.

Although in the real world we do not use simple algorithms like this, it is also not only humans who try to break these encryptions, specialized algorithms also do this dirty work, so hence the need to make these passwords more secure.

Salt consists of adding characters, words, terms, or even numbers that give randomness to the cryptographic result and help make it more complex. They are usually added before encryption, and can be fixed or random.

Taking into account the same algorithm cited, let’s take the example: Senha: 123456 Salt: 20170323 Senha+Salt: 12342017032356 Senha Criptografada: 65323071024321

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

  • 3

    Using registration data for salt is not all bad, but it is important that it is the data of the last password change, not the user registration or something like that. Many users reuse passwords, and if a salt used in a previously broken password is used again with the same password, the resulting hash will be identical. The same ideal is that the salt is random, but strictly speaking any single data serves (and it does not need to be secret, although if it is simple to hide it, it certainly gives an additional security).

  • if the salt is random as you will check the password again???? because if it was random the probability of vc generate the same salt to check if the hashs hit is minimal

Browser other questions tagged

You are not signed in. Login or sign up in order to post.