Is it me or is individual salting rather redundant.
I can see why using one salt forevermore is rubbish but if I salt a different user with a different lt each time, but I need to keep that salt in plaintext next to the hash. Making the whole salting thing a bit redundant if I get a linked in style loss
I certainly see a benefit in padding out user passwords to say 128 bits each time, combined with crypt it will slow down any mass brute force /rainbow attack.
Pre-edit edit: I just answered my own question did I not.
If I understand your point correctly, you're asking how critical it is to always give different/random salts to each password?
Even if you know that hash('password', 'salt1') hashes to a a user's hash, you'd need to recompute hash('password', 'salt2') to check if it's the hash for someone else. It slows them down by increasing the amount of work. If they had the same salt it would be the same hash for multiple users.
Sort of - I had always thought of a salt as another password - something to keep secret so that if the dbase of hashes was lost, there was an "unknown" component that would take an age of searching to find.
This logic is clearly flawed - if they have the dbase they presumably have everything.
So I now understand more clearly - salts are there to
1. pad out the plaintext to increase time to compute
2. convert plaintext from commnly used words (pass1) to
unique plaintext, reducing the ease of cracking multiple
passwords.
In short, salts help slow down the attacker when he has all your hashes. Just like bcrypt et al.
I can see why using one salt forevermore is rubbish but if I salt a different user with a different lt each time, but I need to keep that salt in plaintext next to the hash. Making the whole salting thing a bit redundant if I get a linked in style loss
I certainly see a benefit in padding out user passwords to say 128 bits each time, combined with crypt it will slow down any mass brute force /rainbow attack.
Pre-edit edit: I just answered my own question did I not.