-2

In case of password security I often read, that the use of rainbow tables is appreciated. It is possible, that I don't get it right, but my current perspective is just confusion.

You save a couple of salts in a table, but you must reference them in the table with password hash, which allows you to rebuild the password hash. So I would do it like this:

By creating a new password, save hash ( input + salt ) into the table

Table: Password: hash, Salt reference: 123

I thought, this is used to prevent "dictionary attacks", but what happens, when the user uses a password, which is contained by the dictionary. The attacker can easily pass through.

Just a list with events, which are happening in my point of view:

  1. User/Attacker "types" in this login data
  2. Email/Username is looked up and returns salt reference
  3. Look up salt with reference
  4. Build password
  5. Check password in table with email/username

So how can the salt matter, if it is automatically looked up? This might be a bit confusing, but in the end it makes all sense to me.

Jon Lamer
  • 408
  • 6
  • 12
  • 1
    You seem to be very confused indeed. You do not need to store the salt separately at all, the salt is not a secret. Secondly, a salt does not defend at all against online attacks (someone simply trying to log in using all possible passwords). – deceze Dec 27 '13 at 10:05

1 Answers1

0

So how can the salt matter, if it is automatically looked up? This might be a bit confusing, but in the end it makes all sense to me

You're only taking into account the rainbow table approach. What if somebody finds an exploit in your application to show a database table, which contains user passwords?

Sure, they could use the rainbow attack on the exploited table dump, but what if they don't have the power/resources?

Also, read the following;

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks and pre-computed rainbow table attacks

Source

The salt adds an "extra layer of security", as they'd have to pass in password + salt in order to see if the password they've given is that users password.

Sure, you could argue that holding the salt in the database defeats this purpose, which is why I include obfuscation (a little), and include the microtime() they signed up as the salt, which would be held in the registration_date column - in my head, anyway.

Community
  • 1
  • 1
ʰᵈˑ
  • 11,279
  • 3
  • 26
  • 49
  • 2
    Salts are not secret and "obfuscated" salts are, well, maybe a little speed bump, but in no way fundamentally better. Salts are simply used to prevent an attacker from amortising CPU time across a whole database of hashes. – deceze Dec 27 '13 at 10:10
  • @deceze +1. Thanks for clearing that up for me, however obfuscated salts do, in my view and I've no evidence or tests to back this up, slow down the attacker, and possibly cause the attacker to quit due to not finding the salt quick enough. Although a large assumption, and a silly one to make, the attackers are always 2 steps ahead of us, so we need to try and close the gap to maybe 1 step ahead, or ideally, 5 steps behind. – ʰᵈˑ Dec 27 '13 at 10:15
  • If an attacker manages to get a database full of password hashes to work on in the first place, you should assume he also had access to the source code and can inspect your tricky little salting algorithm at leisure. – deceze Dec 27 '13 at 10:17