Updating Your Password on LinkedIn and Other Account Security Best Practices(blog.linkedin.com)
blog.linkedin.com
Updating Your Password on LinkedIn and Other Account Security Best Practices
http://blog.linkedin.com/2012/06/06/updating-your-password-on-linkedin-and-other-account-security-best-practices/
6 comments
Agreed on both counts. It would be trivial to add a handful of common replacements like the ones mentioned during a dictionary attack.
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 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.
> 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.
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.
Most of my passwords are written down on a sheet of paper. Even if you knew that the sheet of paper contains some of my passwords, I don't think you'd be able to extract them since there's a layer of encryption between my eyes and my fingers.
xkcd to the rescue once again - http://xkcd.com/538/
There is a good XKCD comic that explains this: http://xkcd.com/936/
And if you check at http://crackedin.s3-website-us-east-1.amazonaws.com/ you will see nobody is using "correcthorsebatterystaple" !
All good brute-force crackers have such substitution rules builtin.
Online brute force is a non-issue, protecting from offline brute force is their responsibility (who cares how long and complex my password is if they store it in clear text). The only relevant advice for any online services is don’t use the same password for anything else and always log in via SSL.
This is getting silly now, the hash for my unique strong password was in the list. And there are many others who have stated the same. It should have taken them a whole of 5 minutes to find if these hashes were from their database. It's shameful and shows an utter disrespect for security that they didn't bother salting them (and sha1 really?).
Now it's time for them to own up to the mistake and inform their users, before anyone has anything else compromised.
Now it's time for them to own up to the mistake and inform their users, before anyone has anything else compromised.
From the updated blog entry:
"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.
"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.
Because I'm obviously missing something: what's wrong with a hash + salt?
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)
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)
http://news.ycombinator.com/item?id=4075873
TLDR: PBKDF2, bcrypt, and scrypt already do salting, hashing, and stretching, and better than any roll-your-own scheme.
TLDR: PBKDF2, bcrypt, and scrypt already do salting, hashing, and stretching, and better than any roll-your-own scheme.
You can't have an "unknown" salt
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.
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.
Of course you have to know the salt, but I'm suggesting something like using a different storage medium, so that one vector of attack cannot get both keys- unknown to the attacker.
I should have made that more clear.
I should have made that more clear.
That's dangerously close to "security through obscurity" - whatever process reads the passwd store has to know about and have permission to read the salt store - so just putting it in a different file or giving it a different name only buys you a false sense of security.
The reason for moving the passwords out of /etc/passwd is that there are a s lot of processes that do need to read the user list but don't need access to the passwd hash. But there is nothing to gain from splitting the salts out of /etc/shadow into a another file
The reason for moving the passwords out of /etc/passwd is that there are a s lot of processes that do need to read the user list but don't need access to the passwd hash. But there is nothing to gain from splitting the salts out of /etc/shadow into a another file
The Dropbox post on passwords (and their password strength estimation tool) is much better at describing what strong passwords actually are.
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.
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.
" At this time, we’re still unable to confirm that any security breach has occurred ..."
Really? How long does it take to verify that this breach is accurate and sound an alarm?
Really? How long does it take to verify that this breach is accurate and sound an alarm?
They will wait for market to close or near the close (like 15 mintes before close): so that market does not pile up on this bad news. They will probably confirm this soon.
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).