Thanks for the explanation of peppers! I didn't know that existed. However... Every time you teach people about MD5 without explicitly warning them it's been cracked, a cryptography fairy dies.
There are 2 concepts of a pepper 1. What was explained here, a small random input that is iterated through when authenticating the user 2. An input like the salt but the same for every password that is stored separately to the password (sometimes, but not wisely in the code itself)
@@digitalalpha2 If you asked me this 2 years ago I might have had an answer (or tripped over myself) but I honestly don't know what I meant with point 1 anymore. A pepper as I know it is point 2. The key points are that it is the same for all passwords, and not stored in the database (so a breach/dump doesn't expose it) If you're learning about password hashing I would dive into the PBKDF2 and bcrypt password hashing functions and what they do.
the answer is, don't use hashes like sha1 for passwords. These hashes were not designed for passwords (read as: not designed to be inefficient and expensive to calculate). They were designed to be super fast to calculate - thus easy to bruteforce. So it's better to use something like BCrypt, PBKDF2, etc...
Randorn Canis Thanks. I didn't even think about using both, but I think I'll take a look at bcrypt. I've heard that a lot of people use it, but I've never really tried it.
LiveOverflow Thanks. But isn't this good news? On the server side, it doesn't matter if if takes a bit longer, but if someone uses a dictionary/brute force attack, it would? Anyways, I'll try out bcrypt.
Nice video! Great concept! If anyone is thinking of implementing this into PHP as I first did, don't. It's already implemented in PHP with the function of password_hash & password_verify. Wish I knew that before I implemented it! haha
Thanks so much for this, doing a course with open uni, and this gave a bit more information and understanding than they provided. thanks! And it's good you have a nice clear and understand voice. Keep up the good work,
but the more digits you add the average time to match the password will increase exponentially, in the example, the time it takes for a user to login would ramp up extremely fast and become impractical
I propose to use a dynamic salt and NOT TO STORE it anywhere, it will be re-evaluated every time login details change. Plus, a 100 pepper keys from which only a single passes
The description of a pepper here is interesting, but probably not a good idea. It is better to slow down authentication using a specifically designed system like bcrypt or scrypt.
Havent heard of peppers, but it was a great information learnt! Didn't even think of hackers might get the salts by dumping dbs They could still brute force it much easier like there's no salt added Just cant use rainbow tables.
yeah but with rainbow tables all you have to do is simply check if hashes match, but without rainbow tables, you have to manually re-hash all of the passwords that you want to guess, making it a lot more hard to crack.
I just finished typing a long comment exposing a lot of knowledge that has no business being exposed, but then I remembered the saying "do your filth and keep your mouth shut", so I deleted it. Still, I'm itching to say, this video made me realize how narrow minded most programmers are. Which is great news for me.
So, for my understanding. If you own a rainbowtable, and you know the salt you can just add the salt to every unhashed password in the rainbowtable and hash them again, then you can throw the hash password with the salt into the rainbowtable again, and you will get the password right? So the Salt way is just to make it a bit harder/more annoying to get the password, like with the Papper way.
I always thought pepper was a static string stored in the application added to the salt/pass. This random list of strings in your example is new to me. I don't think I'd use A-z but an array of strong strings instead. Honestly I think it should have been called something else, like hot-sauce, as I truly believe pepper started out as a static string (though I could be wrong).
Technically, they're both peppers since they're both randomness not stored in the database, though storing 1 long string somewhere that's not the database it more useful than rediscovering the pepper every time, since the latter is just used to increase the time it takes to crack passwords, and you should really be increasing the iteration count if that's your goal. Storing a long string somewhere other than the application however, has the added benefit that a database breach still doesn't give enough information, and your application code, or wherever you're storing the pepper also has to be leaked, in which that case, it's basically the same as a salted password.
@@FastKnight401 Yeah, my understanding is slightly different. There are more than one peppering strategies but the fundemental difference I understood was that the pepper is a secret peice of information, typically an HMAC key or similar, that is added to the password before hashing. The peppering described in the video is more like a calculated salt. A pepper should be protected and stored elsewhere, such as an HSM.
@@flymoracer I was under the assumption that in the video they were describing that you store an array of peppers separately from the passwords for iteration, if that is the case would that not fit the definition of a pepper? Storing passwords with their peppers at all seems counterintuitive and would just mean there are now 2 databases that could be breached and individually cause problems increasing security risk via unnecessary broadening.
@@Outwardpd Yeah, exactly. The case in the video seems to use a known array of pepper values, presumably stored in the application code, where each one gets appended to the supplied password in turn until a matched hash is found (or not if the password is incorrect). So the pepper value typically would not get stored along with the password. If it was I guess it would be a salt.
Or just change a few values of the sha256 code which is what I did and so it produces a completely different hash to what would be the sha256 hash then make it hash server side making it impossible as your code is private
Nice explanation dear. I have query, that is 1.pasdword+salt+pepper=hash value ? 2.pasdword+pepper=hash value ? 3. Pepper hash value not stored in database so than where it is stored ? Please reply me.
if hashing is always 1 to 1(a given password will always result in a given hash), why cant hackers mess around with the hashing algorithm to discover a way to un-hash strings? also are all salts appended or can the be prepended or even put in the middle?
also also, won't rainbow tables still be of use if the hacker knows where the "junk" characters are and simply removes them from the hash + salt, as hash +salt -salt = hash?
I only have one question unto those who have a high level of expertise within this field can paswords be encrypted, hashed, salted, and peppered all at the same time thus virtually making it high level to crack by third parties and online viruses etc?
If you have to store the salt in the database, then it would only prevent rainbow table attacks. If the attacker gets in the database, he can just add the salt to each attempt in his dictionary attack without slowing him down. So, salt only helps people with really bad passwords that exist in rainbow tables?
while common passwords will always be found first, if the hashes are salted, then all the hashes in the rainbow table and dictionary attack would have to be recalculated, which ruins the whole purpose of dictionary attacks and rainbow tables. But the most common passwords will still be attempted to be hashed first nevertheless
then if two or more users have the same password, their salts would be the same too; resulting to identical password hashes in your database. that's one of the main things we are trying to prevent here! and it's also a best practice to make sure the salt isn't based on the password itself in any way .
I have a question regarding pepper, you said that it’s not. Where it is not stored in dB or in rainbow table ? Bcz i have read a lot of articles on google and they all said that it’s stored with password(salt+password +pepper)... can you please explain little bit more so I can clear my confusion.
Let's say your pepper consists of a random letter of the alphabet, that gives you 26 possibilities for your pepper. So your authentication program will have to try all 26 possibilities for "password + salt + pepper" at login, which is negligeable. Whereas the attacker needs to compute a table that is effectively 26 times bigger. Now, the size of your pepper can be significantly more than that, with a negligeable cost to you, while the cost to the attacker is tremendous.
A salt is unique for every password, and it is added in anyway to the password, it does not have to be appended to the password. In the video you said a pepper is unique for every password, but they aren't. Salts are stored, so are unique, but a pepper is a secret, so the same pepper is used for every password. Also, salts and peppers do not have any length associated with them, and usually the longer they are, the better.
Nice, concise video. I encountered an issue recently when copying a test environment to a dev environment and was unable to login on the dev environment using the credentials copied over from test. For reference, I was using bcrypt in NodeJS. If the salt is stored in the database as a prefix to the hashed password, why is it that I couldn't login on the dev environment?
just to confirm, over http the password and the user name would be sent from the client to the server in plain text and in https (ssl) it would be encrypted? The methods detailed only help the server and database security, but the client is still very vulnerable?
Very old video but you did get a couple of things wrong, or at least not cover the entire story. for instance, a Rainbow table is not just a straight lookup table. You need to cover chains, and reduction as well to get a clearer picture. But Kudos on the salt and pepper. Companies like joomla even got it wrong at some point using a static salt for all users. Now if your hashes are compromised, it means your db was compromised, thus said actor has the content of the configuration as well, which means they know your salt, and can use any of the existing tables and leak those users.
q: what do you think about hash a password with the same password as a salt.. only the user will "know" the salt and you don't need to store the salt..
That is what's called security through obscurity. It will seem very secure until one hacker anywhere in the world figures it out! If that hacker tells the world, every hacker can try cracking the passwords assuming that you used that method. Suddenly, all the people in the world who used that method have to scramble to update their system! The best security is open source. This might seem counter intuitive but it's true. If your system is hard to crack even with the source code known, you have avoided the security through obscurity issue.
When user enters password for salted password, is there an unhashing algorithm to be able to check if the salted pw in the DB matches user input? Or how is it checked?
not all heroes wear capes, some of them make good tutorials
how do you know if he is wearing a cape or not
@@subzerokar jeez you been going to finishing school
amen
I like when people can explain such complex things easily
Thanks for the explanation of peppers! I didn't know that existed.
However... Every time you teach people about MD5 without explicitly warning them it's been cracked, a cryptography fairy dies.
Jeez.
I wish you taught my Comp-Sci class...
Now I get it.
Tx
&& this educational stryle vid is a nice change too.
There are 2 concepts of a pepper
1. What was explained here, a small random input that is iterated through when authenticating the user
2. An input like the salt but the same for every password that is stored separately to the password (sometimes, but not wisely in the code itself)
Hi, can you provide a reference to this! according to wikipedia only the 2nd one is mentioned there
en.wikipedia.org/wiki/Pepper_(cryptography)
@@digitalalpha2 If you asked me this 2 years ago I might have had an answer (or tripped over myself) but I honestly don't know what I meant with point 1 anymore.
A pepper as I know it is point 2. The key points are that it is the same for all passwords, and not stored in the database (so a breach/dump doesn't expose it)
If you're learning about password hashing I would dive into the PBKDF2 and bcrypt password hashing functions and what they do.
Fantastic tutorial, thank you. I am studying for my CISSP exam and this made a lot of sense to me.
Great video. I knew about hashing and salting, but not about peppers. What do you think is better/safer? Or isn't there a "best way"?
the answer is, don't use hashes like sha1 for passwords. These hashes were not designed for passwords (read as: not designed to be inefficient and expensive to calculate). They were designed to be super fast to calculate - thus easy to bruteforce.
So it's better to use something like BCrypt, PBKDF2, etc...
Randorn Canis Thanks. I didn't even think about using both, but I think I'll take a look at bcrypt. I've heard that a lot of people use it, but I've never really tried it.
LiveOverflow Thanks. But isn't this good news? On the server side, it doesn't matter if if takes a bit longer, but if someone uses a dictionary/brute force attack, it would? Anyways, I'll try out bcrypt.
LiveOverflow You here? Cool!
Same
Nice video! Great concept!
If anyone is thinking of implementing this into PHP as I first did, don't. It's already implemented in PHP with the function of password_hash & password_verify. Wish I knew that before I implemented it! haha
Dude are you f**king crazy?!?!?
You just spent 4 mins clearly explaining what I have been confused about for 4 days!!!
Thank you!
Thanks for the video! I was trying to figure out how salts were stored and you explained it perfectly
Doot doot. Did I get healthy bones? Great use of memes man, very dank
Took you less than5 minutes to explain this topic.
My teacher had an hour and a half and I still didn't get it.
Thank you
Hmm very interesting. I'll absolutely never need to know this so i will never forget
Awesome, clicked away, forgot to like so I went back and left a like :)
Thanks so much for this, doing a course with open uni, and this gave a bit more information and understanding than they provided. thanks!
And it's good you have a nice clear and understand voice. Keep up the good work,
Bruteforce using quantum computer would crack this for 10s
Thanks so much for these videos! it makes learning so much easier!
Thank you! This was explained really well, I understand it now.
Great video. 1 comment though: 3m47s "52 times longer" is only true if the attacker always guesses wrong until the last try. ;)
remember:
the most secure hashing algorithm is one that is not publicly known.
Finally I understand what peppers are. I was always confused and thought pepper and salt are the same
Thank you for this video! Very clear explanation. You are a good teacher.
yeah, this video was really easy to understand
yeah, this video was really easy to understand
Very well done ty I was confused till this point!!!
Quick and simple explained. Nice video!
snoop dogg and ali g as your example passwords - we are brothers from separate mothers
Genius without education is like silver in the mine.
Baran Barış Yıldızlı what?
why only 1 pepper letter? deos using like 4 letters not produce a ton more possible hashes?
but the more digits you add the average time to match the password will increase exponentially, in the example, the time it takes for a user to login would ramp up extremely fast and become impractical
I propose to use a dynamic salt and NOT TO STORE it anywhere, it will be re-evaluated every time login details change. Plus, a 100 pepper keys from which only a single passes
The description of a pepper here is interesting, but probably not a good idea. It is better to slow down authentication using a specifically designed system like bcrypt or scrypt.
Havent heard of peppers, but it was a great information learnt!
Didn't even think of hackers might get the salts by dumping dbs
They could still brute force it much easier like there's no salt added
Just cant use rainbow tables.
yeah but with rainbow tables all you have to do is simply check if hashes match, but without rainbow tables, you have to manually re-hash all of the passwords that you want to guess, making it a lot more hard to crack.
Thank you so much, this was so easy to understand!
I just finished typing a long comment exposing a lot of knowledge that has no business being exposed, but then I remembered the saying "do your filth and keep your mouth shut", so I deleted it. Still, I'm itching to say, this video made me realize how narrow minded most programmers are. Which is great news for me.
Thanks for the video!
It was greatly explained!
Very well explained 👏
Thank you very much 😊
So, for my understanding.
If you own a rainbowtable, and you know the salt you can just add the salt to every unhashed password in the rainbowtable and hash them again, then you can throw the hash password with the salt into the rainbowtable again, and you will get the password right?
So the Salt way is just to make it a bit harder/more annoying to get the password, like with the Papper way.
Then thats just a dictionary attack...?
The Snoop Dog thing was so random
U make a simple topic so complex.
I always thought pepper was a static string stored in the application added to the salt/pass. This random list of strings in your example is new to me. I don't think I'd use A-z but an array of strong strings instead. Honestly I think it should have been called something else, like hot-sauce, as I truly believe pepper started out as a static string (though I could be wrong).
Technically, they're both peppers since they're both randomness not stored in the database, though storing 1 long string somewhere that's not the database it more useful than rediscovering the pepper every time, since the latter is just used to increase the time it takes to crack passwords, and you should really be increasing the iteration count if that's your goal. Storing a long string somewhere other than the application however, has the added benefit that a database breach still doesn't give enough information, and your application code, or wherever you're storing the pepper also has to be leaked, in which that case, it's basically the same as a salted password.
@@FastKnight401 Yeah, my understanding is slightly different. There are more than one peppering strategies but the fundemental difference I understood was that the pepper is a secret peice of information, typically an HMAC key or similar, that is added to the password before hashing. The peppering described in the video is more like a calculated salt. A pepper should be protected and stored elsewhere, such as an HSM.
@@flymoracer I was under the assumption that in the video they were describing that you store an array of peppers separately from the passwords for iteration, if that is the case would that not fit the definition of a pepper? Storing passwords with their peppers at all seems counterintuitive and would just mean there are now 2 databases that could be breached and individually cause problems increasing security risk via unnecessary broadening.
@@Outwardpd Yeah, exactly. The case in the video seems to use a known array of pepper values, presumably stored in the application code, where each one gets appended to the supplied password in turn until a matched hash is found (or not if the password is incorrect). So the pepper value typically would not get stored along with the password. If it was I guess it would be a salt.
Great down to the point explanation.
Very very well explained. Thx so much.
omg what is 1.56 timestamp??? I friggin LOVE IT!
3:53 it takes many years longer when use multiple alcorith together and even reverse hash order between. hacker have know clue
Or just change a few values of the sha256 code which is what I did and so it produces a completely different hash to what would be the sha256 hash then make it hash server side making it impossible as your code is private
Excellent tutorial. More, please! 😃
What about storing the hash of the hash of the hash....say 100 levels deep..... this also makes it computationally expensive
EXCELLENT VIDEO! Thank you!
Nice explanation dear.
I have query, that is
1.pasdword+salt+pepper=hash value ?
2.pasdword+pepper=hash value ?
3. Pepper hash value not stored in database so than where it is stored ?
Please reply me.
its not stored, you bruteforce the pepper on server side.
that's reallt a gold content the way you explained is outstanding thanks alot bro :
)
Great, concise explanation, thanks :)
Great explanation
if hashing is always 1 to 1(a given password will always result in a given hash), why cant hackers mess around with the hashing algorithm to discover a way to un-hash strings?
also are all salts appended or can the be prepended or even put in the middle?
also also, won't rainbow tables still be of use if the hacker knows where the "junk" characters are and simply removes them from the hash + salt, as hash +salt -salt = hash?
thanks for the excellent resource.
liked it so much, would love to see more. not even breaking any stupid UA-cam laws
Thanks for the explanation
you cleared my doubt, it's very informative. thanks
I only have one question unto those who have a high level of expertise within this field can paswords be encrypted, hashed, salted, and peppered all at the same time thus virtually making it high level to crack by third parties and online viruses etc?
Very well explained
A really good video, thanks man.
great explanation and easy to understand
thank you for this tutorial.
I don't get how rainbow tables would not work assuming a hacker has access to the hashed password and the salt
If you have to store the salt in the database, then it would only prevent rainbow table attacks. If the attacker gets in the database, he can just add the salt to each attempt in his dictionary attack without slowing him down. So, salt only helps people with really bad passwords that exist in rainbow tables?
while common passwords will always be found first, if the hashes are salted, then all the hashes in the rainbow table and dictionary attack would have to be recalculated, which ruins the whole purpose of dictionary attacks and rainbow tables. But the most common passwords will still be attempted to be hashed first nevertheless
Is it more safe to hash the password 2 times? so like one to be used as salt and one to store in the database.
then if two or more users have the same password, their salts would be the same too; resulting to identical password hashes in your database.
that's one of the main things we are trying to prevent here!
and it's also a best practice to make sure the salt isn't based on the password itself in any way .
can you use both salt and pepper on top of a hash
ohh thanks I didn't know that online website implemented rainbow table
Are peppers used for scrypt? Whereas SHA256 lacks the pappers.
3:51 why would it take 52 times longer to log in ?
how the users application know if it should check peppers combinations?? has it to be implemented on the front end side?
great explanation!
Hey got everything done by *Realhacker001* on iG it’s legit worldwide hackers 💯💯💯💯💯😮😮😮👂👂👂❤️❤️❤️
can you please make a video on everything we need to know about cryptography in order to start cracking?
Great explanation 👍
I have a question regarding pepper, you said that it’s not. Where it is not stored in dB or in rainbow table ? Bcz i have read a lot of articles on google and they all said that it’s stored with password(salt+password +pepper)... can you please explain little bit more so I can clear my confusion.
Let's say your pepper consists of a random letter of the alphabet, that gives you 26 possibilities for your pepper. So your authentication program will have to try all 26 possibilities for "password + salt + pepper" at login, which is negligeable. Whereas the attacker needs to compute a table that is effectively 26 times bigger. Now, the size of your pepper can be significantly more than that, with a negligeable cost to you, while the cost to the attacker is tremendous.
A salt is unique for every password, and it is added in anyway to the password, it does not have to be appended to the password.
In the video you said a pepper is unique for every password, but they aren't. Salts are stored, so are unique, but a pepper is a secret, so the same pepper is used for every password.
Also, salts and peppers do not have any length associated with them, and usually the longer they are, the better.
Pepper can be implemented both ways. The way described in the video would also work and would be safer.
does pepper character is limited from a..Z and 0..1 or all character in ASCII unicode?
*sorry if my question made you confuse
Hi, really good video, thanks :) !
Maybe you should go a bit slower, sometime we need to pause the video to read the screen content.
Thanks.
That's what pauses are for..
(worst case is 52 times the time it takes without a pepper)*
Great video. Thanks man!!
I actually got this. Thank you!
Great Video! Srry for bad English, I have a question, ho do you get into the deta base to get the hash?
Waiting for your Hak5 field kit use of each tool.
Honestly, we're in 2020, all reputable websites should be using brute force attack detection software.
wow this was really simple to understand
Never use standard MD5.
Thank you for this video!!
Nice, concise video.
I encountered an issue recently when copying a test environment to a dev environment and was unable to login on the dev environment using the credentials copied over from test.
For reference, I was using bcrypt in NodeJS.
If the salt is stored in the database as a prefix to the hashed password, why is it that I couldn't login on the dev environment?
just to confirm, over http the password and the user name would be sent from the client to the server in plain text and in https (ssl) it would be encrypted? The methods detailed only help the server and database security, but the client is still very vulnerable?
Thank you!
video was great thanks bro
that's a lot of hash at the beginning of the video
Very old video but you did get a couple of things wrong, or at least not cover the entire story.
for instance, a Rainbow table is not just a straight lookup table. You need to cover chains, and reduction as well to get a clearer picture.
But Kudos on the salt and pepper. Companies like joomla even got it wrong at some point using a static salt for all users. Now if your hashes are compromised, it means your db was compromised, thus said actor has the content of the configuration as well, which means they know your salt, and can use any of the existing tables and leak those users.
Great video! Thank you!
I know it's weird question but does anyone know what accent is he speaking?
Great and funny video, pass: smoke weed everyday ;)
q: what do you think about hash a password with the same password as a salt.. only the user will "know" the salt and you don't need to store the salt..
That is what's called security through obscurity. It will seem very secure until one hacker anywhere in the world figures it out! If that hacker tells the world, every hacker can try cracking the passwords assuming that you used that method. Suddenly, all the people in the world who used that method have to scramble to update their system!
The best security is open source. This might seem counter intuitive but it's true. If your system is hard to crack even with the source code known, you have avoided the security through obscurity issue.
Really educational thank you
When user enters password for salted password, is there an unhashing algorithm to be able to check if the salted pw in the DB matches user input? Or how is it checked?
THAT WAS AWESOMEE SO CLEAR!! THANKS
Can you please provide an example in java for salt and pepper implementation
what about double or triple Hashing ? ( Is it a good, or dumb idea )?
Your videos are fantastic. Excellent content and production. Like "Crash Course" but in hacking.
Pepper is just a global password according to Wikipedia