0
$\begingroup$

I'm curious about the security implications of reusing characters from the plaintext as salt.e.g.

$salted_plaintext = $plaintext[1] . $plaintext[7] . $plaintext;

My gut feeling is that it increases security through obscurity, though not as much as a proper salt, as existing rainbow tables wouldn't be applicable and would have to be re-made with this "salt" in place.

Since I'm sure someone will ask: the hash is for comparison of some sensitive data against a list of stored hashes.

$\endgroup$
1
$\begingroup$

My gut feeling is that it increases security through obscurity [...]

Security through obscurity is the name of an antipattern, for good reason. Generally, the way we analyze security measures is by trying to give the attacker as much power as we can get away with.

So we just assume that the attacker knows your construction:

$salted_plaintext = $plaintext[1] . $plaintext[7] . $plaintext;

...and then we can observe that since the salt is a function of the password, two users who use the same password will get the same salt and thus the same hashed password, meaning that for each password guess the attacker is able to test every user's password entry. Same as with unsalted password hashes.

[...] existing rainbow tables wouldn't be applicable and would have to be re-made with this "salt" in place.

The proper answer to that is "meh." GPU password cracking is so fast these days that an attacker might not even consider rainbow tables. See Troy Hunt's article on GPU password cracking, where he demonstrates how he cracked 24,710 out of 40,000 salted SHA-1 hashed passwords in 45 minutes with a $500 GPU and a cracking dictionary he downloaded.

You really ought to read the Information Security Stack Exchange's site popular entry on how to securely hash passwords, particularly the top answer.

$\endgroup$
  • $\begingroup$ So we could say that the salt being constructed in this way is basically the same as just not salting? $\endgroup$ – Maybe_Factor Jan 23 '17 at 22:46
  • $\begingroup$ Think of it this way: what we want is that the hash that we store for every username/password entry is uncorrelated to all other entries, even if the two entries in fact have the same password. Unsalted hashing and your proposal both violate this condition. And that means that once I hash a password guess according to either method, I can then test that hash against every user. $\endgroup$ – Luis Casillas Jan 23 '17 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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