

Updating Your Password on LinkedIn and Other Account Security Best Practices - bwag
http://blog.linkedin.com/2012/06/06/updating-your-password-on-linkedin-and-other-account-security-best-practices/

======
sofal
_Substitute numbers for letters that look similar (for example, substitute “0″
for “o” or “3″ for “E”._

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

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

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

~~~
excuse-me
xkcd to the rescue once again - <http://xkcd.com/538/>

------
jgrahamc
Seems foolish for them to have posted this. It's not very good advice on
choosing a password and feels like the wrong response to the story about
passwords apparently having been leaked.

~~~
troels
Indeed. It's almost as if they're blaming the victim here.

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

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

~~~
MSM
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)

~~~
excuse-me
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.

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

~~~
excuse-me
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

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

------
ajays
" _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?

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

