[Password Leak] LinkedIn database hacked

[justusranvier]

You enter a master password and other details (like the domain name and user id) then it uses a hash function to generate a password that doesn't need to be stored anywhere.  It does all of that on the client, in the browser and you can access it from any computer with an internet connection and a browser (only on a computer you trust of course).

I used a tool like that before but found it more convenient to use a tool that came with plugins for every browser I use including Android. I want my password manager to Just Work no matter which browser I am using so I've found it to be easier to disable the built-in managers and just use the LastPass plugin for everything.

[1713565558]

1713565558

[1713565558]

1713565558

[1713565558]

1713565558

[1713565558]

1713565558

[1713565558]

1713565558

[1713565558]

1713565558

[Herodes]

Cool thing is that linkedln easily could rename their service to leakedln. Whoever used linkedln anyway ?

[Nefario]

GLBSE uses BCrypt + salt

[Stephen Gornick]

So far 3,427,202 passwords have cracked from LinkedIn List Almost 50%Its been about 24 hours - The longest? a 29 letter sentence from Bible

 - https://twitter.com/CrackMeIfYouCan/status/210474428407103490

So, the "username" (LinkedIn doesn't use usernames, so that's e-mail address) hasn't been leaked.   So 3.4 million email passwords, maybe a quarter (more, I'ld bet) used the same password as their email, and PayPal.  So presuming a party with malicious intent has control of close to a million valid email accounts and passwords .

So from there, I'm guessing access to the email accounts gives "forgot password" capability to bank accounts.   Most of those will be slowed by a "mother's maiden name" mulltifactor security question, ... but there's probably thousands (or tens of thousands) of bank accounts that will get compromised as a result of this.   PayPal, without having a security question hurdle even more.   Dwolla uses a PIN #, ... hopefully not a whole lot of people used 4321 or 9999 PIN codes for that.

Aye ,... this could be painful.

[justusranvier]

So far 3,427,202 passwords have cracked from LinkedIn List Almost 50%Its been about 24 hours - The longest? a 29 letter sentence from Bible

 - https://twitter.com/CrackMeIfYouCan/status/210474428407103490

So, the "username" (LinkedIn doesn't use usernames, so that's e-mail address) hasn't been leaked.   So 3.4 million email passwords, maybe a quarter (more, I'ld bet) used the same password as their email, and PayPal.  So presuming a party with malicious intent has control of close to a million valid email accounts and passwords .

So from there, I'm guessing access to the email accounts gives "forgot password" capability to bank accounts.   Most of those will be slowed by a "mother's maiden name" mulltifactor security question, ... but there's probably thousands (or tens of thousands) of bank accounts that will get compromised as a result of this.   PayPal, without having a security question hurdle even more.   Dwolla uses a PIN #, ... hopefully not a whole lot of people used 4321 or 9999 PIN codes for that.

Aye ,... this could be painful.

I'm disappointed. According to LeakedIn my password is not part of the leak. It would have been interesting to see if anyone managed to crack my old password: h0NOl&tHgNr7ePTiayf7

[BrightAnarchist]

This pisses me off. Really, I mean really?? I thought LinkedIn was supposed to be professional. Every newb knows that you always want some salt with your hash ( and maybe some eggs too ). Otherwise it's bland and tasteless.

[BCB]

Check This out.
http://shiflett.org/blog/2012/jun/leakedin
Link to Chris Shiflet's blog and another link to "Leakedin"
Their leaked password checker. 

Happy Hunting....

[zhoutong]

Honestly I feel it is going to take companies being force to publicly disclose their exact mechanism for storing passwords and face civil penalties for inaccurate disclosures.   I mean it is 2012 not 1971.  There is absolutely no possible excuse for not using bcypt (or similar) much less not even salting the passwords.     Security through obscurity is no security at all.

Maybe we can get such information from Bitcoin websites via public pressure.

So major Bitcoin businesses and exchanges how are you storing your passwords?
MtGox?
CampBX?
Bitcointalk?
Bitmit?
Deepbit?
Bitcoinica?

Any volunteers?

Bitcoinica: Salted BCrypt with 20 iterations. Enforce minimum 8 characters. It can take months to crack a simple password. (And I use this for all my future app projects. Also recommend everyone to do the same.)

[rjk]

It can take months to crack a simple password.

Only if it isn't in a dictionary somewhere already. But yes, even dictionary cracks are slowed down, somewhat.

[weex]

We salt for the rainbow and iterate for the dictionary. You gotta love technology lingo.

[TangibleCryptography]

Bitcoinica: Salted BCrypt with 20 iterations. Enforce minimum 8 characters. It can take months to crack a simple password. (And I use this for all my future app projects. Also recommend everyone to do the same.)

I assume you mean Salted Bcrypt w/ workload=20, that is 2^20 = 1 million iterations.  Slightly harder.   A single round of bcrypt takes roughly 5x the clock cycles as long as SHA-256 (OpenCL optimized).  Thus bcrypt(20) is on the magnitude of 5 million times harder to crack than salted SHA-256 hash.

Another way to look at it.  If a hacker could brute force a given password hashed SHA-256 in 1 second it would take them 57 days on bcrypt(20).

There is absolutely no reason to use anything weaker than bcrypt (or similar chained iterative functions like PBKDF2 or scrypt).

pass - stupid
MD5(pass) - cryptographically weak
SHA-256(pass) - vulnerable to rainbow tables
SHA-256(pass.salt) - vulnerable to brute force
bcyrpt(pass,salt,2^10) - vulnerable to weak/common password list
bcyrpt(strongpass*,salt,2^10) - computationally infeasible to attack

strongpass being enforced by the site as
8+ char
not in dictionary
not in known password list

[cytokine]

Bitcoinica: Salted BCrypt with 20 iterations. Enforce minimum 8 characters. It can take months to crack a simple password. (And I use this for all my future app projects. Also recommend everyone to do the same.)

I assume you mean Salted Bcrypt w/ workload=20, that is 2^20 = 1 million iterations.  Slightly harder.   A single round of bcrypt takes roughly 5x the clock cycles as long as SHA-256 (OpenCL optimized).  Thus bcrypt(20) is on the magnitude of 5 million times harder to crack than salted SHA-256 hash.

Another way to look at it.  If a hacker could brute force a given password hashed SHA-256 in 1 second it would take them 57 days on bcrypt(20).

There is absolutely no reason to use anything weaker than bcrypt (or similar chained iterative functions like PBKDF2 or scrypt).

pass - stupid
MD5(pass) - cryptographically weak
SHA-256(pass) - vulnerable to rainbow tables
SHA-256(pass.salt) - vulnerable to brute force
bcyrpt(pass,salt,2^10) - vulnerable to weak/common password list
bcyrpt(strongpass*,salt,2^10) - computationally infeasible to attack

strongpass being enforced by the site as
8+ char
not in dictionary
not in known password list

And the best part about bcrypt is that you can dynamically adapt it over time to keep up with Moore's law. Just update the hash whenever after a user successfully logs in with the updated difficulty level.

With the SHA family, you're stuck.

[niko]

Would someone please explain this for the uninitiated: is there only one unique string (password) that corresponds to a given hash?  I believe the technical term is collision resistance, right?  Once you reverse the hash, can you know for sure that you got it right? If password is a dictionary word, it may be obvious, but how about if everyone were using random strings for their passwords? Would the hacker ever be able to know for sure if the reversed hash is the right one?

[justusranvier]

is there only one unique string (password) that corresponds to a given hash?

Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.

[niko]

is there only one unique string (password) that corresponds to a given hash?

Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.

Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash? 

[zhoutong]

is there only one unique string (password) that corresponds to a given hash?

Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.

Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash? 

For MD5: http://stackoverflow.com/a/2000014

[weex]

If you restrict the inputs to being within some normal distribution of user password length, then there are no longer an infinite number of inputs. So there are no longer an infinite number of inputs that can result in the same output.

That doesn't make the statement false though because of the hedging word theoretically.

One other thing I would note here is that the act of telling the public how many rounds there are in your password hashing settings may save the attacker quite a bit of work.

[Serenata]

The safest thing you can do as a consumer is user a random password at each site.

Doing that is much easier with a dedicated password manager, like LastPass.

Apologies to all for the offtopic but if you think about it, it's not.
We're talking about a major password leak at LinkedIn, but we're comfortable to have ALL of our passwords stored on an online service (!). Reading more about LastPass and watching the video on how to use it, I understand that LastPass saves the passwords online, so it can "restore" them to another browser on the same or another computer. Moreover, there are features to store auto-fill information (address, email, etc), so you don't have to fill it every time on every site.
Can you imagine the impact if this site has a similar leak of user data?

Local storage (encrypted ofc) or even what Steve suggested is the way to go IMO.

[defxor]

We're talking about a major password leak at LinkedIn, but we're comfortable to have ALL of our passwords stored on an online service (!). Reading more about LastPass and watching the video on how to use it, I understand that LastPass saves the passwords online, so it can "restore" them to another browser on the same or another computer. Moreover, there are features to store auto-fill information (address, email, etc), so you don't have to fill it every time on every site.
Can you imagine the impact if this site has a similar leak of user data?

LastPass has your encrypted passwords. They don't, however, have the decryption key.

[niko]

is there only one unique string (password) that corresponds to a given hash?

Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.

Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash? 

For MD5: http://stackoverflow.com/a/2000014

Alright, does this mean that if my password is a reasonably random string, and the unsalted hash is made public, it may be possible to "reverse" it, but it won't be possible to tell for sure that that was the actual password - there could be another string with the same hash out there.

Also, does this mean that you could still type in a "wrong" password (that hashes into the proper hash), and you would be able to log in just fine, since server is ultimately comparing hashes?

Sorry for silly questions, I'm not versed in this topic but I want to understand the implications of these kinds of leaks.