There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
You can also find further discussion and get answers to your questions over in Language Help.
Agree with a comment or answer? Like () to up-vote the contribution!
Could be the only one this has happened to but I just want to say this exercise is a little bit bugged. I had to do with “Replace with Code Solution” because it would not evaluate the code I put into the browser after I did the node app.js bit then clicking check your work. I just deleted what the Code Solution put in and went through the steps so I could learn anyways. I really think Bcrypt is neat… And would be an excellent CS themed Halloween costume… Tales from the Bcrypt keeper? Anyone !??
It states that the bcrypt.compare() function extracts the salt from the stored password’s hash in order to hash the entered password provided to compare with. How is this possible? This is a hash of the salt and the password combined. You shouldn’t be able to retrieve the salt from the hash anymore than you could retrieve the password from the hash. And in the next lesson “Bcrypt in a CRUD app”, the salt is not stored to the DB, only the hash. So how does this work?
I think I must be missing something because if the salt can just be removed and then the hash compared, doesn’t that defy the point of a salt? If a hacker got possession of a salted hash could they not just remove it and compare a regular hashed password in a rainbow table like one of the former exercise suggested?
I apologise if I am being stupid, but I am a bit confused.
Knowing which part of that 60 character value is the salt and which is the hash doesn’t do the attacker any good. Either way the salt needs to be stored along side the hash. The hash that is saved in the database is still salted and that salt should be unique. Another way of saying this is the saved hash is not just a hash of the password. It is a hash of the password and salt together. This means if an attacker were to get ahold of the salt and hash, pre-computed rainbow tables wouldn’t be of any use (as precomputed rainbow tables would be just hashed passwords with no salt). The attacker would need to generate a whole new set of rainbow tables (with this unique salt). Keep in mind they would have to do this for each and every saved password in the database as the salt would be different for every saved password. This would be extremely compute and time intensive.