0

Have gone through several questions on this topic at SO, and am unable to find answers to this specific query. I've seen Salting Your Password: Best Practices? and the excellent answer to Non-random salt for password hashes, which both have very helpful guidelines, but doesn't have a clear guideline on storage.

Is it advisable to have the hash, random salt and iteration count all in the same table? If not, what is a suggested approach?

I do understand that rainbow tables can't be made easily with random salts in place, even if we have them together. The question is because there are many simple extra deterrents that can go a long way. For example, have the salt in a different table (injections usually leach a table, not a DB) and the iteration count in a different tier (say, a constant in mid-tier).

Community
  • 1
  • 1
fozylet
  • 1,279
  • 1
  • 13
  • 25
  • 5
    I think you have to assume that a motivated attacker will get *all* the data stored by your system, no matter where you put it. – Greg Hewgill Jun 11 '12 at 05:46
  • Agree, that it is only a minor deterrent to split the table. What about the iteration count. Isn't it best maintained as a constant in mid-tier? In case of a (unlikely) count change in future, it can be managed by the last-logged-in time-stamp to convert successful logins to new iteration count. – fozylet Jun 11 '12 at 05:50
  • 1
    As Greg noted, you should design your system to keep passwords in a format that is very difficult to break even if the attacker knows every bit of information about the password. Keeping things in a different tables is not a deterrent, and shouldn't be used as an excuse to relax your security in some other place (Not saying that you will). Assume that any injections WILL get your entire database. – Alex Lynch Jun 11 '12 at 05:52
  • More suitable for http://s.tk/crypto ? – Cheekysoft Jun 11 '12 at 10:08
  • @Cheekysoft is it possible to move this? – fozylet Jun 13 '12 at 08:10
  • Questions can be flagged for moderator attention with a request to move. Sometimes that can take quite some time though. Another option is just to start a fresh question there. However make sure you look at Rory's links to similar questions over at s.tk/security – Cheekysoft Jun 13 '12 at 08:39

2 Answers2

2

We have answered this question in various forms over on Security Stack Exchange.

These are similar in concept to your approach of holding all the information in the same table.

@Greg's comment is partially right - a determined attacker will be able to get all the data eventually, but the key here is around timing. A skilled attacker, given enough time and resources will be able to access your systems - the key is to making it difficult or noisy enough that you spot it in time.

From one of cryptographer Thomas Pornin's posts on our Security Stack Exchange blog:

  • Why passwords should be hashed - we hash passwords to prevent an attacker with read-only access from escalating to higher power levels. Password hashing will not make your Web site impervious to attacks; it will still be hacked. Password hashing is damage containment.
Community
  • 1
  • 1
Rory Alsop
  • 1,441
  • 25
  • 38
  • 1
    Those questions seem discuss about how to compute the hash, not about how to store the pieces or how to split responsibilities between mid-tier and DB. – fozylet Jun 11 '12 at 13:10
2

It is the normal pattern to store the salt and iteration count together with the computed hash.

The salt is not a secret. A salt 'works' by being different for each computed hash. If the attacker knows the salt and iteration count, it does not help him in any way.

Jacco
  • 23,534
  • 17
  • 88
  • 105
  • Agree about the salt. What purpose does the iterations serve, if the count is available right away? – fozylet Jun 11 '12 at 09:37
  • You could change the iteration count when in the future. So, if you store the iteration count per hash result, you can always do the correct number of iteration when you want to verify them. – Jacco Jun 11 '12 at 10:44
  • If they have a salt, it's then possible to crack the hash. –  Jun 11 '12 at 18:26
  • If they have the salt, it is indeed possible to break the hash. BUT this is not the point of the salt. A salt is not meant to be a secret; it is intended to prevent attacking N hashes for the cost of less than N hashes. I also invite you to read [my long answer on salting](http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190) – Jacco Jun 12 '12 at 07:30
  • @Jacco Agree that random Salt is about slowing down, than about being a secret. My question is about furthering the slowing down. Not readily getting hold of the iteration count (by keeping it in mid-tier) would definitely make it necessary to hack the mid tier as well. I would go to the extent of making it a constant (and not a config) so that reverse engineering is necessary. – fozylet Jun 13 '12 at 08:05
  • @fozylet, By deviating from the standard pattern, you *might* gain some security, but at the same time you introduce a) increased complexity and b) a non-standard pattern (hence, less well tested). So my advice would be against it. Usually, when your attacked has access to the password-hashes, he or she can also access the actual data. or in the words of [Greg Hewgill](http://stackoverflow.com/users/893/greg-hewgill) (first comment on your question): "You have to assume that a motivated attacker will get *all* the data stored by your system, no matter where you put it." – Jacco Jun 14 '12 at 08:01