2

I read many answers on the stackexchange about Bcrypt, Salt and Where exactly to place the salt. For hashes such as BCrypt it is trivial to extract salt from the hash. So, It doesn't matter really where you place the hash. But, I am assuming here that a hash is generated such as hash(plain+salt) or something as such.

Most people recommend that, the best way to put salt is in a different column or alongside with the password hash itself. As far as I understand, this also improves performance for credentials validation easily. And also I assume the server side ensures different salts are used to hash different passwords. So, in case of database is leaked, Attacker will have to compute Rainbow tables for all the hash+salt which is tedious.

But, I am considering an edge case here. Let's assume the attacker is specifically interested in cracking password for one particular user. Attacker dumps the database, gets access for the Hash, and Salt as both are either placed alongside each other or in different columns. Now, attacker will be able to build a custom rainbow table for that salt to run attacks.

So, assuming if you are going to do a trade-off between timing to check password & security, Isn't storing salt alongside with password a bad idea?

Wouldn't you prefer using a secondary, isolated database just for storing the salt with respect to id field to pin point which id the salt is applicable to in the users table in main database?

Would not that be a better option rather than the option which I see daily on Internet everywhere? Or are there any other better options than this ? I do not mind trade-offs between timing/performance of the webpage & security.

Stefan
  • 21
  • 2

2 Answers2

4

Now, attacker will be able to build a custom rainbow table for that salt to run attacks

I don't think you understand what a rainbow table really is and how much effort it is to create one. Basically a rainbow table is a trade-off where one invests lots of time (and memory) initially and then can crack lots of password hashes faster, as long as the relevant hash is covered by the rainbow table. To crack a single password it is way faster to just brute-force it instead of creating a new rainbow table with the specific salt. The protection against attacks based on rainbow tables is thus not to hide the salt but to use unpredictable and sufficiently long salts so that the attacker does not have already a pre-built rainbow-table.

In other words: there is no need to protect the salt against the attack you imagine.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Great answer. So, for Hashes such as Argon, Bcrypt, the best case seems to keep salt long enough and within the same database. For a password scheme such as `hash(plain+salt)`, would you still prefer keeping salt in the same database? Because in this case, `salt` information will only be with attacker if and only if database is leaked containing the `salt` value. Although, cracking that chosen one password is still hard as there can be many combos like `plain+salt` , `salt+plain` , `p[:1]+salt+p[len(salt)+1:]`, etc. So it's still a hypothetical success rate for attacker here – Stefan Feb 22 '19 at 05:34
  • 1
    @Stefan: If you care about protecting the users password then don't use a simple scheme like `hash(plain+salt)` in the first place. Don't try to improve a bad method by putting the salt somewhere else but use established and known good methods instead. – Steffen Ullrich Feb 22 '19 at 06:07
0

I think you misunderstand the purpose of salts.

The purpose of a salt is not to make cracking an individual password using brute force any more difficult!

The actual purpose is simply that two users with the same password, should not have the same hash.

If you could look through a database, seeing 3 users with the same hash, it would be likely that this is a common/weak password. It would not be possible to see that these users have the same passwords if salts are used. Pre-computed hash tables are also pretty much useless when passwords are salted.

If an attacker has compromised your system, you will not get additional security by having an extra database. Keep things clean. Obfuscation is not security.

Tobias Bergkvist
  • 496
  • 4
  • 7
  • Salts are used to serve purpose in [Security](https://en.wikipedia.org/wiki/Salt_(cryptography)) as well. But, let's assume here that an attacker wants to crack only one hash and more importantly he/she has the salt. Now, as the attacker's search space is less. They will generate a hash-table / rainbow-table and try to perform attack over the compromised hash+salt. The question here is not that the users are dumb enough or not to choose password like `12345`, the question is how would you make life tougher for an attacker in an edge case of data breach with Salt+Hash. – Stefan Feb 22 '19 at 04:50
  • Additionally, I am _keeping aside_ the performance of password checking mechanism and complexity of the implementation here just to see what maximum protection can be achieved in case of a data breach – Stefan Feb 22 '19 at 04:53
  • It seems like you are trying to use salts for something other than its intended purpose. **Their ONLY purpose is to make sure two users with the same password does not have the same hash**. I mean, you might as well divide up the hash itself and split it into different databases. If an attacker compromises your system, it doesn't matter that you use different/multiple databases, as they will have access to all of them. – Tobias Bergkvist Feb 22 '19 at 05:01
  • Valid point that their purpose is to make sure two users with same password do not have same hash. Agreed. But, let's think three perspective here for a hashing scheme `hash(pw+salt)`. Case 1 as you said was split hash into different db. (smart counter answer lol) but let's think that it is at computational heaviness scale of 8/10 with security scale of 10/10. But, I can achieve a the same security scale with 4/10 computation scale for placing hash in isolated db (case2). Case-3 is keep in column will be 1/10 comp. but 5/10 in security and also then using `hash(pw+salt)` will be useless too! – Stefan Feb 22 '19 at 05:13
  • If I am to implement an approach to keep the salt in the next column to the hash (or even alongside it). I would prefer ditching the `hash(pw+salt)` approach as it renders total useless in an case of a data-breach as attackers will still able to guesstimate the pattern `pw+salt` (although there can be couple more permutations) for _that_ particular targeted a/c. So, based on all the discussion the best idea seems to use the _salt_ in hashing algorithm which are within password itself (e.g bcrypt) which you don't care even if leaked. – Stefan Feb 22 '19 at 05:22