Bro when's your next movie coming out

Yes, I personally find a pepper even better, because the DB is usually the primary attack vector. The pepper can be completely separate from the DB.

@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.

@Cristiano Morgado you treat a pepper the same way you handle any admin password. Unique and secretly stored.

@@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.

Their system design books are available in the market go for it.

Wow that's brilliant. That's a more convincing argument in favor of salts. They never made sense to me until now.

@@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.

Excatly, using only salts stored in db is actually unsafe, we need global level pepper anyway.

Seriously, the animations are smoother than anything most marketing coming out of big shops.

I think he master Powerpoint :D

He's said that they (it's not a solo venture), use a mix of products including photoshop and illustrator

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.

@@ashishjha9262 awesome makes sense. Thanks!!

@@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.

Bad idea, in case db is compromised you are exposing hash algorithm which can help attacker?

@@kandisaganesh Even if the attacker knows the hash algorithm, it's still impossible for them to calculate the original value based on hashed value.

The *nix shadow file does exactly that -- the password hash begins with a prefix indicating which algorithm was used.

You will have to store the salt in the database, because only then you can have enough entropy to make rainbow tables unfeasable.

@@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.