Salt (cryptology)
Salt ( English for salt ) referred to in the cryptographic a random string to a given plaintext before its further processing (. For example, input to a hash function ) is appended to the entropy increase of the input. It is often used for the storage and transmission of passwords used to the information security to increase.
motivation
Passwords are not saved directly, they are hashed when an account is created, and the hash is saved in the database with the user data. When a user logs in, the password he has entered is hashed and compared with the stored hash in order to authenticate the user .
Cryptographic hash functions such as B. BLAKE or SHA-2 almost certainly generate different hash values for different plain texts (e.g. different passwords). The collision resistance of the hash function means that the probability that the same hash value will be generated for two different passwords is so small that it can be neglected in practice. However, the hash for a given password is always the same. Therefore, the same hash values can be used to identify which users have chosen the same password.
In dictionary attacks , in which you hash many possible passwords one after the other and compare the result with the password hashes stolen from the database, you only have to hash each password once and compare the result with the hashes of all users to determine whether any of the users chose this password. Knowing the password hashes of many users thus multiplies the chances of success. By using powerful parallel hardware (often graphics cards ) and optimized algorithms , you can typically has many millions of passwords per second.
For many hash algorithms, so-called rainbow tables are already available, which relate a number of possible passwords (e.g. all words in a dictionary) to hash values. If a given hash value comes from a password from this set, this password can be found much faster than by systematically trying out all passwords.
Salt
Where the login takes place via the Internet or other networks, the access data are often provided with salts. A password is no longer hashed directly, but is entered into the hash function together with the salt. The salt is either the same for all users or it is generated randomly for each user when they create their account.
Even the use of a constant salt (the same for all users) prevents the rainbow tables from being used for known hash functions, because the salt means that the mapping of the passwords to the hash values is different. You could in principle create rainbow tables for password-salt combinations, but with a sufficiently large number of possible salts this is completely impractical. They would have to contain all supported passwords in every combination with the possible salts - with a bit-long salt the number of plain texts to be recorded in the table would be times as large as before.
Systematic trying out the passwords is just as possible because an attacker who can access the database content can usually also find out the salt. This is made more difficult if a separate salt is generated for each user, which is saved together with the hash value and the other user data. Now a hash value calculated from a trial password and salt is only valid for the user with this salt. Each trial password must be hashed again for each user. In addition, two randomly chosen identical passwords from different users no longer produce the same hash value.
Pepper
To make dictionary and brute force attacks even more difficult, the password can be combined with a sequence of characters chosen by the server and kept secret before the hash value is calculated. This string is called a pepper and is usually the same for all passwords on a server. If the Pepper is also changed for each password, security can be further increased. The pepper is not stored in the same database as the hash value, but in a different and as secure location as possible. If an attacker only gains access to the database (e.g. via SQL injection ), he can still find out the hash values, but these now come from combinations of password and an unknown pepper. A dictionary attack is pointless because no dictionary will happen to contain any of the password-pepper combinations. A brute force attack is also made drastically more difficult because you not only have to try out the passwords, but also the combinations of password and pepper.
It is often recommended to use an HMAC in order to combine password (there as a secret key ) and Pepper (there as a message ), since the collision resistance of the hash function is then no longer decisive for the security of the overall construction.
practice
There are hash functions specially developed for hashing passwords , e.g. B. bcrypt , scrypt and Argon2 . These also allow a coordination of the hash effort in order to burden the attacker with the higher effort when trying out the possible passwords. This is the same principle as with key extension . If the effort required for hashing is increased by a factor of n compared to a normal cryptographic hash function such as SHA-2 , then the attacker also has to spend n times the time for each password , i.e. H. he can try fewer passwords by a factor of n in a given time and has a correspondingly lower chance of success. Hashing with SHA-2, for example, takes less than 10 −6 seconds on a modern computer , and n can therefore often be greater than 1000, depending on the frequency of the server and the available computing power.
The state of the art for this purpose is argon2, which was also designed to make the use of specially developed hardware ( ASICs ) more difficult. The user can determine not only the time required, but also the memory space used and the parallelism (number of processor cores used ).
Difference to nonce and padding
A nonce and the padding are very similar to a salt, since they are also strings that are not evaluated in the program or algorithm or used in any other way than simply appending them to another string. The difference lies in the purpose and the precise application of these strings.
While a salt is used in passwords to increase entropy, nonce and padding are used in encryption algorithms . The nonce is used to ensure the "uniqueness" of a plain text so that the generated ciphertext differs despite the determined procedure of the algorithm if the same plain text is encrypted several times. Thus, the nonce should also be as random as possible.
Padding, on the other hand, does not usually have to meet the criterion of randomness and is usually used to make it more difficult to determine the length of a plain text and ciphertext, or to increase the length to the block length.
Problems
Forms a procedure due to a programming error or a faulty implementation e.g. For example, if you only have 1,000 different salts, creating a rainbow table can still be worthwhile. Such cases are called "weak" salts. One such method is the cached login information (DCC, Domain Cached Credentials, also referred to by cracking programs as MS cache hashes) created by Windows systems (XP, Vista). The username is used as the salt. Rainbow tables can therefore still be generated for widely used user names, e.g. B. administrator .
A salt has no security-enhancing effect against brute force attacks or dictionary attacks in which a check is made for various inputs to determine whether they match the hash value. For this purpose, computationally complex calculations have to be interposed ( key stretching ), the purpose of which is to slow down trial and error to the point of practical uselessness. An example of this is the PBKDF2 algorithm, which is often used when storing passwords.
See also
Individual evidence
- ↑ Password - safer with hash and salt . In: Data Protection Officer INFO March 11, 2013, accessed on November 5, 2013
- ↑ Secure storage of passwords - let's spice up the soup . www.martinstoeckli.ch Accessed October 30, 2013
- ↑ Cracker brake - braking factor . In: c't 13/2011, page 148 Retrieved October 30, 2013
- ↑ Secure storage of passwords - let's add a little pepper . www.martinstoeckli.ch Accessed October 30, 2013
- ↑ Tom Leek: What is the purpose of a Pepper? In: Information Security. Stack Exchange Inc, September 4, 2013, accessed May 30, 2017 .
- ↑ Prof. Dr. Eike Kilt: Hash functions and collisions. (pdf) In: CRYPTO RUB. Ruhr University Bochum , accessed on June 29, 2018 .