3

Commonly when implementing authentication mechanisms that accept passwords is to add salt when hashing the password.

Reading the article here: https://engineering.gosquared.com/evolution-of-password-security (section 4)

is there any actual benefit for doing this? There's a link to an article, listing benefits for decoupling hashes from the users, making brute force attacks even harder since the hash related to the user isn't the actual password hash.

I'm interested in knowing whether this actually helps, or if it's a case of 'security by obscurity'.

note: not asking whether salt is beneficial to hashing passwords. The question is whether decoupling the salt/hash data is beneficial to security.

closed as unclear what you're asking by ThoriumBR, Steffen Ullrich, gowenfawr, Rory Alsop Apr 5 at 14:46

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Possible duplicate of Why are salted hashes more secure for password storage? – ThoriumBR Apr 4 at 14:47
  • @ThoriumBR I don't see how this is a duplicate. Could you elaborate? – Luc Apr 4 at 14:55
  • OP is asking why is useful to use salts on password hashes, and that question explains why salts are used. – ThoriumBR Apr 4 at 15:24
  • 1
    @ThoriumBR OP isn't asking why salt at all, OP is asking whether it is useful to use two salts on password hashes, where one of them is decoupled from the user account to prevent them from being linked when one lacks the correct password. Have you read their links? – Luc Apr 4 at 15:40
  • 2
    The question requires everybody to read the links and find the parts which the OP might refer to (but does not explicitly say so) in order to even understand what the OP is asking. It looks like this leads to various ways the question could be interpreted, depending on what one sees as relevant from the linked articles. I think the question should include all relevant information and context in the question itself instead of hoping that others find these in linked articles. In the current form I therefore propose it to be closed as unclear what is asked. – Steffen Ullrich Apr 5 at 5:38
7

This does not have any serious benefits as far as I can tell.

To summarize the content you linked, the idea is that you don't have a row with the username and hashed password:

users = [
  {"username": "admin", "salt": "PyoBT3KBnn31qDP9", "password_hash": "e53992bb5f7af6f51773ad8ea3033d66"},
  {"username": "someuser", "salt": "2IY3VczmbhHyEMQJ", "password_hash": "a7d38c0493cf0ff4af602b92c4f77a81" }
]

Instead, you remove the password_hash from the users table, and store them separately in a hashes table:

hashes = [ "e53992bb5f7af6f51773ad8ea3033d66, "a7d38c0493cf0ff4af602b92c4f77a81" ]

(Note that the article from gosquared also has a second hash and second salt, but that is pointless as well---I'll get to that later.)

If you store the username and hash together, an attacker can do a guess, for example that the password is "Pizza7!", compute the hash with the salt, and check if it's correct. When separated, an attacker has to check the result against every entry in the hashes table.

If you have 100 users, an attacker has to match the result against 100 hashes. But only one in 256 hashes has a matching first byte, so most of the time that already won't match. Almost all the time, you're just checking the first 1-2 bytes of the result against the first 1-2 bytes of every user's hash (with some shuffling for cache locality, that can be said to be instant). That is why the author advises to inject bogus hashes, so the table becomes huge. Or maybe you just have a billion users, and your table is huge as well.

If you have a huge table, looping through every hash is not efficient. An attacker would take the first, say, five bytes of every hash in the table, sort it, and keep that in memory. That's five gigabytes for a billion hashes, which easily fits in the RAM of an ordinary computer. Then you apply binary search (also known as bisection search) to find a match in about O(log n) complexity. So for a billion rows, that would be something like 9 lookups.

So you bloated your database to be a billion rows, and all the attacker needs to do extra is a handful of lookups.

But the 5GB database is way too large for a GPU. You can't reduce it to, say, three bytes, because (almost) all possible three-byte values will occur, and regardless, three gigabytes still doesn't fit in these tiny cores. So you made it impossible to do the comparison part on a GPU. However, the hash iterations from something like PBKDF2 or Bcrypt can still be done on the GPU. Only the result needs to be compared against the database in the computer's main memory. Unless you use Scrypt or Argon2, the attacker loses virtually no speed at all. You might as well increase the cost parameter of Bcrypt or the iterations parameter of PBKDF2 (they do the same thing).

Why are Scrypt or Argon2 special? Because they're "memory hard": they already have a memory parameter that allows you to require it to use a lot of memory. Sound familiar? Indeed, that's pretty much the same as using a huge table, except that this prevents the attacker from using a GPU at all.

If you don't use any iterations, for example if you use sha256(password+salt), then this scheme might help you because you add lookups which are a tiny bit slower. If you do something sane (any slow hash), I don't see an advantage in doing this.


The scheme I explained above does not match the gosquared article. They used the scheme as described in the follow-up post from opine.me. There they add a second salt. If you use a secure hashing algorithm, a random salt will always result in a unique hash, so there will not be any collisions in the hashes table, so that is not why. Instead, the reason they give is this:

If an attacker is able to both steal a user’s salt value, and insert a specific hash of their choosing into the Hashes table, they can grant themselves access to a specific user’s account

So the scenario is that an attacker can add values to the hashes table, but not the users table. Let me repeat that: they are trying to block an attacker who is able to write values to one user-related table (hashes), but not to some other user-related table (users). Privilege separation strict enough to create a scenario in which an attacker can write to some tables but not to your users table is very rare to begin with, but I'm all for layered defenses. However, your account creation script will need to write to both tables. And any login checking script need to write to neither. Being able to write to one but not the other is an inconceivably unlikely scenario, there will never be a database user with such a set of permissions.

Furthermore, the author that cooked this up argues the following:

First, I didn’t do a good job in the previous post stating my design goals. scrypt already does a perfectly fine job of letting you tune the CPU and RAM cost of completing a single hash. There’s absolutely no need for any other method than scrypt if all you want to do is tune the CPU and RAM burden on your attacker. What I want to do is two-fold:

  1. Impose additional costs (other than RAM and CPU) on an attacker
  2. Make it easier to detect if attackers start stealing your hashes

[...]

So this approach focuses on increasing the disk storage and bandwidth requirement of copying hashes from a target site.

Even petabytes of data would not do much to the lookup speed. It would no longer fit in RAM, but on-disk lookups can use binary search just as well. You can log in fast enough, so an attacker can do the lookups fast enough as well. You are likely to reduce your security by making your hashing algorithm faster, so that your slow lookups don't make the user wait too long.

Buying loads of hard drives to achieve all this is possible (remember that you also need to make backups of all of this), and I guess if you indeed have a few dozen terabytes of password hashes, it might actually prevent an attacker from getting all of it. Anything less is not going to be useful: network speeds are fast enough, and bandwidth and storage is cheap enough. A few terabytes won't faze any attacker. There are already password dumps of 500GB floating around the internet as torrents.

So then a, say, 40TB hashes table would actually work? The author thinks that you'll detect breaches. In practice, breaches very often go undetected for months. Some companies may notice it fast, but an equal number will be compromised for multiple years before they notice. 40TB takes (40*8*1024/3600/24=) 4 days to transfer over an ordinary gigabit connection. Another issue is storing the data, which would indeed be non-trivial at that size. They would probably have to ask friends and then probably still pool some money for a few extra hard drives. Nothing insurmountable, though. And with 40TB stored on slow, spinning drives, you're almost certainly degrading the slowness of your hashes to accommodate this scheme. And even if you succeed in thwarting the attackers, and they manage to get only 1TB (that fits on any modern laptop), then they still have the hashes from 1 in 40 users, plenty to be a big deal.

It's a huge amount of bulk for a very small amount of gain, assuming you don't degrade the quality (slowness) of the hashes.

Not the answer you're looking for? Browse other questions tagged or ask your own question.