Salting, peppering, and hashing passwords

Рет қаралды 67,816

Күн бұрын

What can a hacker do when a database is leaked?
Try Hostinger: hostinger.com/mcoding
Use coupon code MCODING at checkout for up to 91% off all yearly hosting plans!
Your password database just leaked. What info does the hacker get and what can they do with it if you used plaintext passwords, hashed passwords, salted hashed passwords, or peppered salted hashed passwords?
In this video we will talk about hashes, salts, and peppers, which can be used to more securely store passwords in your application's database. We use builtin secure Python primitives. Big open source libraries like Flask and Django use these techniques.
Note: DO NOT WRITE YOUR OWN CRYPTO. This video is for educational purposes to explain the purpose and benefits of salting and peppering, it is not an example of secure production code.
Note: Hash functions used in hashing passwords should be purposefully and configurably slow so that it takes an attacker a long time to check hashes even offline, making it more time-consuming to crack even weak passwords.
― mCoding with James Murphy (mcoding.io)
Source code: github.com/mCodingLLC/VideosS...
Password storage best practices: cheatsheetseries.owasp.org/ch...
Crypto.SE on peppering: security.stackexchange.com/qu...
Timing attacks video: • Cracking passwords usi...
SUPPORT ME ⭐
---------------------------------------------------
Patreon: / mcoding
Paypal: www.paypal.com/donate/?hosted...
Other donations: mcoding.io/donate
Top patrons and donors:
John M, Laura M, Pieter G, Vahnekie, Sigmanificient
BE ACTIVE IN MY COMMUNITY 😄
---------------------------------------------------
Discord: / discord
Github: github.com/mCodingLLC/
Reddit: / mcoding
Facebook: / james.mcoding
CHAPTERS
---------------------------------------------------
0:00 Intro
0:39 DB Leaks
1:14 Plaintext
2:35 Hashes
4:39 Salts
6:14 Peppers
8:14 Closing remarks

Пікірлер: 221

@komodiT1 3 жыл бұрын

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!

@mCoding 3 жыл бұрын

You got it!

@atrus3823 3 жыл бұрын

This has got to be one of the best Python channels on KZfaq. Really great material, interesting topics, in-depth but not overwhelming, and not sensationalized but still engaging. Keep it up!

@mCoding 3 жыл бұрын

Thank you so much! I really appreciate comments like yours! Kind words keep me going!

@samuellebot4390 2 жыл бұрын

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 😂

@mCoding 2 жыл бұрын

Thanks so much!

@jemand771 3 жыл бұрын

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

@mCoding 3 жыл бұрын

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.

@jemand771 3 жыл бұрын

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

@vojtechstrnad1 3 жыл бұрын

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.

@idle-hands 2 жыл бұрын

Call it Paprika

@OMGclueless 2 жыл бұрын

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

@liesdamnlies3372 2 жыл бұрын

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.

@mCoding 2 жыл бұрын

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.

@AnilKeshwani 2 жыл бұрын

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

@georgesanderson918 3 жыл бұрын

I love these security videos, they're awesome! I'm really learning a lot! Thanks mCoding!

@mCoding 3 жыл бұрын

Great to hear!

@jackhuangly89 3 жыл бұрын

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!

@mCoding 3 жыл бұрын

Thank you very much!

@JamilBousquet 3 жыл бұрын

Was actually reading into salting in bcrypts for a personal project recently so definitely gonna use this as a resource. Great vid as always!

@itsalongday 2 жыл бұрын

Great video, this is the first time that I actually understood the concepts of salt and pepper

@madhavareddy580 3 ай бұрын

Greatly explained each of the case! Thanks!!

@andrew_mandrichuk 6 ай бұрын

Thank you so so so much!! This this the best vid about paper and solt so far. Keep it up

@darianleduc 2 жыл бұрын

Awesome explanation! Finally these obscure terms make sense.

@Micaeljm 3 жыл бұрын

2:28 - Laughs in Bitwarden

@saadjadoon6397 3 жыл бұрын

Huh this video was released just now. How did you comment 20 hours ago?

@Orincaby 3 жыл бұрын

@@saadjadoon6397 hacks

@FalseDev 3 жыл бұрын

@@saadjadoon6397 Patreon supporters might have early access

@mCoding 3 жыл бұрын

@PyMaster Patreon gang gets early access!

@katech6020 3 жыл бұрын

Same, Bitwarden is awesome

@alexwhb122 3 жыл бұрын

Another fantastic video! I learned a lot. Hopefully more frameworks will support pepper soon. That's a really interesting trick.

@mCoding 3 жыл бұрын

I was surprised researching that so few libraries support peppers!

@alexwhb122 3 жыл бұрын

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

@Sonyim414 3 жыл бұрын

Hey that's pretty cool. I've never heard of peppers before. Learned something new today!

@mCoding 3 жыл бұрын

Great to hear! Keep learning!

@NobleMushtak 3 жыл бұрын

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)

@mCoding 3 жыл бұрын

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 3 жыл бұрын

@@mCoding like a TPM?

@mCoding 3 жыл бұрын

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

@danielf.7151 2 жыл бұрын

@@mCoding So what would happen if the pepper were somehow leaked?

@CrapE_DM 2 жыл бұрын

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

@wannabedev2452 3 жыл бұрын

This is very knowledgeable, im glad i found this channel

@mCoding 3 жыл бұрын

Welcome aboard! Thanks for the kind words!

@xarros 3 жыл бұрын

I hope you can make a sequel to this video discussing algorithms like SHA, Bcrypt, Scrypt and the differences in using them for authentication

@doonk6004 Жыл бұрын

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.

@mCoding Жыл бұрын

Haha nope 😅 but glad you enjoyed!

@stunize 2 жыл бұрын

I'd never heard of peppers before this. Really informative

@LunaDragofelis 2 жыл бұрын

I have heard of pepper before, but I completely forgot what it was, and this video was helpful to me

@danielakhterov 2 жыл бұрын

Thanks for making these high quality videos.

@mCoding 2 жыл бұрын

And thank you for watching!

@jbaidley 2 жыл бұрын

Great explanation!

@cawkcheck Жыл бұрын

I love this man and the way he explains things

@robertbrummayer4908 2 жыл бұрын

Excellent video!

@AshuraTheHedgehogDX 3 жыл бұрын

Very interesting stuff, good to know!

@mCoding 3 жыл бұрын

Thanks for watching!

@correaswebert 3 жыл бұрын

Coming up next - mint leaves ;) Peppers seems such an simple obvious idea, yet so novel, huh?! Thankful to KZfaq that I found you channel :)

@mCoding 3 жыл бұрын

Thanks for watching!

@markusrupp8333 Жыл бұрын

Thanks a lot for the video!

@anthonyfontana6325 2 жыл бұрын

Great! A clear example of how Salt and Pepper work.

@SomeRandomFellow 3 жыл бұрын

here from the community post. for some reason, youtube is really good at recommending those but not videos 🤔

@mCoding 3 жыл бұрын

I guess i need to make more polls!

@vladislavkaras491 20 күн бұрын

That was interesting things to learn about, thank you!

@mCoding 20 күн бұрын

Glad you liked it!

@suprakens 2 жыл бұрын

Good work man!

@mCoding 2 жыл бұрын

Appreciate it!

@Toldo15 2 жыл бұрын

Great content, thank you

@piriyaie Жыл бұрын

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.

@saidassassi177 3 жыл бұрын

thank you for these very important informations keep the good work up

@mCoding 3 жыл бұрын

You are welcome! Thanks for watching!

@2Sor2Fig 2 жыл бұрын

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.

@128mtd128 5 ай бұрын

this is the best explanation thanks never dit understand it til now👍

@mk9834 3 жыл бұрын

Thanks for sharing, enjoyed it

@mCoding 3 жыл бұрын

Thanks for watching!

@iiN1GH7M4R3ii 2 жыл бұрын

solid explanation, thank you sir

@mCoding 2 жыл бұрын

You're welcome!

@niconeuman 3 жыл бұрын

This was very informative! Thanks!

@mCoding 3 жыл бұрын

Glad you enjoyed it!

@puttenicole 3 жыл бұрын

Good stuff!

@Mutual_Information 3 жыл бұрын

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!

@mCoding 3 жыл бұрын

Thanks so much, always great to hear from you!

@xxX_420BlazeIt_Xxx 2 жыл бұрын

Hoping in the future you can discuss FIDO U2F type authentication.

@sabuein Жыл бұрын

Thank you.

@georgesanderson918 3 жыл бұрын

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

@mCoding 3 жыл бұрын

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.

@lorddurrosXIIIXXXIII Жыл бұрын

very cool stuff

@Ganerrr 3 жыл бұрын

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

@sightorld 2 жыл бұрын

ultimate chad security: properly secure emails instead of passwords

@sqfzerzefsdf 2 жыл бұрын

unlimited chad security: just outsource any logins to passport accounts like google

@HandledToaster2 3 ай бұрын

galaxy chadmaster security: don't use passwords, don't use websites at all. Move to Tibet and free yourself from earthly attachments.

@falxie_ 2 жыл бұрын

Would love to see how to do peppering in a production environment

@tutacat 11 ай бұрын

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)

@vitorhideyoshinakazonebati7531 Жыл бұрын

For the crazy ones, Spring Security supports salt, pepper and all the goods that comes with it :)

@christophhenninger6440 Жыл бұрын

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

@VivekYadav-ds8oz 3 жыл бұрын

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.

@VivekYadav-ds8oz 2 жыл бұрын

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.

@UnfamiliarPlace 2 жыл бұрын

The way you've described pepper, it's just security through obscurity...

@Howtheheckarehandleswit 2 жыл бұрын

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?

@TheNich0145 2 жыл бұрын

what I was thinking as well

@arcstur 2 жыл бұрын

me too

@forkgodsdescendant61 3 жыл бұрын

You reckon faang companies will pickup using peppers in the near future?

@mCoding 3 жыл бұрын

Some of them probably already do.

@Preinstallable 2 жыл бұрын

Delicious, salty, and peppered hashbrowns

@sadhlife 3 жыл бұрын

but is the salt Kosher, and is the pepper freshly ground?

@Amy_A. 2 жыл бұрын

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.

@CrapE_DM 2 жыл бұрын

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.

@tylisirn 9 ай бұрын

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.

@fabioteixeira868 3 жыл бұрын

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')

@mCoding 3 жыл бұрын

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.

@TheEssenceflux 2 жыл бұрын

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?

@eccentricOrange 3 жыл бұрын

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)

@mCoding 3 жыл бұрын

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.

@jeremycomino7610 3 жыл бұрын

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?

@mCoding 3 жыл бұрын

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.

@vskovzgird 2 жыл бұрын

Does salt helps to decrease hash collisions?

@maxturgeon89 3 жыл бұрын

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?

@mCoding 3 жыл бұрын

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.

@alexanderschluter1864 3 жыл бұрын

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?

@mCoding 3 жыл бұрын

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.

@QuantumHistorian 3 жыл бұрын

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?

@mCoding 3 жыл бұрын

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.

@QuantumHistorian 3 жыл бұрын

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

@Mr.Leeroy 2 жыл бұрын

6:01 If you crack one pass, it is trivial to hash it with all the salts and comparing with original hashes.

@ruukinen Жыл бұрын

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.

@milchstrasse8307 2 жыл бұрын

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?

@mCoding 2 жыл бұрын

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.

@milchstrasse8307 2 жыл бұрын

@@mCoding Thanks, for some reason I thought you added the has after in the video so I was confused

@micycle8778 2 жыл бұрын

couldn't you just XOR the salt and the pepper in whatever password library you use, if said library doesn't support peppers?

@ScorpioneOrzion 3 жыл бұрын

could you also generate the peper from something like the user email + some secret + salt?

@mCoding 3 жыл бұрын

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.

@ScorpioneOrzion 3 жыл бұрын

@@mCoding fair

@jonathan3488 2 жыл бұрын

4:26, the hacker can also execute a pass-the-hash attack

@user-gt2th3wz9c 2 жыл бұрын

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?

@mCoding 2 жыл бұрын

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.

@AlphaMoonbase 3 жыл бұрын

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.

@Gelo2000origami 2 жыл бұрын

You could always use both

@DDvargas123 3 жыл бұрын

wouldnt the pepper have to constantly be in circulation somewhere, if u have some form of distributed server system?

@mCoding 3 жыл бұрын

Yes, every server that authenticates users would need access to the pepper.

@iantaakalla8180 3 жыл бұрын

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?

@luck3949 2 жыл бұрын

For me it seems that events "hacker got database" and "hacker got code" are extremely correlated.

@eatchocolate 3 жыл бұрын

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

@mCoding 3 жыл бұрын

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.

@eatchocolate 3 жыл бұрын

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

@mCoding 3 жыл бұрын

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.

@lmtr0 2 жыл бұрын

I do that, I have a different password for everysite that I login.

@ericj4094 3 жыл бұрын

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

@mCoding 3 жыл бұрын

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.

@prathameshTBSM 3 жыл бұрын

U look like that guy from series silicon valley

@vidhyasagar.g 2 жыл бұрын

Does it work ldap

@danielschmider5069 Жыл бұрын

if you could only use one, would you rather use a pepper or a salt?

@rorymax 2 жыл бұрын

Literally thought this was a cooking video when I clicked on it…

@opticalreticle 2 жыл бұрын

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?

@mCoding 2 жыл бұрын

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.

@RabindraNathMurmuready2upload 3 жыл бұрын

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

@randomsoul294 2 жыл бұрын

Mathematically speaking sqrt(x) is the only positive y such that y² = x where x is a positif real number.

@gaelyte2550 3 жыл бұрын

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 ?

@mCoding 3 жыл бұрын

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.

@tk36_real 3 жыл бұрын

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?

@danielf.7151 2 жыл бұрын

That sounds basically like a salt

@SugarBeetMC 2 жыл бұрын

That usually has less entropy than a truly random salt. And less entropy means less effort when precomputing hashes.

@jms019 2 жыл бұрын

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)

@stanrogers5613 2 жыл бұрын

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.

@ruukinen Жыл бұрын

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.

@jms019 Жыл бұрын

But now any client can grab the hash and pretend to be the genuine server to the real client. It's a fail.

@ruukinen Жыл бұрын

I guess you are right. For two way authentication you need complementary keys.

@cyberhard 3 жыл бұрын

A salt with a deadly pepa.

@katdbd 2 жыл бұрын

algorithm comment :D

@avengeranubis 3 ай бұрын

Bro actually cooked

@cool_scatter 3 жыл бұрын

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?

@mCoding 3 жыл бұрын

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

@cool_scatter 3 жыл бұрын

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

@laurinneff4304 2 жыл бұрын

How about not using passwords at all and instead sending an email with a random link to log in?

@mCoding 2 жыл бұрын

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.

@axeskull5193 2 жыл бұрын

Can we use chicken meat with this recipe?

@mCoding 2 жыл бұрын

I believe in this analogy that your password is the chicken meat, and that hashing is the important step of thoroughly cooking said meat.

@Spaz_Rabbit 3 жыл бұрын

Why you cant just use papper without salt?

@randomsoul294 2 жыл бұрын

You can, it does not mean that you should. In some sense salting alone provides more security than peppering alone.

@danielf.7151 2 жыл бұрын

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.

@0xCAFEF00D 2 жыл бұрын

Why aren't peppers used? Seems like a step that'd be introduced almost immediately after salts were thought of.

@driesceuppens7623 3 жыл бұрын

Is there someone who can explain why user emails generally aren't stored in a hash either?

@lamjeri 3 жыл бұрын

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.

@randomsoul294 2 жыл бұрын

Because how would you send an email to an email address that you cannot retrieve?