 I know what you're thinking. Adding salt to hashes sounds like the final step of a great breakfast recipe. But in cryptography, it means adding random data to the input of a hash function to guarantee a unique output, which is called the hash, even when the inputs are exactly the same. And in this video, you'll learn how adding a salt to your hash passwords adds a layer of protection. What's up everyone, my name is Will and I'm a developer advocate here at Off-Zero. Now while adding salt to your hash passwords can protect against different types of attacks, such as hash table attacks and slowing down dictionary attacks and protecting against brute force offline attacks, there are limitations of the protection that salting can provide. If the attacker is hitting an online service with a credential stuffing attack, salts won't help at all because a legitimate server is doing the salting and the hashing for you. Also, I want you to keep this in mind, never tell anyone on the registration form that another user has the same password as them. Having something like that in place will let attackers crack passwords in no time at all. Hash password is not unique on its own and that's due to the deterministic nature of hash functions. When you give a hash function the same input, you always get the same output. So if Alice and Bob were to choose the same password, don't poem me for, their output hash would be the same. So by looking at that table, we can infer that Alice and Bob have the same password because they have the same hash output. This allows an attacker to better predict the password that maps to the hash. Once the password is known then that password can be used to access any accounts that use the same hash. So think about this scenario. Let's say an attacker gets offline access to a database. This database has a table with user names and password hashes. After doing some digging, they find some duplicate hashes. From finding the duplicate hashes, the attacker can then assume that the passwords were hashed using a weak algorithm or they wasn't salted prior to them being hashed. If they find several users with the same hash, that's even better news for the attacker. It can indicate that the system has a default password and several users have opted in to use it. Before we get into talking about how you can salt your password, let's talk about the vulnerabilities of unsalted passwords. So one attack method that can be used is brute force attacks. Brute force attacks use trial and error to try out every different possible password combination until the correct one is found. A brute force attack isn't the most efficient way to crack a password, but you can get results with it nonetheless. You may be surprised at how fast a computer can brute force a seemingly complicated password. Another approach attackers can use is a dictionary attack. An attacker can easily compare a list of generated hashes from a set of commonly used words. For example, from the English dictionary, hence the name dictionary attack, they can compare those common words from the dictionary to the hashes that are in the stolen password. In every match that they find is a cracked password. Even though Alice and Bob chose the same password, they chose something that's fairly uncommon which is don't poem before. However, our friend Mike chose the word friendship which is actually an entry in the English dictionary. And this leaves Mike wide open to a dictionary attack. Now even though Alice and Bob use a word that's not in the English dictionary, they are still not in the clear. Attackers can use special dictionaries such as lead speak to crack passwords that are made from unusual words. So while attackers can crack passwords using different types of dictionaries, they also have another tool at their disposal called tables. Let's talk about cracking unsalted passwords with tables. Attackers have two type of tools at their disposal hash tables and rainbow tables. Both are more effective when used against unsalted passwords. A hash table is essentially a pre-computed database of tashes. They're created by taking random strings and the inputs of dictionaries as inputs for a hash function and then storing those inputs and outputs in a table. The attacker can then do a reverse password lookup by comparing the hashes in the table to those from a stolen password database. The main difference between a hash table attack, a dictionary attack, and a brute force attack is pre-computation. Hash table attacks are fast because the user doesn't have to spend any time computing the hashes. The trade-off for the increase of speed is the immense amount of space required to hold a hash table. And to keep things simple, we could say that a hash table attack is a pre-computed brute force or dictionary attack. Since time and space are limited, the attacker who designs and computes a hash table may want to process the most commonly used passwords first. This would put Alice and Bob at a much higher risk if Don't Pwn Me For is on a commonly used password list. Common password databases are created using frequency analysis across passwords collected from different publicly leaked breaches. The strength of hash tables come from volume, not computation speed. And the volume is huge, and each data breach continues to add to this volume. From a list of companies that have been breached, visit the Pwned Websites List at ihavebeenpwn.com. Faster CPUs, faster GPUs, distributed computations, and weak algorithms are making passwords easier to crack. Since cracking password hashes is more challenging than doing something like credential stuffing, it's always a good idea to use multi-factor authentication as another layer of protection. Alright, so you learned the vulnerabilities of using unsalted passwords and how that can open up your user's data to being attacked. So now, let's talk about the value of mitigating password attacks with salt. To mitigate the damage that a hash table or a dictionary attack can do, you need a way so that when users choose the same password, they don't get the same hash. One way to do this is to add salt to the hash password. According to the OWASP guidelines, assault is a value generated by a crypto graphically secure function. It is added to the input of hash functions to create unique hashes for every input, even if each input is not unique. Assault makes a hash function non-deterministic, which is great since we don't want to reveal duplicate passwords with our hashing. So let's say that we have a password form 1990 move and the salt finding Nemo. We can solve that password by either appending or pre-pending the salt to it. For example, form 1990 move finding Nemo or finding Nemo form 1990 move are valid salted passwords. Once the salt is added, we can then hash it. So let's see that in action. For pre-pending the salt, the salted input would be finding Nemo form 1990 move. And then after it gets ran to the hash function, this would be the result. So now let's take an example of appending the salt. The salted input form 1990 move finding Nemo and the hash result is this. This demonstrates the importance of using unique salts. Let's say that we always decide to append the salt to the passwords. If two users use the same password, we're just creating longer passwords that won't be unique because both of the salted passwords would hash to the same value. But if we choose another salt for the same password, we get two unique and longer passwords that hash to a different value. Let's visualize this through an example. So let's say that Alex and Bob decided to change their password and that they're both using form 1990 move. For Alice, we'll use finding Nemo as the salt and for Bob, we'll use finding Dory as the salt. Alright, so for Alice, we'll take her password form 1990 move with the salt of finding Nemo. The salted input is form 1990 move finding Nemo. And then once we run those through a hash function, this will be the hash result. So Bob, same password as Alice form 1990 move. His salt is finding Dory and the salted input is form 1990 move finding Dory. And then when you run that salted input into the hash function, this is the result. So Bob uses the same password, different salts, different hashes. So someone was able to look at the full list of hash passwords. They would not be able to tell that Alice and Bob use the same password. Each unique salt extends the password and changes it into a unique password. Also when a user changes their password, it should also generate a new salt. In practice, salts are stored in plain text in the database. For example, for finding Nemo, we will store the salt, the hash and the username together. So when the user logs in, we can look up the username, append the salt to the provided password, hash it and then verify if the stored hash matches the computed hash. Now you can see why it is very important that each input is salted with random unique data. When the salt is unique for each hash, we inconvenience the attacker. By now requiring them to compute a hash table for each user hash. This creates a big bottleneck for the attacker. Ideally, we want the salt to be truly random and unpredictable to bring the attacker to a halt. While the attacker may be able to crack one password, cracking all passwords would be unfeasible. When a company experiences a data breach, it is impossible to determine which passwords could have been cracked. And therefore, all passwords must be then considered compromised. A request to all users to change their passwords should be sent out right away. And of course, when that password is changed, a new salt should be generated as well. So now that you know how salting your passwords can mitigate a text, now let's talk about generating a good salt. Is finding Nemo a good salt? When we're adding salts to passwords, we need to add salts that are cryptographically strong and credential-specific. Following the OSWAP guidelines to properly implement credential-specific salts, we should create a unique salt with the creation of each credential. Having a system-wide salt is pointless to mitigate attacks. All that does is make the password super long. Using a system-wide salt lets attackers still be able to use hash tables. We should hash and salt each password that's created by a user. This includes passwords that are created upon registration, and of course, passwords that are created when you do a password reset. If the user happens to eventually cycle through their passwords and reuse one, we don't want to give any hints that the password has been used before. Strong cryptography defines a system that is resistant to cryptanalysis, which are efforts to decipher the secrets of a system. Showing that a cryptographic scheme is resistant to attacks takes a lot of time, extensive testing, reviews, and community engagement. Due to this complexity, security experts strongly recommend that you don't roll your own cryptography. To create cryptographically strong random data, you can use a cryptographically secure pseudo-random number generator. This will gather unpredictable input from sources that we cannot observe. For example, the Random Generator API of your operating system. Even better, we could use a battle-tested cryptographic library. Most of these libraries include facilities for working with random numbers. Again, never roll your own random number generators. As storage permits, you can use a 32 or a 64-byte salt. The actual size will actually depend on the protection function. A longer salt effectively increases the computational complexity of attacking passwords, which in turn increases the candidate set exponentially. A longer salt can also increase the space that's required to store a hash table while decreasing the possibility that such a table will exist in the wild. The security of this scheme does not depend on hiding, splitting, or obscuring the salt. To put it plainly, do not mess with the salt. Salts do not need to be encrypted. Salts are in place to prevent someone from cracking passwords, and can be stored in clear text in the database. However, do not make salts readily accessible by the public. Because of that, user names are bad candidates for using ass salts. Based on the guidelines, Finding Nemo, and that's written in a leapspeak type of way, is not generated from an unpredictable source. It's based on a popular animated movie, which could be used as part of a dictionary brute force strategy. Finding Nemo also doesn't meet the link requirements to be a salt, as it is only 11 bytes long. Our second salt, Finding Dory suffers from the same weakness. It's spelled out using a leapspeak type of manner and is based off of a popular movie and could be used using the dictionary brute force strategy as well. Our human imagination to create randomness can only go so far, so I believe it's best to leave it up to a machine. As we can see, salting and hashing are very complex processes, and the security of our systems greatly rely on their successful implementation. While there are no methods to create 100% secure systems, there are methods to create resilient systems, especially the creation, maintenance, and operation of such methods and systems to security experts. One misstep in a homegrown security solution may lead to extensive damage with your business, your users, and your reputation. You want to rely on algorithms such as Bcrypt, which hash and solve the passwords using strong cryptography. But also, you may want to use a security framework, such as Spring Security in the JavaScript ecosystem, for example. These frameworks offer you abstractions that make the development of your application safer and allow you to integrate with reliable identity providers such as off-zero would make sure identity and access management a lot easier. Alright, so let's do a recap. A cryptographic salt is made up of random bits added to each password instance before it's hashing. Salts create unique passwords even in the instance of two users choosing the same password. Salts help us mitigate hash table attacks by forcing attackers to recompute them using salts for each user. Creating cryptographally strong random data to use as salts is very complex and is a job better left to leading security solutions and providers. You can minimize the overhead of salting, hashing, and general password management with off-zero. We solve the most complex identity use cases with an easy to integrate platform. Thank you so much for watching the video on how to add salts to passwords. If there's any other identity topics that you would like for us to cover here on this channel, please let me know in the comments as I will be checking them. Thank you so much and see you next time.