
6.5 Million LinkedIn Password Hashes Leaked - ssclafani
http://translate.google.com/translate?hl=en&sl=no&tl=en&u=http://www.dagensit.no/article2411857.ece
======
jgrahamc
Some observations on this file:

0\. This is a file of SHA1 hashes of short strings (i.e. passwords).

1\. There are 3,521,180 hashes that begin with 00000. I believe that these
represent hashes that the hackers have already broken and they have marked
them with 00000 to indicate that fact.

Evidence for this is that the SHA1 hash of 'password' does not appear in the
list, but the same hash with the first five characters set to 0 is.

    
    
      5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 is not present
      000001e4c9b93f3f0682250b6cf8331b7ee68fd8 is present
    

Same story for 'secret':

    
    
      e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4 is not present
      00000a1ba31ecd1ae84f75caaa474f3a663f05f4 is present
    

And for 'linkedin':

    
    
      7728240c80b6bfd450849405e8500d6d207783b6 is not present
      0000040c80b6bfd450849405e8500d6d207783b6 is present
    

2\. There are 2,936,840 hashes that do not start with 00000 that can be
attacked with JtR.

3\. The implication of #1 is that if checking for your password and you have a
simple password then you need to check for the truncated hash.

4\. This may well actually be from LinkedIn. Using the partial hashes (above)
I find the hashes for passwords linkedin, LinkedIn, L1nked1n, l1nked1n,
L1nk3d1n, l1nk3d1n, linkedinsecret, linkedinpassword, ...

5\. The file does not contain duplicates. LinkedIn claims a user base of 161m.
This file contains 6.4m unique password hashes. That's 25 users per hash.
Given the large amount of password reuse and poor password choices it is not
improbable that this is the complete password file. Evidence against that
thesis is that password of one person that I've asked is not in the list.

~~~
madmaze
I disagree with #5, I had a few of my coworkers check their sha1 against the
DB and most of them were not in the dump. I also checked for truncated hashed,
none of which were found. I have the feeling this is a subset of the full
database

~~~
madmaze
on another note,

my fairly complex alphanumeric+symbol password IS in the dump, though not
prepended truncated with 0's and the other one I found, which my coworker
admitted was too short and alpha only, was in the dump with prepended 0's.

This could validate the fact that the truncated hashes are actually already
cracked.

~~~
nupark2
Mine was 5 characters, alpha and numeric, but no special characters. It was in
there, prepended with 0's.

Whoops.

At the very least, it should have been longer.

~~~
tomh
Same here - mine was all alpha characters, seven characters, and the hash with
five 0's was in the file. Guess who just changed their LinkedIn password
today? And included some numbers?

------
Smerity
"We were curious what would happen to our share price if our company did
something incredibly stupid"

The above comment might seem incredibly harsh, but really, there's no good
excuse for a site this prominent to not have a salted, secure password hashing
system. Even if they started with an unsalted password system, users can be
migrated to the newer more secure system on next login.

The only way I could regain respect for LinkedIn is if we find that these
unsalted hashes were from users who never logged in to LinkedIn after the
security upgrade. From the replies of other HN users who have found their
password hashes in the leaked list, this doesn't seem to be the case though.

I can understand database leaks. Bad things happen. Not being prepared for
such an event however is where I draw the line. These leaks impact users far
beyond just the site at fault.

It's not enough to say users should use LastPass. They don't, and that's the
world we live in, for better or worse. If computer security doesn't take into
account problematic users, then it's flawed computer security.

~~~
Jabbles
Surely just hashing the username|password would massively reduce the
effectiveness of leaks like this? Sure, a hacker would know what the "salt"
is, but since it now varies between users you would expend the same amount of
effort breaking one person's login as you previously would spend breaking
everyones (on average).

(Not recommending it, just wondering if my reasoning is correct.)

~~~
Smerity
I hear this commonly, so it is a good idea to clear it up.

Usernames have lower entropy than a random salt and are predictable in many
cases. People re-use usernames and some usernames are common. If your password
system became common on the web, or if I knew the workings of your password
system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I
could generate a rainbow table for either common or targeted users. This means
I could generate a rainbow table for "Jabbles", gain access to your password
and compromise your account before the website is likely even aware of a
breach or has time to warn you. Salts only act to slow down, not prevent,
compromising leaked password hashes (as you can always brute force which is
quite practical with MD5/SHA1). Thus, using a username defeats one of the
stated purposes of salting.

It's also said ad nauseam (with good reason) but rolling your own in security
is a bad idea, especially when libraries exist that do exactly what you'd
intend to do just as easily. Algorithms such as bcrypt and scrypt exist and
are well vetted. bcrypt is easy to integrate with many languages and provides
a trivial interface and sane defaults for iterations/rounds [brute force] and
salts [rainbow table]. bcrypt can also handle increasing the security of your
system over time as the metadata is stored as part of the hash.

tl;dr Using a username for salting means a targeted attack against a single or
small number of users would be damn near impossible to stop as the second they
have the password hashes they also have the passwords.

[1]: <http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle>

~~~
taybenlor
Often people say "Don't roll your own security" but the reality is that
developers aren't trying to roll their own. They are trying to solve a
problem, and if a quick google doesn't turn up a good library then they'll try
and figure it out. Googling for password security implementations is likely to
be fraught with horrible horrible advice.

I guess what I'm saying is that it's not enough to say don't do it, instead
the defaults need to be there (and very visible).

~~~
Smerity
I think we've reached a point with bcrypt that a good secure password system
is within reach and comes with sane defaults and ease of use as features for
most programming languages.

If it's just an issue of getting the word out there, then I'm hopeful things
can improve.

~~~
taybenlor
You need more than just bcrypt. You've hinted at other things, but a few
random things popping in to my mind:

    
    
      * Preventing password logging (many web frameworks log parameters)
      * Secure password recovery
      * New alternative attack vectors (eg. Facebook, Twitter auth)
      * XSS and CSRF
    

There are so, so many simple to make security errors, and worse - many of them
are inter-related so that forgetting one will make another vulnerable. This is
why you need safe defaults and more Security education.

~~~
tptacek
A strong password hash doesn't gate on any of those things, so, while you do
indeed need to pay attention to them, you don't need to pay attention to them
before you deploy a strong password hash.

You should deploy a strong password hash immediately.

~~~
Hannan
True point and this is probably off topic, but out of curiosity, what is the
recommended approach for his point about logging messages/requests?

On previous projects, we've gone through all sorts of machinations to detect a
password in our SOAP logging. This usually involves XML parsing (slow,
ineffective on malformed messages) and Regexes (ineffective on malformed or
"unusual" messages).

I can't think of anything better, short of "you can't leak what you don't log"
which is nice in theory but not always practical.

------
Zirro
They just tweeted this:
<https://twitter.com/LinkedIn/status/210356987576324096> \- "Our team is
currently looking into reports of stolen passwords. Stay tuned for more."

~~~
Aqua_Geek
And a follow-up: "Our team continues to investigate, but at this time, we're
still unable to confirm that any security breach has occurred. Stay tuned
here."

<https://twitter.com/LinkedIn/status/210390233076875264>

~~~
Splines
If people are finding their unique password's hashes in the database, that's
pretty damning evidence that a security breach has occurred.

------
swombat
Am I glad that I use LastPass and have a different, 12-character password for
every service?

Why, yes, yes, I am. I've now changed my LinkedIn password, too, just in case.

~~~
Zirro
What's kept me away from such solutions are these questions: How can you trust
one service with all your passwords? What if their configuration has a
vulnerability?

~~~
joelhaasnoot
KeePass works well too - open source, offline solution that has an "Autotype"
function. I actually only run into passwords that are a pain on mobile
devices. Now that my Android phone has no keyboard but tons of power, that's
becoming more and more significant.

~~~
miniatureape
I use keepass too. I keep my database in dropbox and use the android dropbox
and keepass clients on my android. Logging into an app or website involves
opening dropbox, clicking on the database[1], entering my password, choosing
the site, and clicking on "copy password to clipboard." It's a few extra
steps, but it's not that much of a hassle.

[1] I find this easier than opening keepass and selecting the database from
dropbox for some reason that might be as simple as dropbox having an easier to
spot icon.

~~~
king_jester
You can also use the favorite feature on Dropbox to keep a fresh copy of the
database on your phone and have KeePassDroid remember that location. Then your
flow is 1) open KeePassDroid 2) enter password 3) select site 4) copy/paste

------
judofyr
> \- With a computer of 8,000 NOK (~ 1400 USD), you can do a few hundred
> million attempts per second.

Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using
no iterations? Jesus.

~~~
avar
To expand on that, to store passwords don't just use salt+sha1, or try to do
your own nested sha1, just use bcrypt: <http://en.wikipedia.org/wiki/Bcrypt>

~~~
romaniv
I wonder, why do people saying "just use bcrypt" never, ever bother to
elaborate on what benefits it has, and which of them are relevant to the
subject of the conversation? _Believing_ in some function without
understanding implications of its use does very little for real security.

~~~
dchest
Because the answer to your question is one Google search away. HN people are
tired of explaining it every single time bcrypt comes up.

~~~
Symmetry
Also, there's already an answer in the thread
<http://news.ycombinator.com/item?id=4073839>

~~~
romaniv
It's not an in-depth answer. It does not say, for example, why bcrypt is more
secure than nested SHA1. (I believe it has to do with the possibility to
efficiently implement SHA algorithms in GPUs.)

People are using unsalted SHA1, because someone told them in the past "just
use sha1". Now someone else tells them "just use BCrypt". Without
understanding why, it's nearly impossible to to decide which security policy
is sensible. There are many different types of advice competing for attention,
and not all of them are good.

~~~
tptacek
Somebody once said fire was composed of phlogistons. Later, different people
said that fire was instead a process of decomposing fuel molecules and a
release of visible light due to the energy of the chemical chain reactions
taking place inside the flame.

The guy who said "phlogistons" was wrong. So was "just use SHA1" guy.

------
smiler
I've just downloaded the database linked and it only contains the hashed
passwords, not the account usernames / e-mail addresses.

I wonder if someone has the account details to match up otherwise you've no
idea which password belongs to who, and you'd hope that LinkedIn would have
lockout functionality.

~~~
madsr
Keep in mind that whoever leaked the hashes is probably keeping the usernames
/ emails for themselves. The forum in question doesn't allow posting of user-
identifiable information according to the forum guidelines.

The leaked hashes seems to be SHA-1. I've also confirmed that the hash of my
own (semi-complex) LinkedIn password is in the list. Accidentally this is the
same password as I had for HN and that I've now changed (phew! THAT'd been
bad! :-)

~~~
philip1209
As a more general question: why is it not an industry standard to salt with
the username/email in addition to the random key? (i.e. Sha1($salt + $email +
$password)). Even if the random salt were excluded, I would think that this is
much more secure. Existing rainbow tables would not be anywhere near as
helpful, and attempts to generate a rainbow table for a specific salted
database would be ineffective because the salt changes on a per-user basis.

~~~
stephen_g
The solution is to use a better method of storing passwords. Hashes like SHA1
are designed to be really fast (great for hashing data but also great if you
want to brute force).

I think this is a pretty good overview: <http://codahale.com/how-to-safely-
store-a-password/>

------
jnorthrop
Other sources are starting to report this as well:

[http://blogs.computerworlduk.com/unscrewing-
security/2012/06...](http://blogs.computerworlduk.com/unscrewing-
security/2012/06/if-it-turns-out-that-linkedin-passwords-have-
leaked/index.htm)

[http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-
lin...](http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-
linkedin-6-5-million-hashed-passwords-reportedly-leaked-change-yours-
now/?awesm=tnw.to_1EhVq&utm_campaign=social%20media&utm_medium=Spreadus&utm_source=Twitter&utm_content=Bad%20day%20for%20LinkedIn:%206.5%20million%20hashed%20passwords%20reportedly%20leaked%20-%20change%20yours%20now)

------
tazzy531
Good Guy Startup Founder would cross reference this password list with their
own password system and force those that match to reauthenticate and change
their passwords.

This wouldn't be difficult to do and your users would appreciate it.

~~~
jere
How would one cross-reference this list unless you're storing the plain text
passwords?

~~~
ryusage
The released passwords are hashed with SHA1. Assuming you use the same
algorithm and linkedin does not use a salt (they probably do), then you could
just compare the hashes.

~~~
veemjeem
LinkedIn passwords are not salted. You can only make comparisons if your
database contains unsalted passwords. And if both databases used salted-
passwords, then you still can't compare unless you all shared the same salting
key.

------
joelhaasnoot
Database is available here
[https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO...](https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp%2BmuGtgOEptAS4%3D)

(Source: twitter, haven't looked at it myself)

~~~
mkjones
Those just look like hashes - are there usernames / salts somewhere? They do
indeed seem to be salted.

~~~
pimeys
No they're not. I tried the following:

> irb

> require 'digest/sha1'

> Digest::SHA1.hexdigest 'my_password'

=> _hash_string_

Then I searched the file with the hash string and found my password. I really
hope they don't also have the usernames somewhere.

~~~
mkjones
Interesting, I tried this with a bunch of different passwords (though using
php's sha1 function, which obviously gives the same output as ruby's), and
found no matches. You're using the "combo_not.txt" file from the zip file in
the ggp, right?

~~~
toyg
The dump is not complete -- my password is also missing. As other people said,
that file contains about 6.5 million hashes, while LinkedIn has 30 times more
users.

Considering how usernames weren't leaked, there's a big chance that the
intruder is just sitting on them and the other passwords.

~~~
Ecio78
My password is missing too (if i've done right the hash generation as
illustrated above). It's strange that only hashes starting with "000000a9" are
present, someone said here that it's just presentation but my hashed password
is 40char long as those leaked including the 000000a9

~~~
thaumaturgy
Either you don't have a complete file or you haven't scrolled through it. Only
the first 277 hashes start with that string (and some others scattered
throughout).

~~~
Ecio78
i was talkin about hashes starting with 0000 (i just looked at the beginning
and the end of the file). jgrahamc posts is useful, if i dont consider this
0000 (that could be a sign of "ok we've decrypted it" i can find my hash
(password was not very difficult)...

------
toyg
I wonder, what if this list wasn't leaked from LinkedIn databases, but rather
from some third-party service using the "enter your password" anti-pattern? A
flaky service like that would likely not be very good at safely storing
passwords.

Unfortunately, LinkedIn keeping mum on the subject makes it easy to speculate
that it was actually coming from them. Otherwise it'd be easy to deny (and
even spin: "How dare you! We never store unsalted hashes, we follow state-of-
the-art practices here!!"). Also, their security track record is...
embarrassing as it is.

------
smoyer
I wonder how many LinkedIn users use the same passwords for all their
accounts. The article talks about identity theft and "confidential contacts"
but I think the real danger is that people tend to use the same password
everywhere. It's their other accounts that might have real value.

 _EDIT_ \- As I think about it, e-mail accounts would be especially valuable
as most of your other sites could be compromised using the "recover my
password via e-mail" feature if the hacker could read the resulting mail.

~~~
jere
Me. Admittedly, it's stupid as hell, but has generally been too much of a pain
to do anything else (for things outside of banking, email). I've started to
get serious about KeePass lately, but I bet a significant percentage of users
take the lazy approach.

~~~
Zirro
I've developed a system (kept only in my head) where every password I use is
based off on the name of the service. This means that with just one of my
passwords, you're most likely not getting anywhere. With two, you have a
bigger chance of figuring out the differences and thus the system, but it
works fine for me at the moment.

~~~
engtech
Other than the simple top 100 password list, a password based on the name of
the service is the most likely password that everyone has.

Usually something like "domainname"+"common password for all sites"

~~~
Zirro
Don't underestimate me. It contains many numbers extracted from the letters
according to various rules (order in alphabet, backwards, etc), along with
special characters.

------
bermanoid
Whatever manager it was that tasked some junior programmer (particularly one
that didn't know that unsalted SHA1 is a terrible idea) with implementing the
password system at LinkedIn needs to be fired. Making the programming mistake
means that you don't know much about web security, and while not a great
thing, that's forgivable; putting someone that's utterly unqualified for code
with security implications on such an important task is not. Nor is letting
the code get deployed without having someone that knows what to look for
review it. Nor is letting such a bad decision remain live for...what is it
now, almost 10 years?

But let's not stop there. There are probably a dozen other people at the
company whose job it is to avoid blunders like this, all the way up to the top
technical staff. After all, LinkedIn is not, and has not been for some time
now, some tiny underfunded startup. It's a goddamn public company, and even
before that it was a super-team Silicon Valley darling that was getting money
thrown at it since even before tech became cool to invest in again, and it's
been valued at over a billion dollars for almost five years now. There is
_absolutely_ no excuse for this, they should have been doing regular security
audits for years, and no audit worth its salt would miss something this
simple. I absolutely refuse to believe that this problem was unknown, that
nobody _ever_ commented or filed a bug report about this code - no, this was
_deprioritized_ , because it wasn't considered a high enough value problem.
And now it's bitten them in the ass and become a problem, probably because
some other security vulnerability was similarly deprioritized instead of
fixed.

I expect this from some shady Bitcoin market that a high school kid runs off
of a server in his bedroom. I do not expect this type of amateurism from a 10
billion dollar company with hundreds of engineers, many of whom have
specifically looked over that code, some of whom have probably complained
about it, and all of whom should know better than to let it fester...

~~~
gizzlon
" _I expect this from some shady Bitcoin market that a high school kid runs
off of a server in his bedroom. I do not expect this type of amateurism from a
10 billion dollar company with hundreds of engineers.._ "

Think you might be expecting too much from large companies =/

------
aparadja
Cracking the passwords from the hashes is not just fast, it's ridiculously
fast. I can't believe a site like LinkedIn stores their passwords this way in
2012.

    
    
      guesses: 11516  time: 0:00:21:36 0.00% (3)  c/s: 27126G  trying: aptewwod - aptewws1
    

That's plain old john the ripper running on the cheapest 13" 2010 mbp. John is
not even using the GPU, and non-trivial 8-character passwords are scrolling by
in my terminal, too fast to read.

------
madsr
What riddles me though, is how come 6.5 million? LinkedIn has what, 150M
users?

Did they not post the entire load (and are in fact sitting on _all_ the
hashes?) Is the dump an old backup or breach from when they had fewer
accounts? Is it just one DB partition / file that's been lost, an archive?

~~~
revelation
Given that these hashes are not salted, running a 'uniq' on the list of all
users' password hashes would probably already cut it by half, if not more.
Then you eliminate all the easy ones from wordlists, and post the remains on
the internet for people with excess computing power to bruteforce.

~~~
16s
They are already unique and sorted.

sort -u combo_not.txt | wc -l 6458020

wc -l combo_not.txt 6458020

~~~
biot
I assume the first line you meant to pipe it through uniq afer the sort?
Otherwise the only thing you've demonstrated is that sorting a file doesn't
change its line count. :)

~~~
JoshTriplett
"sort -u" means "sort and uniq".

~~~
biot
Wow, I can't believe I was never aware of this. Thank you!

------
jurre
There should be a huge banner on linked in urging users to change their
passwords in my opinion.

~~~
bgilroy26
Even more important to change password on other sites if you use the same
email/password combo there

------
whit537
Here are a couple links to the file:

<http://www.mediafire.com/?n307hutksjstow3> (RAR)

[https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO...](https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp%2BmuGtgOEptAS4%3D)
(ZIP)

------
dredmorbius
Um, pardon the obvious question, but does someone have a direct link to the
hash file?

~~~
rfugger
From a slashdot comment:

[https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO...](https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp+muGtgOEptAS4=)

~~~
dredmorbius
I can confirm that my long-lived randomly generated single-use 12-character
password hash is in the file, but not 00000-prefixed (apparently not broken).

A more recent 20 character single-use randomly generated password was not, but
the file doesn't comprise the full 6.5 million hashes noted in stories.

I've since changed both for rather longer randomly generated single-use
passwords.

------
tantalor
Maybe they read this SO thread?

[http://stackoverflow.com/questions/2019279/what-is-the-
recom...](http://stackoverflow.com/questions/2019279/what-is-the-recommended-
way-to-encrypt-user-passwords-in-a-database)

~~~
weichi
If we can't trust SO for security questions, where do we go to get them
answered?

------
Imagenuity
My old password was in the password file, and it was flagged as cracked.

If you're a Windows user and you want to check if your password is in the
file.

    
    
      (1) download the passwords file from http://www.mediafire.com/?n307hutksjstow3
      (2) the download is a RAR file, so you'll need to have WinRAR installed to extract it.
      (3) to get the sha1 version of your password, go to duckduckgo.com and type:
        sha1 yourpassword
      (4) copy the result, except for the first 6 or so characters
      (5) open a DOS command prompt (WindowsKey+R and type CMD)
      (6) type (quotes required where indicated): find "sha1hash" sha1.txt
        (note: to paste to the command prompt is right-click)
    

Example:

    
    
      The sha1 hash of the password 'password' is: 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
      Remove first six characters: e4c9b93f3f0682250b6cf8331b7ee68fd8
      enter at command prompt: find "e4c9b93f3f0682250b6cf8331b7ee68fd8" sha1.txt
        result:
        ---------- SHA1.TXT
        000001e4c9b93f3f0682250b6cf8331b7ee68fd8

------
finnw
The SHA1 of my LinkedIn password naturally starts with "00000". I wonder if
that would have thwarted the original cracking attempt.

I'm almost disappointed that mine was not in the list.

------
mcculley
I can confirm that my password was in there. I have changed it. My password
was "98mnja6z" which hashes to 6475590bc1407aa98c8b022230292cce3d8528b3. I
used this for no other sites, so I'm not concerned about it leaking.

It is inexcusable that LinkedIn hasn't alerted their users yet.

~~~
docubot
Mine is also in there. It was also a randomly generated password used only on
LinkedIn.

------
mistercow
I'm starting to think it might be wise, if you intend to reuse your password
on multiple sites, to salt it yourself. By using a form like "<site name><user
name><reused password", you protect yourself from rainbow tables without
making your username harder to remember.

And yes, yes, I know you shouldn't be reusing your password across different
sites, or using a dictionary word anyway. And teenagers also shouldn't be
drinking, doing drugs and having sex. It doesn't help anything to pretend that
people are going to behave optimally.

Of course, the preposterous restrictions that websites put on passwords, like
maximum password length, will make this idea harder to put into practice.

~~~
jwegan
I've been doing this myself and it has worked out pretty well so far. My
password is in the list of passwords released, but is uncracked and I can rest
assured knowing that I did not use the same password on any other website.

A couple things to keep in mind:

1) The salt you generate should be put at the front in case the website is
silently truncating the password to a certain length

2) The salt can be something more complicated than site name. I mentally
calculate a fixed length salt based on the site name

3) You may want to still keep two separate "base" passwords, one for high
value sites (banks, email) and one for low value sites (everything else).

------
bonaldi
Given they haven't confirmed they've found and closed the leak, is it wise for
everyone to be changing their passwords already?

~~~
Aissen
Given many people have confirmed that their uniquely generated password is in
the list, is it wise to wait any longer before changing your password ?

~~~
bonaldi
I guess you need to do both: change your password, but to something throwaway.
Then when the hole is closed, change it _again_.

------
tocomment
This makes me wonder. I've been relying on Django's built in user
authentication lately. Does anyone know if that's pretty safe? Is it doing the
right thing for hashing passwords?

~~~
Glowbox
Disclaimer: I am not a cryptographic expert.

<https://docs.djangoproject.com/en/dev/topics/auth/>

Django by default uses the PBKDF2 algorithm, which is better than
nothing/md5/no salt sha1.

I'd use bcrypt or scrypt by default, better be safe than sorry.

~~~
leif
Pbkdf2 is extremely good. Without deeper analysis (or a feature comparison)
I'd be hesitant to say that bcrypt or scrypt are better.

~~~
tptacek
I sincerely mean no offense but this statement came directly out of your butt.
Read the table on page 14 of Colin Percival's Usenix paper "Stronger Key
Derivation Via Sequential Memory-Hard Functions" (which you could have found
by Googling [scrypt paper]); PBKDF2 is ~5x faster (ie: costs ~5x less to
break) than bcrypt; PBKDF2 and scrypt aren't even in the same ballpark.

From exactly where did you derive the idea that PBKDF2 is "extremely good"?

The reality is that all three of PBKDF2, bcrypt, and scrypt are _just fine_.
But PBKDF2 and scrypt have drastically poorer library support than bcrypt;
_nobody_ should delay using a strong password hash so that they can optimize
which one they use.

~~~
leif
All three are extremely good for this use case, when the competition is SHA-1.
Beyond that, I don't know enough to compare the three. So yeah, it came out of
my butt.

If Colin has a paper on it then I trust his comparison. What I really meant to
say is what you said: all three are just fine.

Also, I thought I remembered my comment's parent saying something stronger,
either it was edited later, or I was drunk when I decided it was worth
commenting on.

~~~
tptacek
I just wanted to write the word "butt". Thanks for being cool about it. :)

~~~
leif
hahahaha, well, what you wrote was worthwhile and (as far as I can tell)
correct. Thanks.

------
moondowner
You can generate your own SHA1 for your password and check if it's existing in
the txt file.

<http://jssha.sourceforge.net/>

~~~
pjscott
Or, if you don't trust random web sites, we can turn this into the next
fizzbuzz:

    
    
        $ python -c 'import hashlib; print hashlib.sha1("hunter2").hexdigest()'
    

This will print the SHA1 hash of "hunter2".

------
statictype
I literally created my LinkedIn account only 2 days ago. And my password was
in the list and cracked. Thankfully I don't use it for anything else.

~~~
drewfrank
Is it unique enough that you can be sure it's _your_ password, and not someone
else's? I ask because the cracked passwords seem to be the simple/obvious ones
that are likely to be used by multiple people. If it is strong/unique though,
it would effectively confine the hack time to the last 2 days.

------
Gigel
Obviously the list was filtered to eliminate duplicates. It contains only what
the hackers wanted it to contain. So, why does nobody mentions that it is
HIGHLY LIKELY that the user names associated with the passwords (which are
actually mainly e-mail addresses for LinkedIn) are also in the possession of
the hackers. So, if I would be the hacker - strip usernames, strip duplicate
hashes, post list of unique hashes to let others do the CPU intensive
cracking, retrieve cracked passwords, match with usernames (e-mail address),
check same password on other accounts (first on the e-mail account, then
google the e-mail address on forums or try on the services that interests me
and say "forgot password, send it again to this e-mail address - thank you
telling me that this e-mail has indeed an account with you..."), monetize
somehow the data. As a user that implies - IMMEDIATELY change your password
for the e-mail address used to login at LinkedIn (if it was the same
password); verify if settings of this e-mail account have changed (like an
additional unknown address added to allow retrieval of the password, DUH), try
to remember where you use the same address either as login or to recover
credentials, try to remember where you used the same password, google you
e-mail address to help you remember; change passwords; consider abandoning the
e-mail address if it is not your primary one,... Also - did the amount of SPAM
that you receive on the e-mail address used to login at LinkedIn suddenly
increased, while SPAM remained constant on a similar mail account not
connected to LinkedIn ? Maybe someone just sold your e-mail address, so the
LinkedIn break may affect you even if the password is not in the list. Bottom
line is - LinkedIn approach appears to be: We have no proof that this
particular account was hacked since password hash is not in the list - let's
not overreact and let'sassume it is not hacked even if we don't have a clue
what was actually hacked. I'm not to judge if it is the best approach for the
business, but sure as hell I don't like this approach as a user.

------
miniatureape
I didn't see it in the post, but does anyone know if these were current
passwords (as of this post)? I use a unique password for linked-in, but some
number of months ago I used a password I shared with another site. Wondering
if I need to change that one too. Guess I might as well.

------
ragmondo
I wrote a short article about this kind of stuff - if it's really my data,
then let me use my lock on it : <http://ragmondocom.appspot.com/2012/03/My-
Stuff-My-Lock>

Then I get to choose what strength lock I put on it.

~~~
cheald
First rule of software design: users are lazy. Second rule of software design:
users are stupid.

"Use your own lock" is fine for us Übergeeks, but for the vast majority of the
populace, they just want the provider to put a system in place so they don't
have to worry about it.

------
tintin
I know a lot of companies just keep your account including your password in
there database while you removed your account.

Can I be sure my account was totally removed when I removed my LinkedIn
account? Because the "please change your password as soon as possible" won't
help me much.

~~~
finnw
As long as:

1\. They do not have a mechanism to resurrect your account and 2\. You do not
use the same password elsewhere

then it should not matter.

------
StavrosK
Can we please start using BrowserID or some other standard so we can secure
that _one_ provider and do away with all this? I'd like it if we could
authenticate with Google using 2-factor authentication and be less worried
about my password getting hacked.

~~~
pilif
By centralizing authentication, you make that central provider an even bigger
target and you risk losing access to other services as you lose your main
account (Google is known to sometimes terminate accounts with no way of
recurse).

Finally, when that central provider gets hacked, all your dependent services
are now also compromised.

And as we know from the CloudFlare story over the weekend, not even Google
with their 2 factor authentication is devoid of issues.

No. Centralizing your login to one third-party as as bad as the current
practice of reusing your password for every service you have an account with.
The only way that is reasonably safe is to use different random credentials
for every service and store these credentials somewhere under your (and only
your) control (i.e. a password manager or a piece of paper)

~~~
joeyh
Browserid is not a centralized authentication protocol. Although currently all
implementations I know of rely on browserid.org, this is not required by its
design.

There's also the fully decentralized openid, you know. I'd 100% rather be able
to use openid for sites like Linkedin and this one than rely on every site
implementing sane password management.

------
cjdavis
It seems we will never get rid of bad programming like this. I hit the 'forgot
my password' link on the T-Mobile website yesterday and the pop-up requested
my T-Mobile phone number. Ten seconds later I received an SMS with my actual
password in it.

------
ttul
Guys, this all doesn't parse for me. My password on LinkedIn was 13 characters
long, and included symbols (!@#$%^&&*()), numbers, and alphabet characters. A
13-character password like this would imply a search space of (26 + 26 + 10 +
20) ^ 13 = BIG. If a GPU can check 11 billion passwords per second, this
implies that someone ran 2.4 x 10^7 GPUs for a month.

We're either looking at someone with a seriously ridiculous password cracking
computer (i.e. ASIC-based -- not even FPGAs), a compromise for SHA-1 (very
unlikely), or a keylogger/proxy/trojan/etc... I vote for keylogger.

If your password is in this database, I don't think it's because your password
was brute-forced.

------
Aimes
My old password is not on the list. However, it seems like somebody tried to
log on to windows live with the e-mail address and password I was registered
on linkedin with. This is one of my oldest passwords from when I still only
had one or two passwords.

I noticed this as window live kept sending another of my e-mail accounts a
code needed to log in from an unrecognised computer.

Now it could all be a coincidence, but I wouldn't be surprised if there was a
connection, as the e-mail address and the password were identical to the ones
used on Linkedin. If that's the case there would be a more complete list with
my password/hash as well as the associated e-mail address.

------
sopooneo
How on earth were they not salting? There are so many open source auth systems
now that get all the basics right. Someone who works at a big company like
this and has any insight, please comment. How is this even possible in these
days?

~~~
pjscott
There's still an unbelievable amount of ignorance out there about how to
properly store hashed passwords. There are countless articles explaining that
you need to _hash_ the passwords, and telling you how to use md5("salt" +
password), and then the blog comments are full of helpful people saying that
you should use SHA256, or "no u also gots to add pepper", or exhorting the
author to use a large unique salt from /dev/random (not /dev/urandom, it's not
random enough) and then encrypt the salts in the database with 2048-bit RSA. I
sometimes google around for these articles when I want some morbid fascination
-- it's the intellectual equivalent of those YouTube videos where one car
crashes into another, and then a third car crashes into the wreckage, and then
another car tries to ramp over it and fails, and then everything explodes, and
then the people staggering out of the destroyed cars start shouting bad advice
about hash functions.

------
925601568310
Putting people's personal details on the open web, giving anyone access,
including malicious hackers... This design used by LinkedIn, as well as
Facebook, was a bad idea from the beginning. Don't think they are not aware of
the risks. How much spam and other annoyances do people get as a result? These
companies are killing privacy just to make a quick buck. Maybe they'll be
sued.

Direct link to SHA1 file on mediafire (117MB) to avoid javascript, captchas,
popups, etc.

[http://205.196.120.123/c2o80hrlhteg/n307hutksjstow3/SHA1.txt...](http://205.196.120.123/c2o80hrlhteg/n307hutksjstow3/SHA1.txt_1.rar)

------
ctdh
No sign of my password in there <http://www.mediafire.com/?n307hutksjstow3>,
or my wife's. I checked both the full and the '00000' truncated hash for each.
Neither of us had changed it for the last couple of years.

So I guess it is only a subset of all the linkedin passwords?

I have now changed my passwords anyway.

By the way, the press say both the username and password were hacked, has
anyone seen the list of usernames? They also say 6.4m passwords were hacked
but this file only has 6.14m.

------
jpgouigoux
A salt may not have been enough to protect the passwords : if it is not
complex enough, the presence of common passwords like "password" or "123456"
make a brute-force attack on the salt itself possible in some case. I have
performed a benchmark on that point in particular, and was able to retrieve a
salt in five days, without strong optimization. A bit long to give all the
numbers and code here, so the ref is <http://gouigoux.com/blog/?p=46>

------
jrabone
There's an English-language article (rather than a translation) at
<http://www.bbc.co.uk/news/technology-18338956>

------
johnvey
I cross-referenced the leaked hashes against hashes of the 10,000 most common
passwords and found that 93% of the passwords at least 6 characters long
appear in the leak.

[http://www.johnvey.com/blog/2012/06/93-of-top-passwords-
appe...](http://www.johnvey.com/blog/2012/06/93-of-top-passwords-appear-in-
linkedin-leak)

It's always surprising that people are so lackadaisical about their passwords.
I've had people tell me their passwords in casual conversation multiple times,
just for the sake of discussion.

------
Aissen
If you want to check if your password is in there:

    
    
        read -s a
        zgrep $(echo -n "$a" | sha1sum | cut -d' ' -f1 | \
          sed -e 's/^...../00000/') combo_not.zip
        unset a

~~~
akavel
According to jgrahamc's investigation, this will probably check if your
password is there and _is cracked already_. To check if the hash is there,
although uncracked yet, you should probably remove the sed call from pipeline.

~~~
Aissen
Oh. You're right, I missed that. New command line:

    
    
        read -s a; zgrep --color -E $(hash=$(echo -n "$a" | sha1sum | cut -d' ' -f1); echo -n "$hash|$(echo $hash | sed -e 's/^...../00000/')" ) combo_not.zip ; unset a

------
toyg
The good thing is: every time this happens to a high-profile site, storing
sensitive data, more people get more acquainted with the concepts of "you
really should not use a simple password" and "you really should not use the
same password across all sites". I know it works for me: this was the last
straw that forced me to abandon a good ol' password I've been using since
1998. From now on I'll just rely on password managers (currently DataVault,
but I know people who swear by LastPass).

------
jneal
My password isn't in the file, and yes I checked for a 0'd version as well. My
password is 9 characters of lower case, upper case, numbers, and a symbol. I'm
wondering if this is incomplete, or fake. Either way...if it is a
vulnerability I suppose LinkedIn hasn't fixed it yet, or at least I haven't
heard mention of this - thus even changing your password won't help much if
they can just re-download the database. Thus making a long, complex password
is the best course of action.

------
mynegation
My password hash was in the file and it was cracked. It was a combination of 8
upper and lower case letters, digits and special characters. This is the case
where size does matter and apparently passwords like my old one can be broken
on GPU in minutes or hours nowadays.

Quick sample from persons I polled: 2 password hashes were not in the file, 1
was there and cracked, 1 was there and not cracked yet.

As bad as it is, this can be a great case to raise the awareness of good
password management.

------
alexvay
So I changed my password through my PC yesterday, went to my Android client
and, to my surprise, it is logged on the mobile!

It's been more than 12 hours, and the access token for the mobile client is
still connected to my account, despite changing my password.

I would expect all tokens to be revoked on-password-change. Really
disappointing.

I'll have to set up an SSL proxy later to dump the traffic from Android, see
what is happening. Anyone compiled SSLDump for Android?

------
henkert
00000fac2ec84586f9f5221a05c0e9acc3d2e670
0000022c7caab3ac515777b611af73afc3d2ee50
deb46f052152cfed79e3b96f51e52b82c3d2ee8e
00000dc7cc04ea056cc8162a4cbd65aec3d2f0eb
00000a2c4f4b579fc778e4910518a48ec3d2f111
b3344eaec4585720ca23b338e58449e4c3d2f628
674db9e37ace89b77401fa2bfe456144c3d2f708
37b5b1edf4f84a85d79d04d75fd8f8a1c3d2fbde
00000e56fae33ab04c81e727bf24bedbc3d2fc5a
0000058918701830b2cca174758f7af4c3d30432

------
Hethrir
Torrent of database: <http://www.seedpeer.me/details/4368981/linkedin-
hashes.html>

Magnet link: magnet:?xt=urn:btih:VUPJHINO4KAWLWVLEKKFWKJVF3DVDDDR

Torrent download:
[http://www.seedpeer.me/download/linkedin_hashes/ad1e93a1aee2...](http://www.seedpeer.me/download/linkedin_hashes/ad1e93a1aee28165daab22945b29352ec7518c71)

------
hangas
My belief is that the hackers might get the username password combos, but they
grouped the hashes to only have unique (sort -u ?) passwords hashes and
therefore ease the process of dictionary cracking them as they do not have
salts. The 00000 prefix might be an indication of this. I bet there is an
automate script taking care of a dict attack and the file was released during
execution.

------
slig
Looks like they were too busy tuning their Spam All Your Friends (TM)
"invitation" feature to bother with proper ways to store passwords.

------
joninashby
I deleted my account over 6 months ago but my password hash (strong unique
password) is in the file. Either (a) the file retains passwords of deleted
accounts, (b) the file was stolen over 6 months ago and LinkedIn didn't know
about it, or (c) the file was stolen over 6 months ago and LinkedIn DID know
about it and were hoping it wouldn't show up online.

------
Ecio78
They have added a blog post with an update
[http://blog.linkedin.com/2012/06/06/linkedin-member-
password...](http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-
compromised/)

Unfortunately they dont tell when they started salting the password and if
they've found (and fixed) the hole that permitted the database leak!

------
instakill
Why is there no notification on their website?

------
chrisacky
I've come to the conclusion that this list is genuine. While some people have
said that they could't find their passwords in the list, I think this only
points to the most probable reason in that this is a part list.

Password: "needajob"

    
    
        Hash:    e41b635974babd5d6e7d6dc68e8b3d2fc39938b2
        Cracked: 0000035974babd5d6e7d6dc68e8b3d2fc39938b2

------
grannyg00se
How does this benefit someone who is trying to access an account? There are no
account names tied to these hashes. So even if you managed to find the clear
text of each of these you would still be in a position where you have a list
of over 6,000,000 passwords to work through in order to brute force your way
in.

------
steve8918
Has any legitimate sources confirmed that the usernames were also stolen along
with these hashes? Or were only the hashes stolen?

Could this just be an elaborate hoax where someone generated 6.5M SHA1 hashes
and said that they hacked linkedin? Maybe someone shorted LNKD and then leaked
this, hoping for a monetary gain?

~~~
slig
Someone in this thread stated that his non-common password is hashed on the
list so, very unlikely.

------
disclosure
<http://pastebin.com/JmtNxcnB> \- 20k++ sample cracked passwords from LinkedIn
hash dump released on June 6, 2012. They do appear legit and strong too. It's
unfortunate that LinkedIn hashed them using unsalted SHA-1.

------
sturmeh
If your hashed password is not in this list (trunucated or not) do not assume
for a second that whoever leaked this list had to leak all their lists.

Also note that according to other users, some of these hashes are at least 3
weeks old, they've had this list for some time.

------
jtchang
Is it scary to anyone else that LinkedIn can't confirm yet if their security
was compromised?

------
heliodor
As much as I hate lawsuits, I'd love to see one or two major Internet
companies sued in a class action lawsuit for negligence to serve as an example
and a warning to the rest. This kind of behavior from a top tier internet
presence is inexcusable!

------
mahyarm
A password I used many months ago (maybe almost a year now?) was in the list,
but the password I use currently for many months was not on the list
interestingly enough. This list is possibly pretty old, which means it
happened quite a while ago.

------
ErikCorry
Am I the only one who is too paranoid to decompress a file that I know was
created by a black hat...

[http://www.symantec.com/avcenter/security/Content/2005.12.21...](http://www.symantec.com/avcenter/security/Content/2005.12.21b.html)

------
eddieplan9
Quickly check if your password has been cracked:

<http://crackedin.s3-website-us-east-1.amazonaws.com/>

It will not send your password over the wire. It won't even send the SHA1 hash
over the wire.

------
bstar77
I have an ignorant question... when a SHA1 encrypted password is cracked, can
the hackers actually identify what the unencrypted password is?

I'm guessing no since SHA1 uses a hashing algorithm and only a brute force
approach would potentially work...

~~~
akrasia
I'm not an expert in the field but from what I know, SHA1 is a one way
function. When an encrypted password is cracked, YES, the hackers know that
specific password. They brute forced it by guessing the password, running it
through SHA1, and comparing the output to the hash. If they are the same, then
they guessed the right password.

They do not know any other passwords and if "salt" was used, they would have
to brute force each password. I think salt wasn't used in this case so once
they crack someone's password, they know every other user who used the same
password. So if you and I used the same password, and they brute forced yours
already, they will know that I have the same password.

------
chli
The forum they are talking about apparently (found using google)

[http://forum.insidepro.com/viewtopic.php?p=96122&sid=133...](http://forum.insidepro.com/viewtopic.php?p=96122&sid=13341ef728d68f51bb893e4acde1219d)

~~~
smoyer
The Hacker News effect seems to have taken the forums off-line. If you need a
quick DDOS and don't have a botnet handy, just post the link here!

~~~
chli
[https://www.dropbox.com/s/dsiuavbbzt8cy7g/forum.insidepro.co...](https://www.dropbox.com/s/dsiuavbbzt8cy7g/forum.insidepro.com-
viewtopic.php-p%3D96122.zip)

A saved copy of my local cache...

------
16s
John the Ripper released a patch for this modified sha1 hash type today. So no
need for any manual hacks. You may download the patch here:

<http://openwall.info/wiki/john/patches>

------
Zopieux
It seems there _are_ some duplicates, considering cracked hashes beginning
with 000000. For instance, I found:

    
    
      passforlinkedin
      00000610754c30b38d0c70b72b7e8210268cd9b7
      b3534610754c30b38d0c70b72b7e8210268cd9b7

------
sildani
My LinkedIn's password hash (at the time, I changed it once news broke) was
not listed. And it was a relatively weak password (8 characters, just lower
case characters and numbers). I doubt this is LinkedIn's password dump.

------
hughw
Even after securing our own passwords, we are all still vulnerable to attacks
where the attackers simulate members of our networks to discover private
information like our connections, job history, etc.

------
narrator
So LinkedIn... Why are you not using bcrypt to has your passwords?

<http://codahale.com/how-to-safely-store-a-password/>

------
flux_w42
And here is the (partially) decrypted version with 163267 passwords:
<http://www.mediafire.com/?bq8bd5iojp50zci>

------
mc32
I checked a few 6 char passwords (alphanum) some were not present. So they
seem not to be bruteforcing them serially. Maybe just checking against other
known tables.

------
bmacs
I just made an online too to check if your password is in the list:
<http://billsnitzer.com/linkedin/>

------
localhost007
Here is the original file...
<http://filevelocity.com/ixhk76jz07m5/SHA1.txt_1.rar>

------
dhughes
The worst is I can't remember what password I used but don't want to change it
because I want to know if it's one I used somewhere else not just reset it.

------
zer01
Anyone looking for the file to run these tests yourself ->
<http://clck.ru/d/jE6Mg-5X1ARpN>

------
alyandon
Just adding my two cents worth. This file looks legit as I have a long,
complex password on linkedin and the sha1 hash for it is present in the dump.

------
jameswyse
Does anyone know what encryption scheme LinkedIn uses?

~~~
lhnz
You don't mean encryption. Passwords should be _hashed_.

------
sakai
A question from the cryptographically uninitiated -- how (and how easily) can
these hashes be linked to a user's account name/email?

------
antithesis
It's nice to see a page translated through Google on the front page. It's an
indication that technology is breaking some barriers.

------
dewatson
Did not find my password in the list in truncated or original form. Member
since April 2010, did not change my password even once.

------
kamaal
Can somebody recommend good reading material/book on how to handle
passwords/encryption for practical everyday applications.

~~~
fhars
<http://codahale.com/how-to-safely-store-a-password/>

------
disclosure
Searchable DB is available at <http://dazzlepod.com/linkedin/>

------
KenCochrane
Use <http://leakedin.org> to find out if your password was hacked.

~~~
lordlicorice
`pass` is uncracked?

------
adarshu
Shocking that they didn't even use the basic technique of using salts before
hashing!

------
zenocon
If this is legit, shouldn't LinkedIn be notifying users of the security
breach?

------
fluidcruft
Can anyone tell me where I can change my password on LinkedIn? I must be
dense.

~~~
re_todd
Assuming LinkedIn used SHA1 unsalted passwords and will continue to do so, and
many of us do not want to delete our LinkedIn accounts, what should be the
minimum number of characters we should use in our new password? 15? 20? 100?
(I know, 100 is probably higher than they allow)

~~~
re_todd
I just reset to a 22 character password, so I know that number of characters
is allowable at least.

------
jqueryin
On my own accord and not my employers, I'd like to invite developers to check
out mojoLive as your career management tool. Our goals and vision are light
years ahead of what LinkedIn has slowly become. Also, I dislike recruiters and
spam.

<http://mojolive.com>

------
whileonebegin
A company as large and popular as LinkedIn uses no salt? Surprise.

------
geekin
Terribly sorry to ask this - but where did you guys get the file ?

------
singlow
Of course, now their password change script is broken/overloaded.

------
jonah
Hmm, my (short alpha) password isn't in the list.

------
niels_olson
could some other folks who have this database repost it? The existing sources
(yandex, the original .ru site) seem to be clobbered.

------
madmaze
I confirmed mine is in the dump as well

~~~
mutagen
Mine as well, unbroken (not prefixed with the 00000) in the original file.

------
smattiso
Sorry where is the list?

------
sparknlaunch
Worth noting that some passwords belong to the dating website eHarmony. The
dating site had a password beach last year.

[http://arstechnica.com/security/2012/06/8-million-leaked-
pas...](http://arstechnica.com/security/2012/06/8-million-leaked-passwords-
connected-to-linkedin/)

[http://www.theregister.co.uk/2011/02/11/eharmony_data_breach...](http://www.theregister.co.uk/2011/02/11/eharmony_data_breach/)

------
sparknlaunch
When Twitter recently had accounts and passwords leaked, many were attached to
spam accounts or duplicate records. Most had obvious passwords (like 1234).

Are these legitimate active accounts? Can you do anything with the hashed
passwords alone?

~~~
ecaron
In fairness to Twitter, it was never actually known if the accounts/passwords
came from Twitter.com (proper) or (more likely) leaked from some 3rd-party
Twitter-integrating app that had pre-OAuth integration.

------
yashchandra
I just changed my password. To test, I entered only letters and numbers all in
lowercase. Linkedin accepts it even though the site says "should have upper
case etc.".

------
yashchandra
is this confirmed to be real or a hoax ?

