Hashing is a cryptographic process that can be used to verify the authenticity and integrity of various types of input values.
It is widely used in authentication systems to avoid storing plain text passwords in databases, but it is also used to verify files, documents, and other types of data. Misuse of hashing functions can lead to serious data breaches, but it is better not to protect sensitive data by not using hashing in the first place.
Comparison of one-way encryption method hashing and two-way encryption
Hashing is a one-way cryptographic function, while encryption is designed to work in both directions. The encryption algorithm takes an input value and a secret key and produces a random-looking output called ciphertext. This operation is reversible. Anyone who knows or has the secret key can decrypt the ciphertext and read the original input value.
The hashing function is irreversible. The output of the hashing function is a hash value, a digest, or a fixed-length string called a hash. Since it cannot be converted to the original value, there is no need to keep it secret.
However, one important function of the hashing function is that when hashed, the unique input must always result in the same hash value. If two inputs can have the same hash value, this is called a collision, and the hash function can be considered broken from a security point of view, depending on how easy it is to find a collision, etc. using a computer.
Hashing is always used more than encryption when storing passwords in a database. The reason is that in the event of hacking, the attacker cannot access the plaintext and there is no reason for the website to know the user's plaintext password.
That's why if you've ever gotten a notice from many companies that 'our employees never ask for a password'. You don't need to have a password, and you have an irreversible cryptographic representation of the password, that is, a hash value.
In other words, companies that have suffered data breaches often misuse the term 'encryption' in public standing and tell customers that their passwords are encrypted because they are safe. This is probably because the public is not familiar with the meaning of hashing, so the PR department wants to avoid confusion.
This makes it difficult for external observers to assess the risks associated with the spill. This is because if the password is really encrypted, the risk is higher than if it was hashed. So, you have to ask: Has the encryption key been hacked? In some cases, encryption is used instead of hashing in passwords.
In 2013, Adobe suffered a security breach that resulted in the theft of millions of account information, including encrypted passwords. Adobe updated most of its systems to use hashing, but the leaked server was a backup server that the company was trying to destroy, and the stored password was a Triple Data Encryption Standard (Triple DES) in Electric CodeBook (ECB) mode. It was encrypted.
Attackers could not obtain the decryption key, but using this cipher in ECB mode could leak information and recover a significant number of passwords through brute-force attacks.
OWASP (Open Web Application Security Project) stated in its password retention recommendations, “Encryption should only be used in special cases where the original password must be secured. In some cases, it may be necessary. This is the case when an application needs to use a password to authenticate on an external legacy system that does not support single sign-on (SSO), or when it needs to retrieve individual characters in the password. The ability to decrypt passwords implies a serious security risk, so the overall risk should be evaluated. If possible, alternative architectures should be used to eliminate the need to store passwords in an encrypted format.”
How to use hashing for authentication
In the authentication system, when a user creates a new account and enters a password of choice, the application code passes the password through a hashing function and stores the result in the database.
If the user wants to authenticate later, this process is repeated and the results are compared to the values in the database. Only if they match, the correct password is provided to the user.
If a user forgets their password, the password recovery process entails identity verification, and they verify ownership of the email used to create the account by clicking on the unique password reset link, which is usually sent via email. Allows the user to set a new password hash in the database. If the existing password is sent to the user via email or displayed on the browser through the password recovery process, it is not secure and the best security practices are not followed.
That is, even if hashing is used, the developer is not safe and may commit an implementation error by using a hashing function known to be vulnerable to brute force attacks. This type of hack can be found in many uses in the past, but in MD5 and SHA-1, which are no longer in use.
MD5, developed in 1991, was used as a de facto hashing function for a long time and even after cryptographers proved it was theoretically unsafe. Unfortunately, MD5 is still widely used by older applications or developers who don't understand security.
The first partial collision attacks were theorized in 1996, and the total collision was demonstrated in 2004. Currently, MD5 collisions can be detected on a typical home computer in seconds, and the algorithm is very vulnerable to brute force attacks.
SHA-1 (Secure Hash Algorithm-1) was developed by the NSA in 1995 and was the recommended NIST standard. Since 2005, this function has been known to be insecure against resource-rich attackers with access to cloud computing power.
In 2017, the French National Institute of Information and Communication Technology (INRIA), which collaborated with Google and researchers from Centrum Wiskunde and Informatica (CWI) in the Netherlands and Nanyang Technological University (NTU) in Singapore, published two PDF files with SHA-1 signatures. Generated and demonstrated a real collision against SHA-1. SHA-1 has been pushed back to TLS certificates but is still widely used by older devices and systems for a variety of purposes, including file signature verification, such as code storage and software updates.
For password hashing and storage, the recently drafted Internet Engineering Task Force (IETF) recommended using Argon2 (Winner of Password Hashing Competition in 2015), Bcrypt, Scrypt, and PBKDF2.
However, hashing is more important than the algorithm used. For example, passwords of at least 8 characters are important because they make brute-force attacks that rely on dictionary attacks (a list of common passwords obtained from other data breaches) much more difficult.
Each hash function is implemented to perform multiple iterations or passes of the hashing algorithm for each password. There is also a work factor, the goal is to use more computing resources to hack the results using brute force methods. Increasing the work factor increases security, but because the algorithm is executed multiple times, the computing resource usage of each hashing operation increases and slows down.
In its recommendation, OWASP says, “There is no golden rule for an ideal work factor, but it depends on the performance of the server and the number of users of the application. To determine the optimal work factor, you need to test with the specific server your application uses. "It usually takes less than a second to compute the hash, but it should be much lower for high-traffic sites."
Understanding Salt and Pepper makes password hacking more difficult
Another best practice for safe password storage is to combine each password with a randomly generated string called'Salt' and then hash the result. It also stores the salt, which must be unique to all users and passwords, along with a hash.
Salt passwords make certain types of attacks much more difficult or impossible. For example, an attacker calculates a hash for a large number of password combinations in advance and stores it in a database called a rainbow table. Later, if you find a leaked password hash, you can do an index on the database to see if it matches the previously computed hash. Salt passwords also change the resulting hash, making such an attack inefficient.
Salt also prevents attackers from finding duplicate databases in the database. Even if two or more users choose the same password, the server creates different salts and the hash is different. If the salt is at least 16 characters long, the complexity and length of plaintext strings that must be hacked using a computationally intensive brute-force method increase significantly.
To add another layer of security besides salt, developers can combine any password with a randomly generated string of at least 32 characters called Pepper. Unlike salts that are unique to all passwords, pepper is the same for all passwords, but should not be stored in the database. Pepper's purpose is to make it difficult for an attacker to hack the entire application database, including salt.
Pepper can be stored in a more secure location, such as an application configuration file or a Hardware Security Module (HSM), protected by appropriate file system permissions. “The alternative approach is to hash the password as usual and then encrypt the hash using a symmetric encryption key before storing it in the database,” OWASP said. The key acts as a pepper. This avoids some of the problems of the traditional approach to Pepper, and makes the transition much easier if Pepper is hacked.”
Upgrading the hash
Applications that use unsafe or weak hashing algorithms should switch to modern hashing functions. One of the conversion methods is to use the old hash as an input to the new hashing algorithm and re-read the old hash. This method can solve the immediate problem, but it is more vulnerable to hacking than if a hash was generated from the original user input.
So it's a good idea to regenerate the hash with a new, up-to-date algorithm when the user logs in and enters a password later. If a user does not log in for a certain period of time, you can reset the password and force the password to be reset the next time they log in.
Finally, it's the golden rule for all developers who use cryptography. 'Don't develop your own algorithm'. Cryptography is very difficult, and standardized and widely used algorithms are the result of academic research that is generally peer-reviewed by other cryptography experts and analysts.
0 Comments