Am I correct in thinking that the amount of entropy added with cute tricks like this is essentially nil? Is this advice even remotely valid?
Never give your password to others or write it down.
I don't think the advice to never write your password down is very useful unless coupled with a better way to manage all of your passwords besides memorizing them (like a password manager).
I also find at least a little bit hilarious that Linkedin is lecturing us on security best practices. The main reason you need a strong password (assuming lock outs are in place) is because this kind of thing happens.
I think it is just the opposite.
If you assume that password databases get compromised every now and then, then obviously you shouldn't reuse the same password everywhere. Even a strong password could become public if some badly implemented service stores it in plain text.
And if you don't reuse passwords, then they don't need to be strong (i.e. resilient to an off-line attack where billions of possibilities can be tested per second). There is no point in keeping that password safe if the associated service has already been hacked to the point of losing their password database. Therefore, a password that can withstand online guessing attacks is sufficient.
"It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases."
Still doing it wrong I see.
Depending on how it's done, wouldn't a hash of an unknown salt + password be impossible to translate back to plaintext? Even if the salt is known, as long as it changes per user, doesn't that make the look up incredibly time consuming? (Honest questions)
TLDR: PBKDF2, bcrypt, and scrypt already do salting, hashing, and stretching, and better than any roll-your-own scheme.
A salt protects you against rainbow tables of precomputed hashes of known words. It's still possible to just try all possible inputs and check the resulting hash against the list - and on GPUs it can actually be faster than reading rainbow tables from a disk.
Remember you don't need the original password, just any string that hashes to the same value. The one thing a salt does give you is that you can't crack a single passwd and then check for all other entries with the same hash = users with the same passwd.
But if you use a weak hashing function (sha-1 isn't state of the art) it may be that collisions, with different shorter keys producing the same output, are more likely than you would expect from the number of bits.
Really? How long does it take to verify that this breach is accurate and sound an alarm?
Now it's time for them to own up to the mistake and inform their users, before anyone has anything else compromised.
http://tech.dropbox.com/?p=165
The advice from LinkedIn like "Don't use a word from the dictionary" and "Substitute numbers for letters that look similar (for example, substitute “0″ for “o” or “3″ for “E”." are security theater.
