3 ms·

It might help, but I think the cracking tools would simply get an update that tries `password` and `<salt>password` (and even `password<salt>`). As the salt is

It might help, but I think the cracking tools would simply get an update that tries `password` and `<salt>password` (and even `password<salt>`). As the salt is guessable (as it is in your examples) it just turns into a cat-and-mouse game that the crackers win every time (since for every one of you there are probably 2 or more of them).

AdamGibbins 14y ago
One of the primary ideas behind salts is to render pre-generated rainbow tables useless. Using a salt like the OP mentioned meets this need. Although I'm unsure to how useful and widely used pre-generated rainbow tables are with modern computing.
- mjschultz 14y ago
  Well, in the eHarmony case we're talking about MD5 hashes, so even if you self-salt the password but still choose a weak password a good password cracker will find the password fairly quickly. As an example, yesterday user rorrr posted this comment: https://news.ycombinator.com/item?id=4076840 https://news.ycombinator.com/item?id=4076840. > > MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. > Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules" Self chosen salt, unknown password, known MD5 hashing method. Fire up a password cracker and feed it in a decent dictionary, and you get the password = "Spiderpig1". $ echo -n "Spiderpig1MD5 rules" | md5sum b520542710812f347432232b2a1fba83 - No rainbow table needed.
  - AdamGibbins 14y ago
    Indeed, the hashing is useless so the salts are rendered ineffective. But again, they're not 100% useless - they still do serve their purpose, to render pre-generated tables useless. But when one can generate them again so quick it provides negligible benefit.
- AncientPC 14y ago
  Self-salting with the domain name serves another purpose: prevents you from using the same password across multiple sites. If your password is "password_linkedin", it's fairly obvious what the salt is. However, most released passwords are not heavily scrutinized. It's most likely that those using exposed passwords will instead try user@email.com / password_linkedin elsewhere. You can also easily change self-salt so it doesn't fit any obvious pattern. What I do is a strong base password, then self-salt with the domain name. For example: Mk3+e1_T2iei I'm using "Mk3+e1_T" as the base password, "2" as a divider, and "iei" are the first 3 vowels of a domain name (LinkedIn in this example).

AdamGibbins 14y ago

One of the primary ideas behind salts is to render pre-generated rainbow tables useless. Using a salt like the OP mentioned meets this need. Although I'm unsure to how useful and widely used pre-generated rainbow tables are with modern computing.

mjschultz 14y ago
Well, in the eHarmony case we're talking about MD5 hashes, so even if you self-salt the password but still choose a weak password a good password cracker will find the password fairly quickly. As an example, yesterday user rorrr posted this comment: https://news.ycombinator.com/item?id=4076840 https://news.ycombinator.com/item?id=4076840. > > MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. > Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules" Self chosen salt, unknown password, known MD5 hashing method. Fire up a password cracker and feed it in a decent dictionary, and you get the password = "Spiderpig1". $ echo -n "Spiderpig1MD5 rules" | md5sum b520542710812f347432232b2a1fba83 - No rainbow table needed.
- AdamGibbins 14y ago
  Indeed, the hashing is useless so the salts are rendered ineffective. But again, they're not 100% useless - they still do serve their purpose, to render pre-generated tables useless. But when one can generate them again so quick it provides negligible benefit.
AncientPC 14y ago
Self-salting with the domain name serves another purpose: prevents you from using the same password across multiple sites. If your password is "password_linkedin", it's fairly obvious what the salt is. However, most released passwords are not heavily scrutinized. It's most likely that those using exposed passwords will instead try user@email.com / password_linkedin elsewhere. You can also easily change self-salt so it doesn't fit any obvious pattern. What I do is a strong base password, then self-salt with the domain name. For example: Mk3+e1_T2iei I'm using "Mk3+e1_T" as the base password, "2" as a divider, and "iei" are the first 3 vowels of a domain name (LinkedIn in this example).