14

Is it okay and isn't useless? It could be saved in another table or even another database.

What do you think?

P.S. For higher security, I have the constant salt "peanuts" too. It's constant value saved in configuration file (not in database). So if hacker want to somehow hack password, he need access to file server and database as well.

mgiuca
  • 20,958
  • 7
  • 54
  • 70
daGrevis
  • 21,014
  • 37
  • 100
  • 139
  • 2
    Does your platform not have a decent signin/security implementation? Reinventing this stuff is risky, no matter how hard you think about it. – spender Jun 16 '11 at 12:56
  • I'm using Kohana and there is ready-to-use module for that. This is more for my own knowledge and so on. – daGrevis Jun 17 '11 at 11:45
  • "I have password "peanuts" too". Do you mean that you have an *added constant salt* "peanuts"? In that case it makes sense (and that's the way your accepted answer interpreted it). – mgiuca Jun 20 '11 at 01:41
  • @mgiuca With "peanuts" I meant constant value that's stored on file-server. It's hashed in with password and salt. – daGrevis Jun 20 '11 at 12:58
  • OK then if you don't mind, I'll edit the question to change "password" to "constant salt", since "peanuts" isn't really a password. – mgiuca Jun 22 '11 at 10:08

2 Answers2

27

Yes, it's okay to store the per-user salt in the same table which stores the password hash (not the password itself) - even if the adversary gets access to the raw database data, he'd still need to try each user's salt+password separately; storing the salt in another table is not really adding any significant security (if you assume the adversary has access to the database, it doesn't make much sense to me to assume he only has access to one part of it).

If you're using salt+peanuts+password to create the password hash, then I'd say that your design is safer than 80% of the systems out there - which is to say, reasonably safe without going overboard with paranoia.

Note however, that if you're actually storing the password in recoverable form (encrypted or plaintext), you're throwing any security out of the window - the whole point of salts and hashing is that you are not storing the password in recoverable form. If you do store the password, that is the weakest link of your system, which is then completely insecure. To make things clear: the user table should only contain the salt and hash of salt+peanuts+password, never the password itself.

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
  • 1
    I get the salt and hash, but What are peanuts? – Antony Jun 06 '12 at 13:50
  • 4
    @Antony: They go well with salt ;) It's a way of referring to a per-application salt, likely stored on the application server (so that in case of a database compromise, part of the salt is still beyond the attacker's grasp). Also called "pepper", in the same humorous vein. – Piskvor left the building Jun 06 '12 at 16:27
3

You want to store 1) the per-user salt and 2) the result of hashing password+salt). You do not want to store the password itself.

Robert Levy
  • 28,747
  • 6
  • 62
  • 94