This has got to be one of the best Python channels on UA-cam. Really great material, interesting topics, in-depth but not overwhelming, and not sensationalized but still engaging. Keep it up!
To recap, use a pot to bake some varied sprinkling of salt, a single non-locally sourced twist of pepper, over some hash pwns. But also keep your kitchen clean to avoid leaks. Happy cooking!
I once heard about peppers in a slightly different way: when initially saving a password, a very short (1-2 characters) random sequence (pepper) is generated and hashed together with the salt and password. the pepper is not saved anywhere at all. when verifying the password, the application itself has to "crack" the password by trying all the possible peppers. this increases password validation time by a factor of x (e.g. 26 for a single lowercase letter) which should be neglible (anything below 500ms is completely fine). however, this also increases the time needed to crack the password by the same factor, making it much harder for an attacker to crack the password offline
Yes i've heard of this use before. It's still called a pepper since it is randomness not stored in the db. This also avoids the need to distribute the pepper to each server. Personally i'm not a fan of using pepper in this manner. In my opinion, using a pepper this way signals that you (not you personally) are using this as a crutch because your hash function is bad (not suitable for hashing passwords). A secure password hasher like Argon2id, bcrypt, or scrypt will have a configurable parameter for how slow to be, and you should just increase this parameter if you want your hash to be slower.
@@mCoding yeah that makes sense. using the built-in "slowification" is probably way better (more efficient and secure) than trying to add it later. I think the article was even using md5 as an example, so your point about compensating for weak hashing functions is spot on :D
Using a hash function with a sliding computational cost will be much more consistent. Generating random short character sequences means some of them (like "aa") will get cracked much quicker than others.
@@vojtechstrnad1 While that's true, it's already the case that brute force attacks are more or less uniformly distributed in running time. The fact that "aa" will get cracked quicker is moot because even without any random pepper sequence 1/26 of passwords will be cracked in the first 1/26th of the expected time, 1/26^2 in the first 1/26^2 time, etc.
Python is not a language I usually work with but this channel is just so interesting and its teachings are so horizontal to most programming language that i can not stop watching it 😂
Never knew about peppers before! You mentioned that peppers could be stored in a "secure memory enclave." What is a secure memory enclave, and how would it be different or more secure than the database? (Also, Discord gang)
A secure memory enclave is some memory, typically in a dedicated separate chip on the motherboard or even on the cpu itself. This memory is segregated from normal memory and it typically cannot even be addressed. It does not have an addressable location in memory that the operating system can directly access. It can only be accessed through a limited api. This makes it more secure because classes of attacks like buffer overflows and stack or heap busting cannot be used to access this memory. It's not failsafe, but it's just another extra layer of security.
@@spicybaguette7706 TPMs currently have a number of similar use cases, such as storing encryption keys for full-disk encryption. I'm not sure if a TPM could out-of-the-box (or maybe off-the-mobo would be a better expression in this case) be used for storing a pepper, but it probably could be used that way.
Use a unique, strong password for every site and service? Yeah. I do that. It’s called a password manager. A glossary term: Precomputed hashes are called rainbow tables, and by now the ones available are _massive._ Just a hash should be considered as bad as plaintext. This was a fantastic explanation of password hashing, salts, and peppers. Very good for everyone to know these things.
Maybe I should have said "what percentage of your users do you think actually do that?". My audience is of course full of programmers who probably do actually use password managers :) I'm aware of rainbow tables, which are a specific way to store precomputed hashes, but I think that mentioning them was better saved for another video.
This channel is so consistently excellent in that you provide very clear, succinct and approachable introductions to each topic you cover. Absolutely fantastic. Great explanation of the utility of salts
@@mCoding That's unfortunate! Maybe your video will help evoke some change. I had honestly never even heard of that before watching this. I had, however, heard of (and used) salted passwords.
1:11 - As someone whose been writing Python code for 11+ years, one of the new changes to Python3 that always surprises me when I see it is type-hinting. After learning Java a few years ago, I understand the appeal and the benefits, but if you want actual static typing, Cython seems a more robust answer.
Thank you for videos - it one of best (if not the best) channels i've seen for intermediate-advanced python, and importantly, introducing functionality or ideas that are not commonly used. Importantly, it is also very short and sweet, and cuts to the chase. Really well done!
Thank you! This was a very good, clear explanation of salts, peppers, and password hashing! Hopefully peppers have gotten more library support in the past year since you made this video.
On the (definitely correct) bit at the end where you talked about how you should never handle passwords yourself if you can help it, just use a well tested open source implementation. Is there any reason you couldn't still implement peppers even if your open source password handling system of choice doesn't by simply mixing it in with the users password yourself before you send the password off to the open source password handler?
Thank you for this video. Another security, which I think should be brought in any case, is that you should save the salt in its own column. Currently you save everything in one column. This means that if a potential hacker gets the hash of the password, he can immediately get the salt as well. But if the salt is stored in a separate column, the hacker must also be able to get to the column with the salt. This increases the security a bit.
There's also a weaker version of peppering that's easier to maintain and increases security. You DO store the peppers in your database (globally), but there are many of them. Like 10 or 20 or 30. You do not store the pepper used for each user, just all the peppers available. As the server application, you might have to iterate through all 30 peppers to verify if an entered password is correct or not. However, the attacker now has to perform 30 times more work per each brute force attempt as well. That makes it a very good security measure.
As mCoding states below, this indicates a poor security measure, as all you want to do here is just increase time taken per password, which can be done by choosing a difficult hashing function.
I don't know *anything* about cryptography, but that is now slowly changing. It's interesting the clever defensiveness you need to take to protect against hackers. Another solid vid!
I think the hash algorithm argon2 supports peppering, though I'm not sure. Even though, it's still a really good hash algorithm for passwords specifically. There are tree versions of argon2, argon2i, argon2d, and argon2id. I can't exactly remember which of the ones are for what, but I know that either I or D are for to protect against side-channel timing attacks, and the other is for more speedy hashing, and both (argon2id) is for both, it's pretty cool
Argon2id is the currently top recommended secure way to hash/salt, and it is built on the blake2 hash that I used in this video. It does not explicitly have a parameter for pepper, but you could just append the salt and pepper and use that in argon2id's salt parameter, or you could put the pepper in the associatedData parameter ("optional arbitrary extra data"). Looking at the source for argon2id, all it does with the password, salt, and many of its other parameters is append them and their length to the initial buffer, as in ... ∥ Length(password) ∥ Password ∥ Length(salt) ∥ salt ..., and it doesn't use them in any other way. However, I'm not in a position to recommend doing such a thing since I'm not an expert cryptographer. I would wait until expert cryptographers explicitly add support for it or make recommendations about how to incorporate peppers.
The salt doesn't necessarily allow a bad actor to easily crunch hashes offline; if you have a minimum password length of 6, that's 7 locations you could insert the salt. Obviously if they figure it out, they can still crunch offline, but if there's a secret algorithm that determines the location of the salt based on some other factor on a per user basis, the hacker would have to try every single one to get a single password.
A workaround for pepper is add it to the password just when hashing. Or, to add it to the salt, changing that operation (though then you need to vet your code to make sure it's still secure)
Couldn't the hacker create an account by himself, search for his profile entry in the leaked database, and then start cracking the pepper on his local machine? Or is the pepper so secure that it would take millions of years to crack?
If a weak pepper was used this attack could be viable, but finding a value with a given hash (called a preimage) is thought to be practically impossible even for many weak hash functions like md5, let alone modern secure hash functions.
I feel like XORing the pepper over the hashed password and salt would be more secure than concatenating into the password before the hash. Probably more performant too, though you have to then separate the b64 encoding step.
With an ideal hash function there is no difference. With cryptographically secure hash functions there is no practical difference. The hash function mixes the bits of the salt over the entire result already.
I'm not sure I understand the pepper. If it's possible to put it somewhere that is accessible by the servers doing the authentication but out or reach of hackers/discontent employees, why not put the whole database there and be done with it?
Excellent question. The extra security from using a pepper doesn't come from the fact that it is necessarily out of reach of hackers (although using a secure memory enclave does add an additional layer of security), it comes from the fact that it is stored in an additional place that a hacker would need access to at the same time as the database. A hacker who hacks a database probably doesn't get access to the application code or the server actually running the application. A hacker who hacks the application server doesn't necessarily get access to the database. It usually wouldn't be possible (or desirable) to store your entire database on the application server for space reasons, but even if you did do this you wouldn't gain extra security from it because all the password information is still stored in just one location. Using a pepper is a simple way to split the information that a hacker needs in multiple places, making their job more difficult. If the hacker succeeds in hacking the database but is caught before they are able to hack an application server, then they aren't able to hack users. If they hack both the db and application before getting caught, then they have the salt, pepper, and hashes, and can start cracking weak passwords.
@@mCoding I see, thanks. So it's like using two bike locks rather than just one: it's not that the second is necessarily better than the first, but it just doubles the number of barriers that have to be broken.
Shouldn't the pepper used, be somehow indexed like (with?) the encryption algorithm used? Because in the example the code I see no way to deal with pepper change, besides discarding the entire old database... For instance, instead of 'blake2b' could one append a descriptor 'scheme1' or something, that is known somewhere else to be blake2b + pepper version yyyy-mm-dd? That way if the current pepper leaks, the system still has some way to identify the "compromised" (weakened) passwords info and to migrate away to a new pepper (Just start using a 'scheme2')
Indeed, all extra params of the algorithm and other information you will have to stuff into the name part of the password. Something like blake2b:50:100:2$salt$hash. For blake2b with 50 rounds, 100 memory, pepper v2.
So could adding the pepper conceivably be done in hardware? If it can completely avoid the main CPU, with that part of the hash implemented in a chip that can't be reprogrammed, that can't be broken right? (Not to say "unhackable", I've learnt that's a dangerous term)
Conceivably yes, the whole hash could be done on a dedicated chip that automatically adds the pepper in, but I would be surprised if there were any actual implementations of this given the cost to benefit ratio.
It must be said that once you hash a password, no mutual authentication can happen and the password can be taken by a compromised server. Security comes from making sure the box called authentication server is isolated from the web server (which should be assumed to be likely to get compromised)
It's not just the web (application) server access you need to worry about. There are more passwords in the standard "leaked password" dictionaries out there that were leaked by insecure disposal of disk drives than there are from, say, SQL injections, etc.
This is wrong. mutual authentication happens from the server by just providing the hash and the client hashing their own password to check against that hash. The authentication for the server works the normal way where the client provides the password and the server hashes it and compares it to it's own hash. In both cases only someone who is party to the original secret can pass this verification.
No it's not trivial. It is the same time complexity as just trying that password for every user. Sure you can do it offline but it will take a long time, which is the point. No password is 100% secure even if the attacker has no prior knowledge since all of them can be cracked given enough time. The point of all of this is to cost enough time to not make it worth it.
I don't know much about web server design, so maybe my question is ill-posed. If I understand correctly, the hashing etc. happens server-side, otherwise the salt and pepper would need to be sent to the client and that sounds like a terrible idea. Then my question is: is it possible that plaintext passwords could still be inadvertently saved in log files somewhere? Or is it bad practice to log every POST request?
Yeah, server administrators do typically log all or most requests, but the log would only include that it was a post request to the login page or whatever, the actual data from the request should not be stored in a log. Logging all post data would be a storage waste so most admins wouldn't want to do this in the first place, but additionally it would be a big no-no to store any sensitive client data in a log file, especially passwords. I'm sure that some company has made this mistake and leaked data this way before though. Security is hard to get right, and oh so easy to get catastrophically wrong.
Always wondered if using the non-changeable ID of a user would be enough as a salt or if it should be a totaly seperate like you did in your video. I suppose yes, but that feeling of just using the ID keeps nagging me.
Concatenating salt and password is probably bad practice because many hash functions are vulnerable to length extension attacks (en.wikipedia.org/wiki/Length_extension_attack), including sha-2 and its variants. If a good hash function is used then this is probably okay, but most sites still only use one round of a weak function like sha256...
It is always a good idea to use well-proven open-source libraries rather than doing it yourself. Modern secure methods of hashing passwords, like Argon2id, typically do something to incorporate the length as well, like salt + len(salt) + password + len(password) + other params + len(other params) + ..., which prevents any kind of length extension attack.
So salt is stored in the database, pepper is stored in the code or in a secure memory enclave... Why not calling only the one in the code pepper so we could also have spices in the secure memory so all 3 parts of the site have to be leaked instead of 2 ?
It's very possible this kind of thing gains support in the future, storing spices on many different places to increase security, but the incremental benefit of a third spice is much less than salting and peppering, so it probably won't become popular in the near future. I.e. the extra security from needing 3 simultaneous hacks vs just 2 simultaneous hacks is not worth as much. As soon as even 1 hack occurs, you should re-salt and re-pepper everything.
I have a cuestion about de declaration of variables. In the video you typed "password: str", that means that variable will only accept strings or it's just something for you to remember the variable class?
It means that the variable is intended to be a string, but these type hints are nit enforced at runtime so it is mainly for the reader of the code to help understand.
So for the pepper-part, if nobody has included that yet, would it be possible to just add my pepper in front of every password I save and retrieve (making it a longer password) so that I then could use normal cryptographic functions that have pepper not yet implemented or should I wait for my preferred function to include it (if it not has already)?
Checking whether two passwords are the same is unfortunately very useful because people tend to use very weak passwords. Go through the hashes and look for the most common one, which will be about .5% to 1% of your users. All those users' passwords are 'football'. Ok password policies etc. can lower the percentage who have the same pass, but but you will still see a lot of users with the same password, which would then tell you who to start guessing weak passwords on. There's more discussion of why pepper without salt is not as good in the link in the descriptiom on crypto.se.
I guess you could argue it's a backup i.e. in that rare evnt that the pepper gets found out, it's the same as if you only hashed the password. at least, concerning the issues brought up in the video.
You say that "because an attacker knows the salt, they can try to crack the password offline". Is this really true? In the example, you append the salt to the beginning of the password before hashing it, but the attacker doesn't know that. You could append it to the end, interweave it into the password, multiply them together as numbers, or any custom function you can think of to incorporate the salt into the password. Is there a reason this isn't done?
Great question! What you are describing is called "security by obscurity". Although it is good intentioned, it is generally frowned upon. Yes, you can do something nonstandard like interweaving the salt into the hash and that very well may trick some attackers. However, this is also dangerous because in being creative this way, people will often unknowingly break some security property, making it easier for the attacker. If you want to waste more of the attacker's time, use a stronger slower hash function, don't risk messing up an existing system. As for cracking the password offline, if you want to make sure there is no chance of the attacker being able to attempt offline cracking, use a pepper as suggested in the video! Both the pepper and interweaving salt ideas could be thwarted if the attacker gains access to the application code, but the pepper cannot be thwarted if the application code remains safe, whereas something like interweaving salt an attacker could potentially figure out using a number of techniques (e.g. hash some common passwords and look for statistical correlations of those hashes with the leaked db hashes, this would thwart any permutation-based approach like interweaving salts).
@@mCoding I suppose it's true that, to change how the salt is applied, you'd likely have to run your own auth library, or at least override a part of an existing one, which you're completely correct in saying could undermine the security somehow. I think if, for some reason, you had to roll your own, it would theoretically be better to do something like that than not - security *augmented by* obscurity is never *worse* - but yeah, if you're in a position where you have that much control, using a pepper accomplishes the same thing while being more secure. Thanks for the response!
Most websites would not let the hacker make more than a few incorrect guesses before ignoring further attempts, however, even if the attacker was allowed to make as many guesses as possible, the fact that the pepper is a randomly generated long string means that the hacker will not be able to guess the pepper anyway.
Yoy certainly could do that. However, email is generally not considered secure, so this approach is not recommended. Additionally in that case the email link itself is effectively acting like a password.
I have seen some tutorials who generate the random salt, add it to the password and then hash it(instead of hashing the password then adding the salt), then store the salt (before it was hashed) and the hashed password and use it to make the comparisions for login, etc. Also, can I store the salt in another table?
The salt is added before hashing, not after. A salt would be useless if it was only added into the string after hashing. What may have confused you is that the salt is stored alongside the hashed(password + salt), but this is purely a convenience and efficiency hack since the salt and hash will always be needed together. The salt could be stored wherever you want in the database, but since it's only purpose is to be used with the hashed password at login time, it is very common to store them in the same field.
Just for clarification: couldn't I just pick certain things about each user (e.g. username and age) (obviously always the same attributes) and put that into the hash with the password?
There is typically only one pepper for the whole application so it cannot depend on user data. What you describe is a method of changing the salt. Yes, you could append something like user email to the salt, but why? You would then need to rehash the password (and hence require the user to enter their password) in order to change their email, and it doesn't seem to provide any benefit since this data would still be available to the hacker in the event of a leak since it is stored in the database.
Then wouldn’t the relevant attack then be to change the pepper into something known, changing the password/salt/pepper problem into the solved password/salt problem?
Is there a reason I'm missing for not using only the hash function (as opposed to requiring additional libraries)?i.e. concatenate the salt, pepper, and pw and hash them as one
What additional libraries are you referring to? Do you mean using the compare digest instead of ==? Or do you mean why base64 encode? The former is to prevent againsy timing attacks. The latter is to make it easier to print out and to make using the $ separator safe.
@@mCoding at 8:05 you mentioned that "most libraries don't support peppers". I was just saying I don't understand why you'd need "support" and couldn't just concatenate your input strings (with $, for example) and pass it to a hash function. What additional support would you need from a library?
Ahh yes, I see what you were asking now. I think it would be totally fine to just plug in the pepper the way you mentioned. However, for password hashing you want a specific kind of slow hash function, so things like sha256 are out. You want how slow it is to be configurable, which is something that Argon2id, bcrypt, and scrypt all offer. Additionally, I am not a cryptography expert and my word is close to worthless for such a critical part of your application. Historically speaking, it is extremely easy to try to "get creative" with a cryptography tool and end up accidentally subverting one of it's security properties or allowing for a class of attack that you never considered before. As a non-expert, I know I'm not qualified to do anything beyond using a prebuilt system like Aegon2id exactly in accordance with it's documentation (which explicitly mentions salt but not pepper), and therefore I cannot in good conscience recommend even the most trivial creative deviations to my viewers.
I thought this too. But it's probably because email is usually used as a login and identifier of the user. And not being able to search for users base on a unique identifier would be a nightmare for support teams. Emails are also more convenient for users than some unique ID or a nickname.
Another good practice is to hash the passwords multiple times instead of one, using a computationally heavy hashing algorithm (hash(hash(hash(...hash(password)))). The goal is to make it significantly harder for an attacker to be able to crack passwords offline, in case you dont use pepper or if the pepper is leaked as well. Cracking a hash for which you have the salt the pepper and the algorithm is actually quite easy and fast for weak passwords. Using the multiple hashes, it would make it much much more time consuming, and potentially unfeasible for the attacker to actually crack passwords this way.
Just use the inbuilt functions in the hash algos to do that instead. Do not get creative with cybersecurity tools unless you yourself are an expert in the field.
This has got to be one of the best Python channels on UA-cam. Really great material, interesting topics, in-depth but not overwhelming, and not sensationalized but still engaging. Keep it up!
Thank you so much! I really appreciate comments like yours! Kind words keep me going!
To recap, use a pot to bake some varied sprinkling of salt, a single non-locally sourced twist of pepper, over some hash pwns. But also keep your kitchen clean to avoid leaks. Happy cooking!
You got it!
I once heard about peppers in a slightly different way: when initially saving a password, a very short (1-2 characters) random sequence (pepper) is generated and hashed together with the salt and password. the pepper is not saved anywhere at all. when verifying the password, the application itself has to "crack" the password by trying all the possible peppers. this increases password validation time by a factor of x (e.g. 26 for a single lowercase letter) which should be neglible (anything below 500ms is completely fine). however, this also increases the time needed to crack the password by the same factor, making it much harder for an attacker to crack the password offline
Yes i've heard of this use before. It's still called a pepper since it is randomness not stored in the db. This also avoids the need to distribute the pepper to each server. Personally i'm not a fan of using pepper in this manner. In my opinion, using a pepper this way signals that you (not you personally) are using this as a crutch because your hash function is bad (not suitable for hashing passwords). A secure password hasher like Argon2id, bcrypt, or scrypt will have a configurable parameter for how slow to be, and you should just increase this parameter if you want your hash to be slower.
@@mCoding yeah that makes sense. using the built-in "slowification" is probably way better (more efficient and secure) than trying to add it later.
I think the article was even using md5 as an example, so your point about compensating for weak hashing functions is spot on :D
Using a hash function with a sliding computational cost will be much more consistent. Generating random short character sequences means some of them (like "aa") will get cracked much quicker than others.
Call it Paprika
@@vojtechstrnad1 While that's true, it's already the case that brute force attacks are more or less uniformly distributed in running time. The fact that "aa" will get cracked quicker is moot because even without any random pepper sequence 1/26 of passwords will be cracked in the first 1/26th of the expected time, 1/26^2 in the first 1/26^2 time, etc.
Python is not a language I usually work with but this channel is just so interesting and its teachings are so horizontal to most programming language that i can not stop watching it 😂
Thanks so much!
I love these security videos, they're awesome! I'm really learning a lot! Thanks mCoding!
Great to hear!
Never knew about peppers before! You mentioned that peppers could be stored in a "secure memory enclave." What is a secure memory enclave, and how would it be different or more secure than the database?
(Also, Discord gang)
A secure memory enclave is some memory, typically in a dedicated separate chip on the motherboard or even on the cpu itself. This memory is segregated from normal memory and it typically cannot even be addressed. It does not have an addressable location in memory that the operating system can directly access. It can only be accessed through a limited api. This makes it more secure because classes of attacks like buffer overflows and stack or heap busting cannot be used to access this memory. It's not failsafe, but it's just another extra layer of security.
@@mCoding like a TPM?
@@spicybaguette7706 TPMs currently have a number of similar use cases, such as storing encryption keys for full-disk encryption. I'm not sure if a TPM could out-of-the-box (or maybe off-the-mobo would be a better expression in this case) be used for storing a pepper, but it probably could be used that way.
@@mCoding So what would happen if the pepper were somehow leaked?
@@danielf.7151 It would then still be just as secure as a database with just salt. Not terrible, though you should probably find a way to change it...
Use a unique, strong password for every site and service? Yeah. I do that. It’s called a password manager.
A glossary term: Precomputed hashes are called rainbow tables, and by now the ones available are _massive._ Just a hash should be considered as bad as plaintext.
This was a fantastic explanation of password hashing, salts, and peppers. Very good for everyone to know these things.
Maybe I should have said "what percentage of your users do you think actually do that?". My audience is of course full of programmers who probably do actually use password managers :)
I'm aware of rainbow tables, which are a specific way to store precomputed hashes, but I think that mentioning them was better saved for another video.
chad security: just hash it, if someone has a password that can be cracked within a year its his their own fault
edit: this comment is not a joke
ultimate chad security: properly secure emails instead of passwords
unlimited chad security: just outsource any logins to passport accounts like google
galaxy chadmaster security: don't use passwords, don't use websites at all. Move to Tibet and free yourself from earthly attachments.
Hey that's pretty cool. I've never heard of peppers before. Learned something new today!
Great to hear! Keep learning!
This channel is so consistently excellent in that you provide very clear, succinct and approachable introductions to each topic you cover. Absolutely fantastic. Great explanation of the utility of salts
2:28 - Laughs in Bitwarden
Huh this video was released just now. How did you comment 20 hours ago?
@@saadjadoon6397 hacks
@@saadjadoon6397 Patreon supporters might have early access
@PyMaster Patreon gang gets early access!
Same, Bitwarden is awesome
Another fantastic video! I learned a lot. Hopefully more frameworks will support pepper soon. That's a really interesting trick.
I was surprised researching that so few libraries support peppers!
@@mCoding That's unfortunate! Maybe your video will help evoke some change. I had honestly never even heard of that before watching this. I had, however, heard of (and used) salted passwords.
I hope you can make a sequel to this video discussing algorithms like SHA, Bcrypt, Scrypt and the differences in using them for authentication
but is the salt Kosher, and is the pepper freshly ground?
1:11 - As someone whose been writing Python code for 11+ years, one of the new changes to Python3 that always surprises me when I see it is type-hinting. After learning Java a few years ago, I understand the appeal and the benefits, but if you want actual static typing, Cython seems a more robust answer.
Great video, this is the first time that I actually understood the concepts of salt and pepper
Thank you for videos - it one of best (if not the best) channels i've seen for intermediate-advanced python, and importantly, introducing functionality or ideas that are not commonly used. Importantly, it is also very short and sweet, and cuts to the chase. Really well done!
Thank you very much!
This was very informative! Thanks!
Glad you enjoyed it!
here from the community post. for some reason, youtube is really good at recommending those but not videos 🤔
I guess i need to make more polls!
I have heard of pepper before, but I completely forgot what it was, and this video was helpful to me
Very interesting stuff, good to know!
Thanks for watching!
Thank you! This was a very good, clear explanation of salts, peppers, and password hashing! Hopefully peppers have gotten more library support in the past year since you made this video.
Haha nope 😅 but glad you enjoyed!
On the (definitely correct) bit at the end where you talked about how you should never handle passwords yourself if you can help it, just use a well tested open source implementation. Is there any reason you couldn't still implement peppers even if your open source password handling system of choice doesn't by simply mixing it in with the users password yourself before you send the password off to the open source password handler?
what I was thinking as well
me too
You reckon faang companies will pickup using peppers in the near future?
Some of them probably already do.
Coming up next - mint leaves ;)
Peppers seems such an simple obvious idea, yet so novel, huh?!
Thankful to UA-cam that I found you channel :)
Thanks for watching!
Thank you for this video. Another security, which I think should be brought in any case, is that you should save the salt in its own column. Currently you save everything in one column. This means that if a potential hacker gets the hash of the password, he can immediately get the salt as well. But if the salt is stored in a separate column, the hacker must also be able to get to the column with the salt. This increases the security a bit.
There's also a weaker version of peppering that's easier to maintain and increases security.
You DO store the peppers in your database (globally), but there are many of them. Like 10 or 20 or 30. You do not store the pepper used for each user, just all the peppers available.
As the server application, you might have to iterate through all 30 peppers to verify if an entered password is correct or not. However, the attacker now has to perform 30 times more work per each brute force attempt as well. That makes it a very good security measure.
As mCoding states below, this indicates a poor security measure, as all you want to do here is just increase time taken per password, which can be done by choosing a difficult hashing function.
This was an incredibly well-explained video. Thank you!
Was actually reading into salting in bcrypts for a personal project recently so definitely gonna use this as a resource. Great vid as always!
I'd never heard of peppers before this. Really informative
I don't know *anything* about cryptography, but that is now slowly changing. It's interesting the clever defensiveness you need to take to protect against hackers. Another solid vid!
Thanks so much, always great to hear from you!
Greatly explained each of the case!
Thanks!!
I think the hash algorithm argon2 supports peppering, though I'm not sure. Even though, it's still a really good hash algorithm for passwords specifically. There are tree versions of argon2, argon2i, argon2d, and argon2id. I can't exactly remember which of the ones are for what, but I know that either I or D are for to protect against side-channel timing attacks, and the other is for more speedy hashing, and both (argon2id) is for both, it's pretty cool
Argon2id is the currently top recommended secure way to hash/salt, and it is built on the blake2 hash that I used in this video. It does not explicitly have a parameter for pepper, but you could just append the salt and pepper and use that in argon2id's salt parameter, or you could put the pepper in the associatedData parameter ("optional arbitrary extra data"). Looking at the source for argon2id, all it does with the password, salt, and many of its other parameters is append them and their length to the initial buffer, as in ... ∥ Length(password) ∥ Password ∥ Length(salt) ∥ salt ..., and it doesn't use them in any other way. However, I'm not in a position to recommend doing such a thing since I'm not an expert cryptographer. I would wait until expert cryptographers explicitly add support for it or make recommendations about how to incorporate peppers.
This is very knowledgeable, im glad i found this channel
Welcome aboard! Thanks for the kind words!
Awesome explanation! Finally these obscure terms make sense.
Thank you so so so much!! This this the best vid about paper and solt so far. Keep it up
The salt doesn't necessarily allow a bad actor to easily crunch hashes offline; if you have a minimum password length of 6, that's 7 locations you could insert the salt. Obviously if they figure it out, they can still crunch offline, but if there's a secret algorithm that determines the location of the salt based on some other factor on a per user basis, the hacker would have to try every single one to get a single password.
Great! A clear example of how Salt and Pepper work.
A workaround for pepper is add it to the password just when hashing. Or, to add it to the salt, changing that operation (though then you need to vet your code to make sure it's still secure)
Couldn't the hacker create an account by himself, search for his profile entry in the leaked database, and then start cracking the pepper on his local machine? Or is the pepper so secure that it would take millions of years to crack?
If a weak pepper was used this attack could be viable, but finding a value with a given hash (called a preimage) is thought to be practically impossible even for many weak hash functions like md5, let alone modern secure hash functions.
I feel like XORing the pepper over the hashed password and salt would be more secure than concatenating into the password before the hash. Probably more performant too, though you have to then separate the b64 encoding step.
With an ideal hash function there is no difference. With cryptographically secure hash functions there is no practical difference. The hash function mixes the bits of the salt over the entire result already.
I'm not sure I understand the pepper. If it's possible to put it somewhere that is accessible by the servers doing the authentication but out or reach of hackers/discontent employees, why not put the whole database there and be done with it?
Excellent question. The extra security from using a pepper doesn't come from the fact that it is necessarily out of reach of hackers (although using a secure memory enclave does add an additional layer of security), it comes from the fact that it is stored in an additional place that a hacker would need access to at the same time as the database. A hacker who hacks a database probably doesn't get access to the application code or the server actually running the application. A hacker who hacks the application server doesn't necessarily get access to the database. It usually wouldn't be possible (or desirable) to store your entire database on the application server for space reasons, but even if you did do this you wouldn't gain extra security from it because all the password information is still stored in just one location. Using a pepper is a simple way to split the information that a hacker needs in multiple places, making their job more difficult. If the hacker succeeds in hacking the database but is caught before they are able to hack an application server, then they aren't able to hack users. If they hack both the db and application before getting caught, then they have the salt, pepper, and hashes, and can start cracking weak passwords.
@@mCoding I see, thanks. So it's like using two bike locks rather than just one: it's not that the second is necessarily better than the first, but it just doubles the number of barriers that have to be broken.
I love this man and the way he explains things
thank you for these very important informations
keep the good work up
You are welcome! Thanks for watching!
solid explanation, thank you sir
You're welcome!
That was interesting things to learn about, thank you!
Glad you liked it!
For the crazy ones, Spring Security supports salt, pepper and all the goods that comes with it :)
Thanks for making these high quality videos.
And thank you for watching!
Would love to see how to do peppering in a production environment
Thanks for sharing, enjoyed it
Thanks for watching!
The way you've described pepper, it's just security through obscurity...
For me it seems that events "hacker got database" and "hacker got code" are extremely correlated.
Thanks a lot for the video!
Shouldn't the pepper used, be somehow indexed like (with?) the encryption algorithm used? Because in the example the code I see no way to deal with pepper change, besides discarding the entire old database... For instance, instead of 'blake2b' could one append a descriptor 'scheme1' or something, that is known somewhere else to be blake2b + pepper version yyyy-mm-dd?
That way if the current pepper leaks, the system still has some way to identify the "compromised" (weakened) passwords info and to migrate away to a new pepper (Just start using a 'scheme2')
Indeed, all extra params of the algorithm and other information you will have to stuff into the name part of the password. Something like blake2b:50:100:2$salt$hash. For blake2b with 50 rounds, 100 memory, pepper v2.
Delicious, salty, and peppered hashbrowns
why cant the hacker compare some of the hashed salted peppered passwords and find the substring that appears in every password, which is the pepper?
Unlike salts, the pepper is not stored in the database, so it will not appear in any of the leaked data so this approach would not work.
this is the best explanation thanks never dit understand it til now👍
So could adding the pepper conceivably be done in hardware? If it can completely avoid the main CPU, with that part of the hash implemented in a chip that can't be reprogrammed, that can't be broken right?
(Not to say "unhackable", I've learnt that's a dangerous term)
Conceivably yes, the whole hash could be done on a dedicated chip that automatically adds the pepper in, but I would be surprised if there were any actual implementations of this given the cost to benefit ratio.
Great explanation!
It must be said that once you hash a password, no mutual authentication can happen and the password can be taken by a compromised server. Security comes from making sure the box called authentication server is isolated from the web server (which should be assumed to be likely to get compromised)
It's not just the web (application) server access you need to worry about. There are more passwords in the standard "leaked password" dictionaries out there that were leaked by insecure disposal of disk drives than there are from, say, SQL injections, etc.
This is wrong. mutual authentication happens from the server by just providing the hash and the client hashing their own password to check against that hash. The authentication for the server works the normal way where the client provides the password and the server hashes it and compares it to it's own hash. In both cases only someone who is party to the original secret can pass this verification.
But now any client can grab the hash and pretend to be the genuine server to the real client. It's a fail.
I guess you are right. For two way authentication you need complementary keys.
if you could only use one, would you rather use a pepper or a salt?
Good work man!
Appreciate it!
6:01 If you crack one pass, it is trivial to hash it with all the salts and comparing with original hashes.
No it's not trivial. It is the same time complexity as just trying that password for every user. Sure you can do it offline but it will take a long time, which is the point. No password is 100% secure even if the attacker has no prior knowledge since all of them can be cracked given enough time. The point of all of this is to cost enough time to not make it worth it.
Excellent video!
I don't know much about web server design, so maybe my question is ill-posed. If I understand correctly, the hashing etc. happens server-side, otherwise the salt and pepper would need to be sent to the client and that sounds like a terrible idea. Then my question is: is it possible that plaintext passwords could still be inadvertently saved in log files somewhere? Or is it bad practice to log every POST request?
Yeah, server administrators do typically log all or most requests, but the log would only include that it was a post request to the login page or whatever, the actual data from the request should not be stored in a log. Logging all post data would be a storage waste so most admins wouldn't want to do this in the first place, but additionally it would be a big no-no to store any sensitive client data in a log file, especially passwords. I'm sure that some company has made this mistake and leaked data this way before though. Security is hard to get right, and oh so easy to get catastrophically wrong.
couldn't you just XOR the salt and the pepper in whatever password library you use, if said library doesn't support peppers?
Why aren't peppers used? Seems like a step that'd be introduced almost immediately after salts were thought of.
Always wondered if using the non-changeable ID of a user would be enough as a salt or if it should be a totaly seperate like you did in your video.
I suppose yes, but that feeling of just using the ID keeps nagging me.
You could always use both
Would it not be a good idea to use the username as the salt, it would achieve the same things without needing to store an extra variable?
Concatenating salt and password is probably bad practice because many hash functions are vulnerable to length extension attacks (en.wikipedia.org/wiki/Length_extension_attack), including sha-2 and its variants. If a good hash function is used then this is probably okay, but most sites still only use one round of a weak function like sha256...
It is always a good idea to use well-proven open-source libraries rather than doing it yourself. Modern secure methods of hashing passwords, like Argon2id, typically do something to incorporate the length as well, like salt + len(salt) + password + len(password) + other params + len(other params) + ..., which prevents any kind of length extension attack.
Great content, thank you
4:26, the hacker can also execute a pass-the-hash attack
So salt is stored in the database, pepper is stored in the code or in a secure memory enclave... Why not calling only the one in the code pepper so we could also have spices in the secure memory so all 3 parts of the site have to be leaked instead of 2 ?
It's very possible this kind of thing gains support in the future, storing spices on many different places to increase security, but the incremental benefit of a third spice is much less than salting and peppering, so it probably won't become popular in the near future. I.e. the extra security from needing 3 simultaneous hacks vs just 2 simultaneous hacks is not worth as much. As soon as even 1 hack occurs, you should re-salt and re-pepper everything.
I have a cuestion about de declaration of variables. In the video you typed "password: str", that means that variable will only accept strings or it's just something for you to remember the variable class?
It means that the variable is intended to be a string, but these type hints are nit enforced at runtime so it is mainly for the reader of the code to help understand.
So for the pepper-part, if nobody has included that yet, would it be possible to just add my pepper in front of every password I save and retrieve (making it a longer password) so that I then could use normal cryptographic functions that have pepper not yet implemented or should I wait for my preferred function to include it (if it not has already)?
Literally thought this was a cooking video when I clicked on it…
Does salt helps to decrease hash collisions?
Thank you.
Couldn't you just pepper it without the salt? Yes 2 identical passwords would be the same, but that info isn't particularly useful.
Checking whether two passwords are the same is unfortunately very useful because people tend to use very weak passwords. Go through the hashes and look for the most common one, which will be about .5% to 1% of your users. All those users' passwords are 'football'. Ok password policies etc. can lower the percentage who have the same pass, but but you will still see a lot of users with the same password, which would then tell you who to start guessing weak passwords on. There's more discussion of why pepper without salt is not as good in the link in the descriptiom on crypto.se.
I do that, I have a different password for everysite that I login.
Why you cant just use papper without salt?
You can, it does not mean that you should. In some sense salting alone provides more security than peppering alone.
I guess you could argue it's a backup i.e. in that rare evnt that the pepper gets found out, it's the same as if you only hashed the password. at least, concerning the issues brought up in the video.
You say that "because an attacker knows the salt, they can try to crack the password offline". Is this really true? In the example, you append the salt to the beginning of the password before hashing it, but the attacker doesn't know that. You could append it to the end, interweave it into the password, multiply them together as numbers, or any custom function you can think of to incorporate the salt into the password. Is there a reason this isn't done?
Great question! What you are describing is called "security by obscurity". Although it is good intentioned, it is generally frowned upon. Yes, you can do something nonstandard like interweaving the salt into the hash and that very well may trick some attackers. However, this is also dangerous because in being creative this way, people will often unknowingly break some security property, making it easier for the attacker. If you want to waste more of the attacker's time, use a stronger slower hash function, don't risk messing up an existing system. As for cracking the password offline, if you want to make sure there is no chance of the attacker being able to attempt offline cracking, use a pepper as suggested in the video! Both the pepper and interweaving salt ideas could be thwarted if the attacker gains access to the application code, but the pepper cannot be thwarted if the application code remains safe, whereas something like interweaving salt an attacker could potentially figure out using a number of techniques (e.g. hash some common passwords and look for statistical correlations of those hashes with the leaked db hashes, this would thwart any permutation-based approach like interweaving salts).
@@mCoding I suppose it's true that, to change how the salt is applied, you'd likely have to run your own auth library, or at least override a part of an existing one, which you're completely correct in saying could undermine the security somehow. I think if, for some reason, you had to roll your own, it would theoretically be better to do something like that than not - security *augmented by* obscurity is never *worse* - but yeah, if you're in a position where you have that much control, using a pepper accomplishes the same thing while being more secure. Thanks for the response!
What if attacker was registered on website before leak and he has weak password? Can he brute force pepper, when he has salt, password and hash?
Most websites would not let the hacker make more than a few incorrect guesses before ignoring further attempts, however, even if the attacker was allowed to make as many guesses as possible, the fact that the pepper is a randomly generated long string means that the hacker will not be able to guess the pepper anyway.
Good stuff!
U look like that guy from series silicon valley
How about not using passwords at all and instead sending an email with a random link to log in?
Yoy certainly could do that. However, email is generally not considered secure, so this approach is not recommended. Additionally in that case the email link itself is effectively acting like a password.
very cool stuff
I have seen some tutorials who generate the random salt, add it to the password and then hash it(instead of hashing the password then adding the salt), then store the salt (before it was hashed) and the hashed password and use it to make the comparisions for login, etc. Also, can I store the salt in another table?
The salt is added before hashing, not after. A salt would be useless if it was only added into the string after hashing. What may have confused you is that the salt is stored alongside the hashed(password + salt), but this is purely a convenience and efficiency hack since the salt and hash will always be needed together. The salt could be stored wherever you want in the database, but since it's only purpose is to be used with the hashed password at login time, it is very common to store them in the same field.
@@mCoding Thanks, for some reason I thought you added the has after in the video so I was confused
Just for clarification: couldn't I just pick certain things about each user (e.g. username and age) (obviously always the same attributes) and put that into the hash with the password?
That sounds basically like a salt
That usually has less entropy than a truly random salt.
And less entropy means less effort when precomputing hashes.
could you also generate the peper from something like the user email + some secret + salt?
There is typically only one pepper for the whole application so it cannot depend on user data. What you describe is a method of changing the salt. Yes, you could append something like user email to the salt, but why? You would then need to rehash the password (and hence require the user to enter their password) in order to change their email, and it doesn't seem to provide any benefit since this data would still be available to the hacker in the event of a leak since it is stored in the database.
@@mCoding fair
I am wondering why math.sqrt() function always gives positive value is this function is not wrong? Or May be I am thinking a bit off of logic
Mathematically speaking sqrt(x) is the only positive y such that y² = x where x is a positif real number.
wouldnt the pepper have to constantly be in circulation somewhere, if u have some form of distributed server system?
Yes, every server that authenticates users would need access to the pepper.
Then wouldn’t the relevant attack then be to change the pepper into something known, changing the password/salt/pepper problem into the solved password/salt problem?
Is there a reason I'm missing for not using only the hash function (as opposed to requiring additional libraries)?i.e. concatenate the salt, pepper, and pw and hash them as one
What additional libraries are you referring to? Do you mean using the compare digest instead of ==? Or do you mean why base64 encode? The former is to prevent againsy timing attacks. The latter is to make it easier to print out and to make using the $ separator safe.
@@mCoding at 8:05 you mentioned that "most libraries don't support peppers". I was just saying I don't understand why you'd need "support" and couldn't just concatenate your input strings (with $, for example) and pass it to a hash function. What additional support would you need from a library?
Ahh yes, I see what you were asking now. I think it would be totally fine to just plug in the pepper the way you mentioned. However, for password hashing you want a specific kind of slow hash function, so things like sha256 are out. You want how slow it is to be configurable, which is something that Argon2id, bcrypt, and scrypt all offer. Additionally, I am not a cryptography expert and my word is close to worthless for such a critical part of your application. Historically speaking, it is extremely easy to try to "get creative" with a cryptography tool and end up accidentally subverting one of it's security properties or allowing for a class of attack that you never considered before. As a non-expert, I know I'm not qualified to do anything beyond using a prebuilt system like Aegon2id exactly in accordance with it's documentation (which explicitly mentions salt but not pepper), and therefore I cannot in good conscience recommend even the most trivial creative deviations to my viewers.
Can we use chicken meat with this recipe?
I believe in this analogy that your password is the chicken meat, and that hashing is the important step of thoroughly cooking said meat.
Is there someone who can explain why user emails generally aren't stored in a hash either?
I thought this too. But it's probably because email is usually used as a login and identifier of the user. And not being able to search for users base on a unique identifier would be a nightmare for support teams. Emails are also more convenient for users than some unique ID or a nickname.
Because how would you send an email to an email address that you cannot retrieve?
A salt with a deadly pepa.
Does it work ldap
james how old are you?
Another good practice is to hash the passwords multiple times instead of one, using a computationally heavy hashing algorithm (hash(hash(hash(...hash(password)))). The goal is to make it significantly harder for an attacker to be able to crack passwords offline, in case you dont use pepper or if the pepper is leaked as well.
Cracking a hash for which you have the salt the pepper and the algorithm is actually quite easy and fast for weak passwords. Using the multiple hashes, it would make it much much more time consuming, and potentially unfeasible for the attacker to actually crack passwords this way.
Just use the inbuilt functions in the hash algos to do that instead. Do not get creative with cybersecurity tools unless you yourself are an expert in the field.
Bro actually cooked