Hacker News Reader

Comment by kibwen | Hacker News Reader

Perhaps users would be better served by salting their passwords manually before signing up for any web services. If your usual throwaway password is "Passw0rd1", try "eharmonyPassw0rd1" for your eHarmony account, and "linkedinPassw0rd1" for your LinkedIn account.

At this point, I can't even tell if this is sarcasm.

View on HN

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).

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.

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.

> > 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.

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.

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).

Reply on news.ycombinator.com