System Design: How to store passwords in the database?

[@nemeziz_prime]

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 ❤️

[@NonTwinBrothers]

Bro when's your next movie coming out

[@jfolz]

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.

[@danielschmider5069]

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.

[@jfolz]

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

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

[@jfolz]

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

[@mhombach3035]

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.

[@NguyenTuan-ek1pv]

Short, concise, very straight forward You guys are so amazing.

[@singhabhay1810]

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.

[@JeremyChone]

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

[@yahayaoyinkansola8258]

This is so wonderful!, i never understood why people always salted their passwords and thought it was never important, now i do thanks to you!

[@ksuhdilla]

I love this man's voice. It's like a soft lullaby but he is feeding me information

[@RahulHasija39]

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.

[@gauravkumarmnnit]

Short and sweet yet to the point explanation, eagerly waiting for your new videos.

[@bazoo513]

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

[@simple-stack-by-ed]

Simple quality. This channel is one of my role models.

[@nathantorquato9777]

Please release a course on system design! Your content is amazing!

[@soundhermm5514]

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

[@ClipHiveCentral]

Without his linkedin post i wont be able to figure this brilliant and easy-catch presentation

[@ashishagupta]

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]

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

[@atabhatti6010]

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

[@mhombach3035]

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.

[@zoomzoom1889]

Excellent, well written scripts in easy to understand language. Keep doing these videos

[@riddhishchakraborty8529]

Explained in simple style. Informative.

[@manojamrutharaj9071]

Glad to see one of the Authors of the book making these excellent videos for us to understand. Thanks for your effort...

[@rishabhmaheshwari7788]

Very good and interactive session. And it felt great to see you saying thank you while doing namaste.

[@000bulit000]

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

[@liang3163]

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

[@nanotichorizon9644]

Elegantly explained. You are top class brother! The design of inputs as well as the representation of logic is concise and clear.

[@achintha8963]

I am really thankful to the KZbin algorithm for recommending this brilliant channel. Man, your content is to the point👌. Keep it up❤.

[@tigana]

Great video I appreciate how concise this was. Why isn't the salt hashed too for extra security?

[@codegreenie3429]

I am super happy because this is exactly how i store my customer passwords in my app database. Guess I am a good CS student afterall

[@RS-vu5um]

Very Clear and Crisp explanation. These videos are very helpful. Appreciate your work for the community.

[@RossiMurilo]

Great content! Super clean and straight forward. Well done!

[@Sanatanlif]

Learned again something new , Thank you Alex!! More power to you !! Keep helping as you are !!

[@sahibvirk]

Sir you are so brilliant and a very good teacher. Please, make more videos.

[@yacoubasawadogo8225]

Very well explained in a short video ❤

[@borkomne]

Great content, thank you! What software do you use to create animations? They are so clean and smooth, greatly adds to clarity of your explanations!

[@Julien-hg8jh]

I think he master Powerpoint :D

[@peterstedman6140]

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

[@Na4Ge4]

wish identity server 4 tutorials can be this easy to understand

[@manuelnovella39]

These videos really are amazing

[@drakezen]

I didn't know that you are the author of the system design book; I had bought it months ago. Great book!

[@anhquocnguyen1578]

amazing explanation and illustration. thank you

[@skhapijulhossen6499]

Easy peasy explaination. Brilliant Man! 🙌 We need more system design videos 🙏

[@JamesJansson]

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.

[@SanjeeviRajRC]

simple and clean explanation.

[@emmanuelespinoza2634]

I just discover your channel, it is pure gold man keep it going 🥰

[@TylerTriesTech]

What are you using to make the animated diagrams?

[@RameshJothimani]

Thanks a lot for this video! Simple, clear & excellent demonstration

[@Julien-hg8jh]

i love how you explain ! it can not be more clean and simple :D

[@theghostwhowalk]

Great series… N00b question: When the database gets compromised won’t salt be exposed as well? If so then p/w can be recovered ?

[@ashishjha9262]

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)

[@CyberMew]

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.

[@theghostwhowalk]

@@ashishjha9262 awesome makes sense. Thanks!!

[@theghostwhowalk]

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

[@CyberMew]

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

[@Alan_Dler]

Great video mate. thanks for the web101 review.

[@tvm73827]

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?

[@AlexRoxjar]

Some of the best videos I've watched on the topic!

[@liang3163]

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!

[@pratikchavan3603]

Pretty Good explanation 👏

[@parkershaw8529]

Thanks for sharing the knowledge! I learned something new today!

[@SayanInMoves]

very nice content. I love it. Just praying for more videos to publish soon.

[@joydey1794]

❤️ just what I was looking for

[@igor9silva]

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.

[@nikhilneela]

Wouldn't using https, already encrypt the contents in signup and login flow ?

[@igor9silva]

@@nikhilneela yes but on a different layer. HTTPS is fairly easy to decrypt when on the same network (using any regular sniffing software).

[@risingdamp220gaming6]

Such a great video! Amazing Delivery and top notch visuals!!

[@pobodjjd]

Precise and accurate! Thank you very much!

[@ProshnoKoutuhol]

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?

[@andreaspettersson3258]

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.

[@liquidpebbles]

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

[@GDScriptDude]

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

[@multiwebinc]

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]

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

[@multiwebinc]

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

[@shreerangakv7183]

Please do complete course on these topics.

[@stackunderflow5951]

We can also store the hash algorithm used in the database, which makes adapting to new algorithm easier.

[@kandisaganesh]

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

[@stackunderflow5951]

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

[@lawrencedoliveiro9104]

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

[@juloko]

Learned and subscribed.

[@9415868687]

Question: if user's password is weak and can be found in a common passwords DB? does salting still help? if yes, how?

[@evancombs5159]

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.

[@digvijaychauhan7312]

Wow great simple.Can you please tell what for we use pepper?

[@icesallowcome]

Just found this channel, it's dope. That's my dawg.

[@AungBaw]

Animation, quality & content improved video by video.

[@towb0at]

Really great videos on this channel, I enjoyed them very much even though I didn't look them up with the intent of learning something new

[@deepakdiipu6572]

bcrypt automatically adds salt to the password. We don't have to store the salt separately in database, it will be taken care by bcrypt in general

[@18something]

Great content, you got me with the Kafka one. Pls do more system design vids

[@neroamayo6345]

Brilliant. Please keep uploading videos.

[@sakthikumar4721]

One of the best tutorials. I love your videos awaiting for more.

[@Lucas-ne8xu]

Clear explanation. Please keep making these amazing videos.

[@daniel860305]

Can you elaborate on the precomputation attack? Thanks a lot!

[@DvACtOid]

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 .

[@sheikhAbdelrahman]

Nice and simple .. Thank you!

[@manieshsh]

Thanks for such crisp video. One question though. How will one store a password for a database in the same DB. ?

[@gpt_forever]

Thanks a lot! Very helpful information

[@aviksarkar8673]

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.

[@singhsandeep]

yes

[@Icmex70]

Yeah, but you need to concatenate password and salt before hashing.

[@MegaSascuach]

More videos please!!!!!

[@angel54268]

Amazing video Thanks

[@subee128]

Thank you very much

[@syedfaiqhaidernaqvi1031]

How does the encyption algorithm match the hash stored in database and the one entered by the user, as algorithms like bcrypt, argon2 etc generate different hash values for the same input each time???

[@TheHarimir]

nice explanation. it does leave me with one question: how abaut password recovery?

[@upulba]

Very nice explanation, quick question: why do we use salt when storing a password in the DB?

[@RajeshSharmaIndia]

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.

[@martindeveloper4856]

In the context of bcrypt hashing in Node.js, the hashed password stored in MongoDB might look like this: "$2b$10$rPaTHg7Gi6HYHjjctWWtXern7vSd1D6PtvNxBzYH4kxvM5k9eG5qi" Here's a breakdown of the different parts of the hash: - "$2b$": The "2b" indicates the algorithm used for hashing, which is bcrypt. - "10": This represents the "workload" or the number of rounds the password was hashed. A higher number of rounds increases the computational effort required to hash the password. - 22 characters: This portion represents the salt, which is a randomly generated value unique to each password. The salt is securely stored within the password hash itself. - 31 characters: This portion represents the actual hashed password, which is the result of applying the bcrypt algorithm to the combination of the original data (password) and the salt, repeated for the specified number of rounds. It's worth noting that in some tutorials or explanations, the term "salt" may be mentioned separately, leading to confusion when looking at the stored password hash in the database. However, in bcrypt, the salt is included within the hashed password string itself. Understanding this format can help clarify the structure of the bcrypt hash and how the salt is incorporated into the overall hashed password. If you have any further questions or need more clarification, feel free to ask!

[@noredine]

"password1" is a very commons pass, that's why I use "password2"

[@zixuanzhao6043]

so the validation process when first fetch the salt then hash the combination of pwd+salt, does this happen at the client side or server side?

[@deverasjk]

awesome video!!! if you it ok, could you make a video big O notation?? tyvm anyway!!

[@notreallyme425]

When logging into a website is the hash computed on the client or the server? In other words is the password sent over the Network to the server and the server computes the hash, or does the client computer accept the password, compute the hash, and then transmit the hash to the client?

[@rbelatamas]

cool, thank you!

[@cryptomania3553]

Amazing sir

[@Qwertzym0onsif]

Wow ! Thats really good explanation to such a complex thing ! Keep it up

[@kunliliu1875]

Very useful

[@panos9186]

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?

[@rajeswarigs2759]

when we add salt to the database entry, are we not exposing that to the attacker as well if they get db access ?

[@zerocool4360]

Amazing explanation. Everything makes much more sense now. What tool are you using to create such great animations?

[@peresola3885]

Thanks for the video! I can't quite understand slide in 2:15. Can someone help me understand? Thanks

[@Nathan17B]

Quality Content. Thanks my friend.

[@ashkanahmadi]

Great content thanks. The part that surprised me is storing the salt in the database. I thought that was going to be kept secret. If the salt is stored in plain text in the database, then if someone has the data, how does the salt stop the hacker? Don't they have access to a secret key in this point?

[@triffid0hunter]

A salt prevents the use of things like rainbow tables to just get the password (or a string that produces the same hash) out, unless the attacker has tables that include every possible salt value and the same salting scheme. It also prevents an attacker finding accounts that have the _same_ password.

[@BleachWizz]

That's what I thought... most methods would still work, like: Common characters; Common passwords; Simple brute force. It's only really hitting look up tables so you still need to guarantee you're using a good password probably generated not in your head... which already makes the addition of the salt useless. Now, because most humans don't generate passwords seems like it's actually really relevant to do so for them. I still think it's worth it to protect the salt, perhaps you could cripto it but I'm not sure how would you make it really safe in case of compromise while avoiding it being really dependent of something else.

[@butterfly7562]

@@triffid0hunter I think so, too. if you have a user's salt and hash value, then violently try a simple combination of password and salt to hash, and then hash pairs may still crack the password, so I think the core lies in two points： 1.Users still need complex passwords, allowing violent exhaustive attempts to fall into the cost of time 2. What really needs to be kept secret is the hash logic of the application, such as hashing with salt multiple times, or adding pepper (a confidential system environment variable).🧐

[@vasanthkorada4802]

thank you. waiting for more videos

[@antonioleon2350]

Hello, thanks a lot for this useful video. I have a question: In the first part of the video I understand that hashing is a slow and costly process, and in the second part of the video I see that when a user log in there is a hashing step. How is it fast when the user log in and the system perform hashing of the password inserted + the salt? Thank you :)

[@merukit]

a single hash can probably still be performed very quickly. I think the point about hashing with slow algorithm is that for a hacker to get the right password from the hash, they have to try hashing all possible passwords to see if that outputs the same hash (brute force), which will add up much more time with a slower hashing algorithm since many more hashes need to be computed

[@lawrencedoliveiro9104]

Cryptographic hashes are fast enough to run, say, millions of times per second. For password hashes, you want to slow that down to something more like a thousand times per second. That still makes no perceptible difference to a human user logging in, but it will throw a real spanner in the works of brute-force password-guessing systems. By the way, password hashing is useless if you want to do shared-secret authentication, where it’s not just the client authenticating to the server, but the server is also authenticating to the client. For that, you cannot avoid storing plain-text passwords on the server.

[@dhl4102]

What’s the appropriate hash function to use in real industrial

[@benmp4094]

This is top stuff, thanks for sharing