Man this guy is brilliant. He keeps uploading videos about stuff which has always left me perplexed. Plus these animations and short crisp videos are the perfect icing on the cake ❤️
In addition to a per-password salt you can also add a random, application-specific "pepper". It's hashed along with the password and the salt, but unlike the salt the pepper is not stored in the DB. A dump is useless without the pepper and an attacker would often need multiple vectors to obtain both.
@Cristiano Morgado unlike a salt the pepper should be considered a secret. Storing it on the machine (hardcoding, config file, ...) is an option if a bit risky. Since you probably don't want an admin to type it in on startup, a central key server would be the next most secure option.
@@juliansoto2651 peppers are secrets, though I wouldn't say they're on the level of an admin password. Since you should always use a salt as well the impact of a leak is very limited. Storing it locally in a file is probably fine, though a key server has some advantages when it comes to maintenance.
I think you misunderstood how a "pepper" is supposed to work :) A "pepper" is some short string that is added to the password while the hash is created, but that pepper is never stored anywhere. This way, your own server has to do a "tiny-bruteforce" on the users password when he tries to login. Since it's "tiny", it will only take a few ms, but for an attacker this will blow the timescale off. It's also more secure because for the pepper there can/should be used a small but very exotic pool of characters to choose from on the random generation. So you can take a few exotic ascii/unicode symbols for the pepper's character-pool and most attackers will "never" reveal the password if "only" the database was breached and not the server-code. Even if the server-code was also breached, the pepper would still force an attacker to waste more ms computation per iteration.
Binged watched all the videos.. though I knew about these concepts watching the simple yet accurate explanation was a pleasure. The graphics were simple and effective , my only complaint is I wish the video was longer with more content.
Very nice explanation. On top of password individual hash (stored in the DB), we also use an additional system wide salt, usually stored as a kubernetes secret property. This add another level of security. Also, we also use similar salt technic for the web token signature. Web Tokens embed their expiration, which is updated at each web request (typically as a http only cookie), and the third element is the signature using: ash(user_uuid + user_tsalt + global_tsalt). Also, we do NOT store credentials/access in the token, which is a longer conversation. So, a user row has a psalt column, for the password hash, and a tsalt for the token salt. Anyway, great vide, this is great to find this level of content on RU-vid.
You have amazing set of tutorials. Two things I would like to mention - What if someone steal the HDD containing this user database. They will have access to salt and bcrypt hash, they can start doing bruteforce attack. To address this issue - Should we also have bitlocker enabled on machine managing these passwords/sensitive information or Shouldn't we encrypt the hash by some common DB key for all the users or unique key of each user. Those keys then can be managed by some other service.
Very clear. A pointer or two to common attacks to which unsalted hashed passwords are vulnerable would be useful, just to shock a naive viewer a bit. BTW, I appreciate the fact that you never call an attack "impossible", not even "infeasible", but merely "unattractive".
Another advantage of using salt is that.. internal person who has access to db cannot identify if there are same hashes stored in database, that means two user have same password.
@@juliansoto2651 Yes. The same is true if a user repeated passwords across apps. If the attacker brings an old file of stolen password hashes to compare, the stolen hashes are useless against the new file made with different salts, even if the passwords are repeated.
It would have been nice if you had mentioned and explained "pepper" in addition to the "salt", which is the most modern and secure way of securing passwords :) Also, MD5 is not only "too fast", it's officially broken in way where mathematical collisions exist to narrow extract the original password pretty quick.
I love your short and highly informative videos. Here’s a suggestion for a video. How are passwords stored in a password manager or an application that accesses other password protected applications like a database?
Great content and animation, concise and easy to grapes. I couldn't complain anything. If ask for any improvement can be made is keep produce more content and make voice sound more energetic .
With hashed password with salt in the DB, in DB leak case - attackers has hashed password and salt on one dish. Then, the thing is to try different algorithms to decode it... I think it's like a house with locked door, but without one wall 🙂.
Great explanation. One thing I would like to add is that modern programming languages have hashing libraries available (e.g. for Argon2 and Bcrypt) and the salt is generated by the library and outputted as part of the hash, so you don't need to worry about trying to manually generate or store the salt.
@@Hauketal The point is that the hash, along with any other parameters used to calculate the hash, are part of the output string that these libraries generate. You don't need to specifically worry about or store the salt separately.
The easiest way to do this is Bcrypt. It stores all the information (password hash and salting information) in a single string in the DB. Lots of implementations across lots of programming languages.
This is used to prevent precomputation attack. Suppose attacker knows that SHA256 has been used in DB. He will compute SHA256 of all common word in dictionary and voila! User who used simple dictionary word as password are compromised. Now suppose DB administrator used salt for each row. Now attacker has to comuter SHA256 of all common dictionary word against each salt. Imagine 10M user or 10 million salt. He/she has to computer the SHA of all dictionary items 10 million times(As opposed to single time previously)
My understanding is this (please correct me if I am wrong, not security expert): The salted hashed value result (of salt and plain password) is stored along with the salt. Yes the salt is visible in plain text. However it is made much harder to crack the password since probably no rainbow table exists for it that can be used as the salt is random and unique per password (unless the attacker build their own table but it’s just further deterrence), so attacker has no way to easily look it up and instead has to try attacking it manually, password by password, restarting the crack each time per user, making it harder and deter efforts to crack it. Imagine your password is “1234”. It hashed to “ABCD”. Easily crackable. Now the backend does the salting for you behind the scene. So maybe it becomes hash(“ABCDrand0mSaltHeRe”). It’s harder to crack. The hash value is stored in the hash column along with the salt in the salt column. Again this is unique salt per user password. During login, client sends backend the password say “EFGH”. Backend will take it and together with the salt prestored for the username, does the hash check, if hash(“EFGHrand0mSaltHeRe”) == hashed_value_in_db. If you have the same salt for all passwords. Then it’s as good as as not using any salt. Any experts please feel free to correct me.
@@CyberMew agree to both of you, but when database is compromised, since we storing salt on the dB, won’t that be exposed per user too along with pw? So even if salt is unique per user, getPw for user I’d will give salt too?
@@theghostwhowalk I guess there is no foolproof prevention. You want to make life harder for attackers. The video mentioned bcrypt which is a slow hashing function which helps to waste attacker time. Rainbow tables are not readily available for each of the password+hash combinations (wiki has a good explanation on what rainbow table is). As Ashish Jha mentioned the computation is a lot when you try to crack it. Password by password. “a”+”salt”, “aa”+”salt”, etc. I guess it’s mainly to prevent easy cracking of password. It does not prevent the cracking of password. This is why you use a long and complicated password and that is always advised. Otherwise hackers can still crack it easily.
This design implies that the password will go as plain text through the network, before being hashed at the server. The technique I'm used to is: hash at the front-end (for both sign up and login), then re-hash it at the backend, including the salt and pepper. Very few milliseconds are added, and the password is never transfer as plain text.
During login, the scenario you described, where the communication between the client and server can potentially be intercepted by a third party, sending the password in plain text is not secure.
That is concise and brief explanation indeed so thanks. But then, how do you overcome a "pass-the-hash" attack where an attacker already has access to a DB (does not matter how) and then he/she can use hashed passwords from other accounts for a possible privilege escalation?
Nice can you explain in videos on backend best practices with solutions like password saving , you discussed in this video. Why we use Vault if in Database we can use security
Just to clarify myself.. that "Salt" is a randomly generated string that also stores in the db after hashing corresponding to the user. Correct me if I am wrong.
If the salt is stored in the database, what is the value in adding it to the password? The hacker can get the salt from the database (if it is compromised), and using pre-computation attacks they can hack the password and the salt?
It would still be quite safe to store it there as a pre-computation attack is based on known pairs. For instance, the md5 of "apple" is 1f3870be274f6c49b3e31a0c6728957f so an attacker would just do a lookup if the hashed password in the database matches 1f3870be274f6c49b3e31a0c6728957f and if it does, they know that the password is "apple". Adding a salt would make that table of known pairs useless as the salt is unique and would generate a unique hash that doesn't exist in any pre-computed table.
@@andreaspettersson3258 I see. So it prevents an attacker from scanning an entire table to find records with known hashes. But, if an attacker had the hash and the salt for each record, they could conceivable try to brute force each record's password by hashing common passwords appended with the salt from the record until they find a match or move onto the next record?
@@liquidpebbles Yes, if the data has any value to the hacker then they are surely going to spend a few minutes looking at the field names to look for a salt value field and try to spot a well known fingerprint of a data storage schema.
I have to say some points of the author are somehow misleading: 1. a global field pepper is enough for rainbow table attack(or any other brutal force attack) 2. unique salts for every user is for preventing extreme cases when two users set the same password, since you need to make every user's hash unique. This can ensure the hacker can at most decode only one user's real password even if he break the first layer security(the global field salt). Normally, you cannot just use "unique salts for every user" to prevent attack, because if the database is hacked, the hacker can generate the rainbow table to attack one user by using "his unique salt from database" + "a list of commonly used password from online". So the best way is using pepper + salt, an not-bad way is using pepper alone, while using salt alone is unsafe!
The salt is there to protect against a compromised database so the hacker can't just compare the hash in the database against known hashes to figure out the password. It doesn't protect against a compromised password.
