5

Possible Duplicate:
Password Hashing add salt + pepper or is salt enough?
How to store salt?

Ok I have been studying a lot about password hashing lately. And I have a few questions. So I will explain what I know (if I have gone wrong anywhere along the way, please correct me so I may learn) so I can show you where my confusion lies.

So the reason why I want to hash my users passwords is so that if a hacker gets a hold of the database, he can't just use their emails and type in their passwords to steal their money. It also makes it so any admins cannot see what their passwords are. So the bottom line is to keep my users safe.

Using just a hash like MD5 is not good enough because rainbow tables can be used to figure out what their password is immediately and fast computers can just crack those anyways regardless of salting or not.

But it is important to use salt when hashing to make sure rainbow tables cannot be used and forces hackers to have to brute force their way into finding out the password. So when we are storing the salt, lets say by appending it to the hash, <hash>_<salt> it doesn't matter if its in plaintext because hackers are forced to brute force the hash.

So now onto my questions.

1. Why don't I encrypt the salt from my code and then store the encrypted salt in the database?

It seems like if I did this, then it would be impossible for a hacker to ever brute force and get the password because they would assume the salt is plaintext when really it is not. So they would try and try and never come up with the password. But this leads to my second question.

2. How can a hacker tell what kind of hashing algorithm I used when looking at the database?

If I hashed my password using bcrypt and then hashed that using scrypt and on and on, it seems like the only way to be able to figure out the order of hashing is to be able to see my code.

Ok in order to help explain myself better, let's make up a scenario. A hacker uses some form of SQL Injection to print my entire users list, getting 1000 rows of emails with hashed passwords. These passwords I appended my salt which has been encrypted with my key that's only kept in the code. How would the hacker even know that the salt is encrypted? And if he somehow discerned that it was encrypted he wouldn't be able to decrypt the salt unless he had the key. Which the only way to get the key is if he had access to my code. If he had access to my code, then at that point, he would see exactly how I hashed and salted my passwords so he could easily duplicate the process whether or not he had my key anyways and then start brute forcing to get the passwords. So it seems like doing something like encrypting the salt would stop any hacker who didn't have access to the code from ever figuring out the passwords. Is this not true? If not, please explain it to me in detail. =D

Community
  • 1
Aust
  • 159
  • 1
  • 5
  • 4
    These are two separate questions, both duplicates. A secret salt is called a pepper; see [How to store salt?](http://security.stackexchange.com/q/17421) and [Password Hashing add salt + pepper or is salt enough?](http://security.stackexchange.com/q/3272) . Using a secret algorithm does not help, see [When hashing passwords, is it okay to store the algorithm used …?](http://security.stackexchange.com/q/29414) and [How valuable is secrecy of an algorithm?](http://security.stackexchange.com/q/24449) . And don't forget to apply strengthening (PBKDF2, bcrypt, scrypt) in addition to salting. – Gilles 'SO- stop being evil' Jan 26 '13 at 23:17
  • @Gilles, Yes I have seen most of those which is what caused this question. I thought a secret salt was called a pepper but wasn't quite sure. So anyways I guess my direct question is, if I have a pepper, and a hacker only has access to the database, how can he ever figure out the password? – Aust Jan 27 '13 at 00:18
  • @Polynomial, I have also seen that question but it seems that people are so concerned about salting and hashing but wouldn't encrypting be even better than that? I mean if a hacker only had access to the database (no code aka no key) they would never get the password? – Aust Jan 27 '13 at 00:22

1 Answers1

3

Lets assume a hacker got ahold of your database.

Lets analyse what happens when you store the encrypted salt into your database. The hashing function that utilizes the encrypted salt won't be able to use the salt until it is decrypted. So your code would request the encrypted salt and would need to be decrypted with a key. We can assume this key is in the code.

Since the hacker has your database, they will have the encrypted salt. Now they really only need the key. In your example, the key is stored in the code. Normal salts are going to be stored in the code as well. You really don't add any security at all here since the hacker can simply decrypt salt by getting the key from the code just as if they were have to got the salt from the code.

Most hashing function are going to have enough entropy that you can't analyze the string to figure out which hash function was used. However you can visually see that different hashes contain a different amount and type of characters, which will give you a better clue on which is being used.

If a hacker were to get your database, getting your code may be just as easy. The purpose of a salt is so it can't be subject to a rainbow table attack. But of course they would be able to generate a rainbow table but it may take too much time to do so.

ponsfonze
  • 1,332
  • 11
  • 13
  • Right, but if they had then encrypted salt, how would they know it was encrypted? And if they discerned that, how would they ever get the key unless they could get to the code? And if they could get to the code, then they would see the process of salting and hashing, so all of the preventive measures that I took would be gone anyways? Sorry I'm just trying to understand whats the big deal with salting and hashing instead of encryption and using keys. =) – Aust Jan 27 '13 at 00:24
  • 1
    The idea behind salting is that even if they know the salt, and know your hashing algorithm and everything, they still need to do a brute force search trying out all possible passwords until they get the right one to crack _one single user's_ password. Without salt, they can try passwords until they guess one that _any_ user has used. So if you have a million users, they can crack a million passwords instead of a single one if you don't use a salt. – gnasher729 Jun 24 '14 at 12:47
  • Once an attacker breaks into your site, you assume they have access to everything on the site, and obfuscation doesn't help. – gnasher729 Jun 24 '14 at 12:50
  • 1
    "Normal salts are going to be stored in the code as well." I thought salts are supposed to be stored in the database. They're supposed to be unique per account so there wouldn't be enough room in the code. – Buge Aug 19 '14 at 14:47
  • @Buge What I had meant here was, there is usually going to be 1 salt stored in the code, not one for each hash. Having a unique salt for each hash may increase the time it takes for a particular brute force attack on the hash, however that is not the purpose of a salt. There might be a better way of increasing the resistance to brute force attacks by increasing the interations of your hashing algorithm. You can store salts in a database as well as in the code. The security between these two methods may be a seperate question. – ponsfonze Aug 19 '14 at 16:03
  • 1
    "there is usually going to be 1 salt stored in the code, not one for each hash." [This highly rated answer](http://security.stackexchange.com/a/17435/50123) says "A salt is a random unique token stored with each password." If you're using a global salt you're limiting its effectiveness. Of course you should use key strengthening also, but you can only do so much of that because it slows you down as well. Unique salts don't slow you down. – Buge Aug 19 '14 at 21:02
  • 1
    One problem with reusing the same salt for different users is that same password + same salt -> same hash. If you see a large number of users with the same hashed password, that's a big clue that it's probably one of the really weak, really common passwords. – Kevin Mar 26 '18 at 15:01