Hacker News Reader

Comment by mseebach2 | Hacker News Reader

You could at least bcrypt them all with the same salt, however, it's a long step backwards from individual salting. Also, then you can't check for "[common base password][phone number]" or some variation that's exactly as dangerous as just using a common password - if you kept a plaintext list, you could do substring searches.

The more important lesson here is probably that your users insisting on using crappy passwords isn't really a problem for technology to solve. If you users aren't in the mindset of feeling an obligation towards protecting the data, there are much bigger holes in the network than password complexity enforcement.

http://www.smbc-comics.com/comics/20120220.gif

http://www.theregister.co.uk/2008/04/16/password_security/

View on HN

I think that the main problem is always going to be the end users. I'd like to say that fingerprints or iris scans would solve the issue, but they have their own problems (e.g. having a backup password in case prints or scans aren't recognised).

I agree that it really should be the user's attitude that needs to change, but there will always be that one person even if the other 99% of people get things right - so I think that at least trying to build a system to compensate for this is just as worthwhile as educating users.

I quite like the idea from XKCD [http://xkcd.com/936/] of using words instead of letters (but also have a few problems with it), perhaps rather than having passwords, we should have pass sentences that also have requirements (8 words of more, at least 2 punctuation marks, for example) or are generated for the user (could be nonsense sentences or contain misspelt words).

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.

And he was enlightened...

Reply on news.ycombinator.com