“I have hashed the passwords and stored them in the database, there will be no way an adversary can reverse the hashes”. All too often I have heard this coming out of application developers and infrastructure team. This is true to a certain extent, if the password was complex enough. However, many a time proper password complexity and hygiene were not abided to and due to usability issue, password complexity was not strictly enforced as well. Show
So what can we do to ensure that the passwords were properly secured and stored in the database? Salt and bcrypt or PBKDF2. In cryptography, a salt is a random string of data that is appended to a one-way function that hashes the data. What it primarily defend against is something known as a lookup/rainbow table attack. Find below for a simple illustration of a typical lookup/rainbow table attack.
 CrackStation runs on a extremely large pre-computed lookup tables to attempt to crack the password hashes. The hash value obtained by the adversary was compared against the lookup table, which contains a mapping between the hash and the associated cleartext string, in this case would be “Password123” This was only made possible because salt was not used. Imagine a random salt “Rand0mS@lt” was appended to the cleartext password before hashing, the resultant hash value of “Rand0mS@ltPassword123” would not be found in CrackStation’s lookup table. Even with the usage of salt, it does not stop the adversary from attempting a dictionary or brute-force attack against the salted hash. Take for example MD5(Salt+Password) hash was stored in the database. Ad adversary can create his own list of MD5(Salt+Wordlists) hashes and compare them against the hash value stored in the database. This way, he would be able to retrieve the cleartext value of the password if a match occurs. This was only achievable because MD5 is an extremely efficient hashing algorithm that calculates its hashes very quickly. We can mitigate this by using a technique known as key-stretching. bcrypt and PBKDF2 are two very slow hashing functions that can achieve this. The idea is to make the hash function slow enough such that even with custom hardware and modern GPU, dictionary and brute-force attacks are too slow to be worth the adversary’s effort in attempting so. The aim is to make sure that the hash function is slow enough to impede attacks, yet quick enough not to cause any noticeable delay for the legitimate user. Securely salting and hashing password before storing into the database is extremely important. People tends to reuse their password on multiple sites. Given the rise of security breaches and password hashes being leaked (recent Cloudflare and Dropbox hack), this is definitely a concern that needs to be addressed. References: https://crackstation.net/hashing-security.htm http://dustwell.com/how-to-handle-passwords-bcrypt.html https://www.wired.com/2017/02/crazy-cloudflare-bug-jeopardized-millions-sites/ https://www.theguardian.com/technology/2016/aug/31/dropbox-hack-passwords-68m-data-breach Passwords remain the most common method of user authentication. Yet, they’re not the most secure. One solution to certain security concerns with password authentication involves hashing, a form of one-way encryption that transforms one string of characters in a password into a completely different string using a mathematical hashing function. To improve the safety of your hashing algorithm, you can also use security techniques such as salting, where you add a “salt value,” or a set of random characters, to the password before hashing it. Using techniques like salting exponentially increase the computational cost for attackers to decipher the hash if your system is ever breached. In this article, we will discuss what salting is, how it improves the strength of a hash, and what the differences are between salting and peppering. Then, we’ll discuss some best practices for salting a hash and highlight how Stytch’s Passwords solution uses salting to enhance security and protect against hackers. What is salting?Salting is the process of modifying the password string that is to be hashed by adding a salt value to that initial string. A salt is a string of characters that could either be a legible word or, preferably, a set of random characters. For example, you might have a password like Pa$$word, with a salt value of Df)0!2. Instead of storing the hashed password as-is, the system will add the salt somewhere to the string — usually before the password, though it can also be after. The string that will be hashed will be the salt plus the password: Df)0!2Pa$$word, in this example. This new string will then get hashed and saved into the database. So, even if there were to be a data breach and the hashed passwords were to be leaked, the added salt would make even common passwords tough to crack. The value of salting in addition to hashing passwords becomes clearer when you consider how attackers will attempt to crack hashed passwords that are exposed in a data breach. While storing passwords in plaintext is the worst password storage hygiene, rainbow table attacks make the sole act of hashing passwords inadequate when it comes to securing your users. “Rainbow table attacks” leverage pre-computed lists of password hashes to infer the plaintext value of a leaked hash value. By adding a salt to your password hashing process, you remove the ability for hackers to leverage these pre-computed lists. Salting versus pepperingSalting and peppering, at the core, have the same goal. Both involve altering the initial string by adding a random value to it before being hashed. The key difference between them is where they are stored. Peppering also describes the adding of a pepper (a random value) to a password during hashing, but unlike salting, the value isn’t kept with the password in the database — instead, it’s saved separately in a different location and form, like in the application code or a Hardware Security Module. One peppering technique is to randomly select a pepper from a list of strings. The pepper used isn’t saved, so each login attempt means the application needs to try each pepper in the list until it finds a matching hash. This is very effective against attacks but places a huge load on the software doing the authentication as you will essentially create multiple log-in attempts while cycling through the list of peppers. Another notable difference is that salting is usually unique per password, whereas peppering would use the same value, or one value of a list of peppers, for each password. The salt would be saved with the hashed password in the database, and the pepper would be in the codebase, in a secure key vault type of service. Unfortunately, this causes peppering to be more hardware intensive than salting, and the computational cost exponentially increases the more users you have. It also causes the login process to be much slower than salting due to the calculation processes. Salting best practicesWhen implementing salting as part of a password storage and hashing process, there are some best practices to follow:
You can also run the password through the hash algorithm multiple times. Salting with StytchInstead of trying to implement salting yourself, you can turn to Stytch to ensure your salting technique is thorough, advanced, and secure. Our new Passwords solution implements all of the best practices outlined above, offering the most secure, properly salted hash available. We wanted to ensure this password solution used the most efficient and secure hashing algorithm, so we’ve used Scrypt to support our salting and hashing algorithm. Stytch also provides breach detection, helping to prevent the use of credentials that have been compromised, and password strength detection, which makes sure that each link in the chain is as strong and secure as possible. This helps dramatically reduce account takeover risk. Since new ways are constantly being developed to hack passwords, one solution is to move away from passwords entirely. Stytch offers passwordless authentication, meaning users can use things like biometrics, OAuth, Magic Links, SMS and WhatsApp Passcodes, and other passwordless forms of authentication that keep your users — and your systems — secure. But if you’re not quite ready for passwordless, that’s okay! Stytch’s password solution is the most secure option available and will help keep your sensitive information safe. Protect your passwords with StytchSalting is a necessity when storing passwords, as it protects yourself as well as your users. It provides that extra set of uniqueness to a password and, in turn, makes the password exponentially more secure — on top of the base level of security that password hashing offers. Stytch uses best practices to ensure that the salts used are unique and that each password is properly hashed and secure. To see Stytch’s salting strengths in action for yourself, get started with Stytch today. What is used to make hashing more secure?What's the Most Secure Hashing Algorithm? SHA-256. SHA-256 (secure hash algorithm) is an algorithm that takes an input of any length and uses it to create a 256-bit fixed-length hash value.
How does hashed passwords keep data more secure?Using Basic Password Hashing
Password hashing add a layer of security. Hashing allows passwords to be stored in a format that can't be reversed at any reasonable amount of time or cost for a hacker. Hashing algorithms turn the plaintext password into an output of characters of a fixed length.
What is the best hash for passwords?To protect passwords, experts suggest using a strong and slow hashing algorithm like Argon2 or Bcrypt, combined with salt (or even better, with salt and pepper). (Basically, avoid faster algorithms for this usage.) To verify file signatures and certificates, SHA-256 is among your best hashing algorithm choices.
Which are the 3 security requirements that a secure hash functions should satisfy?Data Encryption
A cryptographic hash function must satisfy three criteria: Preimage resistance. Second preimage resistance (weak collision resistance) Strong collision resistance.
|
