Cybersecurity with hashing
Hashing makes it difficult for attackers to decrypt stored passwords - if it is used correctly. The functions play an important role in IT security - especially when it comes to storing passwords. This is what you should know about the topic:
Hashing is a cryptographic process that can be used to validate the authenticity and integrity of various types of data. Hash functions are mainly used in authentication systems - here they offer the advantage that no passwords have to be stored in plaintext format. If hash functions are used incorrectly, serious data leaks can result. The only thing worse is if hashing is not used at all.
Encryption vs. hashing
Unlike encryption, which can be reversed, hashing is a one-way street. The output of a hash function is a construct of various fixed-length characters - the hash value.
Hash values do not necessarily have to be kept secret, as it is not possible to convert them back to their original state. An important point here is that each data set to which a hash function is applied generates a unique hash value. If two different inputs have the same hash value, there is a "collision". Depending on how complicated it is to detect this by calculation, a hash function can be classified as ineffective from a security perspective.
If passwords are to be stored in databases, hashing is almost always preferable to encryption: In the event of a compromise, attackers will not get their hands on passwords in plain text format. "Encryption should only be used if there must be a way to recover the original password," recommends the Open Web Application Security Project (OWASP) on its website.
Hashing is used extensively in authentication systems: When a user creates a new account, the application hashes the password and stores the result - the hash value - in a database. With each subsequent authentication, this process is repeated and the hash value is compared with the one in the database. If they match, the user has entered the correct password.
If a password is forgotten, an identity check is part of the password recovery process. This usually involves sending an email with a unique link to the address used to create the account. When this link is clicked, a new password is created or chosen - and with it a new hash value in the database. If, on the other hand, the recovery process results in the old password being sent to the email address or displayed in the browser in plain text format, there is an implementation error - security best practices have been ignored in such a case.
The use of hashing alone is therefore not enough - the hash function must also be implemented correctly, otherwise there is a risk that attackers will succeed with brute force attacks. Errors can occur here, for example, if outdated hashing algorithms such as MD5 or SHA-1 are used.
In a current draft, the Internet Engineering Taskforce (IETF) recommends the use of the following hashing algorithms for storing passwords:
In addition to the algorithm, other factors are also important. For example, the password length: a minimum of eight characters is important, for example, because this makes dictionary attacks much more difficult.
Each hash function can also be implemented in such a way that the hashing algorithm is applied several times to the password ("work factor"). This provides higher security, but also requires more computing power. According to OWASP, there is no golden rule for choosing the right work factor: "The choice of the ideal work factor depends on the performance of the server and the number of users on the application. To determine it, tests with different servers are necessary. As a rule of thumb, the calculation of a hash value should not take longer than one second - in environments with high traffic even less."
One of the best practices in terms of secure password storage is so-called "salting". Here, a randomly generated string of characters - the "salt" - is combined with each password and stored together with the hash value. This prevents rainbow table attacks, for example, but also ensures that attackers cannot detect duplicate passwords in databases: Even if two different users have chosen the same password, salting ensures that these hash values differ. Effective salts should have at least 16 characters in order to mathematically put an end to brute force methods.
An additional security layer can be created by using "Pepper". Here, all passwords are combined with a randomly generated string (32 characters). In contrast to the salt, which is generated individually for each password, the "pepper" is the same for all passwords - and should therefore not be stored in the database. Instead, it can be stored in an application configuration file or a hardware security module.
The goal: Even if an attacker comes into possession of the complete database including the salts, it will be difficult to crack the hash values without Pepper.
Applications that use an insecure or weak hashing algorithm should be immediately upgraded to the latest version. The old hash values can be used as input for the new algorithm - in the form of a re-hashing process, so to speak. However, you should be aware that the resulting hash values are not as secure as those generated from the original user input. Therefore, it is commonly recommended to regenerate hashes with a modern algorithm only when users log in the next time.
The golden rule for all developers when it comes to cryptography in general is to avoid self-developed algorithms. The standardised and widely used ones are the result of years of research and are also put through their paces by other researchers and experts. (CSO)