[Password Leak] LinkedIn database hacked

[i_rape_bitcoins]

This morning, a dump of unique passwords from LinkedIn databases had been posted. From the dump, it is revealed that password hashes did not include a salt. This allows the attacker to generate a rainbow table that is valid with all the hashes. So expect your password compromised. (feel the same as if your password were leaked plain-text)

If you have a LinkedIn account and use the same password for other services (such as mtgox), please change your password. If you are unsure, visit LeakedIn to check.

More news here: https://news.ycombinator.com/item?id=4073309

[1715594469]

1715594469

[kjlimo]

And remember to always salt your passwords 

Who salts a password?  Is that something I have to do when creating a password, or is that directed at the password manager to make sure to salt the passwords?

[mcorlett]

Is that something I have to do when creating a password, or is that directed at the password manager to make sure to salt the passwords?

The latter.

[ErebusBat]

Who salts a password?  Is that something I have to do when creating a password, or is that directed at the password manager to make sure to salt the passwords?

kjlimo,

It is, unfortunately, up to the website operator to do.  The safest thing you can do as a consumer is user a random password at each site.

[TangibleCryptography]

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?

[nimda]

Goddammit, I can't find a mirror of the leak.
Oh, found it. This is fun.

[weex]

CoinDL and ExchB both use salt and multiple rounds of hashing.

[realnowhereman]

If you have a LinkedIn account and use the same password for other services (such as mtgox), please change your password. If you are unsure, visit LeakedIn to check.

Seriously people: don't go to LEAKEDin and type your password.  Whether it's honest or not, you gain nothing from potentially handing your password over to some random site on the Internet.

[i_rape_bitcoins]

If you have a LinkedIn account and use the same password for other services (such as mtgox), please change your password. If you are unsure, visit LeakedIn to check.

Seriously people: don't go to LEAKEDin and type your password.  Whether it's honest or not, you gain nothing from potentially handing your password over to some random site on the Internet.

"Just provide your password (which we hash with JavaScript; view source to verify) or a SHA-1 hash of your password below, and we'll check."

browser hashes password -----sends to server-----> server replies if hash matches.

[theymos]

Bitcointalk?

SMF uses SHA-1 hashes salted with the username. Not the greatest, though better than LinkedIn. (I'm trying to improve our password security.)

[realnowhereman]

"Just provide your password (which we hash with JavaScript; view source to verify) or a SHA-1 hash of your password below, and we'll check."

browser hashes password -----sends to server-----> server replies if hash matches.

Oh that's okay then... as long as it says "we're honest" on the website, it must be fine.

[mcorlett]

"Just provide your password (which we hash with JavaScript; view source to verify) or a SHA-1 hash of your password below, and we'll check."

browser hashes password -----sends to server-----> server replies if hash matches.

Oh that's okay then... as long as it says "we're honest" on the website, it must be fine.

The source is available for anyone to read.

[epetroel]

I expect that they didn't get all user's passwords.  

I downloaded the leaked text file and verified that the hash of my password was NOT in there.  Checked the hash of another friend from work here, and his wasn't either.  So either they didn't get all the passwords, they got all the passwords but didn't release all of them, or the list is a fake.  Probably one of the first two (i doubt it's a fake)

EDIT: Also, usernames were not included in the file.  So either they don't have the usernames to go with the passwords or more likely they have them but just didn't release them.  Probably just waiting to sell the username+password hash list to the highest bidder.

[Serge]

they got 6.5mil out of 150million users

[epetroel]

they got 6.5mil out of 150million users

Well, there were 6.5 million distinct passwords.  Considering many users pick the same bad passwords, that very likely represents a lot more than 6.5 million users.

[Serenata]

Who salts a password?  Is that something I have to do when creating a password, or is that directed at the password manager to make sure to salt the passwords?

kjlimo,
It is, unfortunately, up to the website operator to do.  The safest thing you can do as a consumer is user a random password at each site.

+1
Cool tool for the job > Keepass

[justusranvier]

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.

[Xenland]

http://CheaperInBitcoins.com salts its passwords with 254 random characters uniquly per account, along with appending another salt that is the customers ID# multiplied by an undisclosed number on top of requiring users/merchants/customers a password of 10 characters or more. so to visualise the hashing it would look something like this in pseudo code

Code:

hash("sha512", <random 254 characters> (<user_id> * <undisclosed number>) <customer/username password>)

[Steve]

"Just provide your password (which we hash with JavaScript; view source to verify) or a SHA-1 hash of your password below, and we'll check."

browser hashes password -----sends to server-----> server replies if hash matches.

Oh that's okay then... as long as it says "we're honest" on the website, it must be fine.

The source is available for anyone to read.

Just change your password on linkedin, then you don't need to worry about if the source is read able or anything. Problem Solved

Uhhh…as well as every other site where you may have happened to use the same username and password.  People really do need a way of testing whether specific passwords are in that list…because many may have forgotten what password they used (with browser autofill, etc) and if they reset it, well, that doesn't tell them which password has been compromised.  Otherwise, they may need to change every password on every site, which can be tedious.

Just more justification to use unique, generated passwords on every site.

[Steve]

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.

I prefer to use something that generates a password from a master instead of storing any passwords anywhere.  Here's one such solution:
http://passwordmaker.org/passwordmaker.html

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

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

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

[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

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.

It's almost impossible for passwords with readonable length. But yes, the server will accept anything if the hash matches.

You may want to read this: http://en.wikipedia.org/wiki/Birthday_problem

[Raoul Duke]

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

Will you put your ass on the line to defend that statement as an absolute truth?

[TangibleCryptography]

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.

Yes.  The server never knows the password it only knows the hash. It hashes the password provided and compares it to the hash it has stored.  If they match it logs you in.  

So hypothetically if

"This is my password"  and "86f7e437faa5a7fce15d1ddcb9eaeaea377667b8"
both hash to "eee411109a229046154bc9d75265a9ccb23a3a9c" then the server would let you login with either.

This is why hashes need to be reasonably long.  MD5 (should be considered ancient and horribly broken) is only 128 bit,  SHA-1 is 160 bit, SHA-256 and SHA-512 are 256 and 512 bit.  The larger the keyspace the lower the probability that any two values will produce the same hash.

This same principal applies to Bitcoin.  Since addresses are hashes of the public key it is theoretically possible for two (or more) different public keys to hash to the same address.  Any of the associated private keys could spend the funds.  RIPEMD-160 and SHA-256 are considered cryptographically strong and have very large keyspaces which makes any collision academic at best.   If the algorithms were ever degraded that risk would become more real.

[Gabi]

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.

Note that for SHA 256, 224, 512, 384 no collision has ever be found. None.

[genjix]

https://intersango.com/security.php

Intersango uses SHA512 + salt + site wide secret

[TangibleCryptography]

https://intersango.com/security.php

Intersango uses SHA512 + salt + site wide secret

Thanks for having that publicly disclosed on your site.  An example for all sites to follow.

[BrannigansLaw]

And remember to always salt your passwords 

I put salt on everything but common I know where to draw the line and its not going to be on a Heart rate monitor!

[BCB]

But are ALL your (email) passwords secure.

Hackers look for and will eventually find a chink in the armor (no offense!)

http://krebsonsecurity.com/2012/06/attackers-target-weak-spots-in-2-factor-authentication/

[zebedee]

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?

Lol.  Simple answer to simple question?  There are an *infinite* number of random strings matching your hash.

After all, there are an infinite number of strings, and only len^possibilitiespercharacter unique hashes right?  infinite / finite = infinite

Look up the "pigeon-hole principle".  Simple logic, I'm struggling to even justify calling it mathematics.

[justusranvier]

Will you put your ass on the line to defend that statement as an absolute truth?

I'm confident enough in the company's incentive not to deliberately screw over their users to use the service. I need to trust them not to steal my passphrase, but I don't think that adds very much risk because I also need to trust all the websites I have accounts on to not do nefarious things with my data.

The government could force LastPass to install a backdoor in their plugin that recovers my passphrase (like Hushmail) but so what? They could just as easily force Google to turn over my Gmail account or my bank to give them all my money and they don't need my passwords to do it.

[proudhon]

I don't understand how so many long and seemingly secure LinkedIn passwords have been brute-forced?  Will somebody help me understand how they're decrypting 20+ character passwords?  Last I read over 60% of the leaked hashes have been decrypted.  I can understand that being the case if most of them were really short and simple passwords, but it looks like a lot of them followed password security standards pretty well.  Help me understand.

[defxor]

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

Will you put your ass on the line to defend that statement as an absolute truth?

I already do, and have been doing so for quite some time. I personally verified LastPass' crypto architecture including reading through the javascript they serve my browser before trusting them. What I would want to see, but it needs to be dragged through W3C first, is the ability for web clients to verify signatures of code blocks served to them and warn the user if the code block changes.

Yes, my Bitcoin wallet password is stored in LastPass as well.

[mcorlett]

I don't understand how so many long and seemingly secure LinkedIn passwords have been brute-forced?  Will somebody help me understand how they're decrypting 20+ character passwords?  Last I read over 60% of the leaked hashes have been decrypted.  I can understand that being the case if most of them were really short and simple passwords, but it looks like a lot of them followed password security standards pretty well.  Help me understand.

Rainbow tables.

[Xenland]

I don't understand how so many long and seemingly secure LinkedIn passwords have been brute-forced?  Will somebody help me understand how their decrypting 20+ character passwords?  Last I read over 60% of the leaked hashes have been decrypted.  I can understand that being the case if most of them were really short and simple passwords, but it looks like a lot of them followed password security standards pretty well.  Help me understand.

This assumes that LinkedIn didn't really salt their passwords or take any kind of salting precautions but,

TO put it simply when you encrypt a password like "duck" you get a constant output like "2d2370db2447ff8cf4f3accd68c85aa119a9c893effd200a9b69176e9fc5eb98"

Now the act of salting is appending some random but knowable data. so if my salt was "123" (with out the quotes) then my password would like like this, "123duck" and the server would save the encrypted password output as "50a7b5d4016f61fae2a9d86368db862971c0ef4c83e01f3a88d12a78febff81a"

With out a (very long 512+ character) salt its really easy to brute force but just for the sake of a simple example even with a small salt like 123 in front of a password makes the encrypted output completely different.

So back to my point, even with a 255 character password (with out a salt) Its easy to bruteforce with something called a rainbow table (which is a huge database of precomputed encrypted password ouputs). hope that makes more sense and i just wanted rambling

(Ps. With out a long salt the rainbow table most likely will contain the output that was appended to the password as if their was no salt. so even if linked in did use a salt it wasn't long enough and the rainbow table contained the precomputed out put).

[TangibleCryptography]

I don't understand how so many long and seemingly secure LinkedIn passwords have been brute-forced?  Will somebody help me understand how they're decrypting 20+ character passwords?  Last I read over 60% of the leaked hashes have been decrypted.  I can understand that being the case if most of them were really short and simple passwords, but it looks like a lot of them followed password security standards pretty well.  Help me understand.

Rainbow tables.

Longer answer.  By not using salt they made passwords deterministic.

The SHA-1 of "password" will ALWAYS be 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8.   The password can be precomputed.   It is made worse by the fact that SHA-1 (and SHA-256) are insanely fast.  A single GPU can hash up to a billion passwords per second.   In a year one can pre-hash and store 31 quadrillion passwords with a single graphics card.  A community of hackers can work together to hash a magnitude more.

The use of a fast hash algorithm combined with no salt dooms even the longest and most complex passwords.  They are already "pre-cracked" the hackers are simply looking them up in a lookup table.  One can obtain or purchase rainbow tables for just about any unsalted algorithm (or weakly salted like WPA2). 

Now using salt changes that:
The SHA-1 hash of "password" with a salt prefix of "123456789" is aa2cc735aa01f661a39d6a03214d2e551eb0d8ad
The SHA-1 hash of "passwrod" with a salt prefix of "123456780" is 5571911de78b7bdffcfa11ef75d93a6cab3d6540

Precomputation becomes impossible.  SHA-1 is still very very fast algorithm (which is bad) but salt at least makes the attacker work "in real time" which gives users with more complex passwords time to change them.  But even moderately complex passwords are going to fail because Moore's law is a monster.  I mean a GPU is a hashing engine.  Think about Bitcoin.  A Rigbox is 25 GH/s.  What does that mean?  It means it can perform 50 billion SHA-256 hashes per second.  If reprogrammed to crack passwords it could crack ever possible combination of 8 digit password in 9 hours.  All 9 digit passwords in 30 days.  Known, prior hacked, and dictionary passwords would fall in minutes.

Using "slow multi-round password function" (like bcrypt) AND a pre record salt eliminates all the short cuts.  The only option is to sllllllllllllllllloooooooooooooooooooooowwwwwwwwwllllllllllly brute force the passwords one record at a time.  That means exhaustively trying say all 8 digit passwords for a single account takes weeks if not months.   All but the weakest of the weak are just not economical to even attempt to attack"

Using a strong passwords is only half the answer.  You are also dependent on the service provider using proper password storage.

So now is the time to start asking sites "how are you storing my password?":
If they are using no salt (or a fixed per site salt) they don't care about your security.
If they are using a small salt (anything less than 64 bit, well 32bit is borderline) they don't care about your security.
If they are using a weakened or obsolete algorithm (SHA-1, MD5, etc) they don't care about your security.
If they are using a "fast hash" algorithm* (SHA-256, SHA-512, RIPEMD-160, etc) they don't care about your security.

* Unless iteratively performed.  PBKDF2 for example can use SHA-256 as it's "core cipher" but it strengthens it by hashing it tens of thousands of times:
SHA-256(salt+(SHA-256(salt + (SHA-256(salt + (SHA-256 .... SHA-256(salt + password)

[Xenland]

I don't understand how so many long and seemingly secure LinkedIn passwords have been brute-forced?  Will somebody help me understand how they're decrypting 20+ character passwords?  Last I read over 60% of the leaked hashes have been decrypted.  I can understand that being the case if most of them were really short and simple passwords, but it looks like a lot of them followed password security standards pretty well.  Help me understand.

Rainbow tables.

Longer answer.  By not using salt they made passwords deterministic.

The SHA-1 of "password" will ALWAYS be 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8.   The password can be precomputed.   It is made worse by the fact that SHA-1 (and SHA-256) are insanely fast.  A single GPU can has up to a billion passwords per second.   In a year one can pre-hash and store 31 quadrillion passwords with a single HD 5970.

The use of a fast hash algorithm & no salt dooms even the longest and most complex passwords.  They are already "pre-cracked" the hackers are simply looking them up in a lookup table.

Now using salt changes that.
The SHA-1 hash of "password" with a salt prefix of "123456789" is aa2cc735aa01f661a39d6a03214d2e551eb0d8ad
The SHA-1 hash of "passwrod" with a salt prefix of "123456780" is 5571911de78b7bdffcfa11ef75d93a6cab3d6540

Precomputation becomes impossible.  Now SHA-1 is still very very fast algorithm (which is bad) but salt at least makes the attacker work "in real time" which gives users with more complex passwords time to change them.

Using "slow multi-round password function" (like bcrypt) AND a pre record salt eliminates all the short cuts.  The only option is to sllllllllllllllllloooooooooooooooooooooowwwwwwwwwllllllllllly brute force the passwords one record at a time.

That means exhaustively trying say all 8 digit passwords for a single account takes weeks if not months.   All but the weakest of the weak are just not economical to even attempt to attack"

And now I know why people prefer Bcrypt
Might have to update myCheaper In Bitcoins Library to have this option.

[proudhon]

I don't understand how so many long and seemingly secure LinkedIn passwords have been brute-forced?  Will somebody help me understand how they're decrypting 20+ character passwords?  Last I read over 60% of the leaked hashes have been decrypted.  I can understand that being the case if most of them were really short and simple passwords, but it looks like a lot of them followed password security standards pretty well.  Help me understand.

Rainbow tables.

Longer answer.  By not using salt they made passwords deterministic.

The SHA-1 of "password" will ALWAYS be 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8.   The password can be precomputed.   It is made worse by the fact that SHA-1 (and SHA-256) are insanely fast.  A single GPU can has up to a billion passwords per second.   In a year one can pre-hash and store 31 quadrillion passwords with a single HD 5970.

The use of a fast hash algorithm & no salt dooms even the longest and most complex passwords.  They are already "pre-cracked" the hackers are simply looking them up in a lookup table.

Now using salt changes that.
The SHA-1 hash of "password" with a salt prefix of "123456789" is aa2cc735aa01f661a39d6a03214d2e551eb0d8ad
The SHA-1 hash of "passwrod" with a salt prefix of "123456780" is 5571911de78b7bdffcfa11ef75d93a6cab3d6540

Precomputation becomes impossible.  Now SHA-1 is still very very fast algorithm (which is bad) but salt at least makes the attacker work "in real time" which gives users with more complex passwords time to change them.

Using "slow multi-round password function" (like bcrypt) AND a pre record salt eliminates all the short cuts.  The only option is to sllllllllllllllllloooooooooooooooooooooowwwwwwwwwllllllllllly brute force the passwords one record at a time.

That means exhaustively trying say all 8 digit passwords for a single account takes weeks if not months.   All but the weakest of the weak are just not economical to even attempt to attack"

I understand that they didn't salt and that that makes it easier to get the passwords.  I guess what's worrisome is that from what I've read there were some reasonably secure passwords whose hashes were decrypted - passwords along the lines of "34IDdka]o43';s/A".  I don't think passwords like that can be decrypted in a few days, even using a bunch of GPUs.  So, are we to understand that passwords like that are in some giant rainbow table?  That's what's bothering me about this.

[mcorlett]

So, are we to understand that passwords like that are in some giant rainbow table?  That's what's bothering me about this.

Yes, but you shouldn't worry; most services salt their passwords, and many use multiple iterations making brute-force attacks infeasible.

[TangibleCryptography]

I understand that they didn't salt and that that makes it easier to get the passwords.  I guess what's worrisome is that from what I've read there were some reasonably secure passwords whose hashes were decrypted - passwords along the lines of "34IDdka]o43';s/A".  I don't think passwords like that can be decrypted in a few days, even using a bunch of GPUs.  So, are we to understand that passwords like that are in some giant rainbow table?  That's what's bothering me about this.

Yes.  It should bother you.

Without salt it is easy to precompute and store passwords years in advance.  When you get a hacked password database you simply "look them up". The hash of an input will never change so the hash of  "34IDdka]o43';s/A was "7c6fbf7e2bfceb28c7be5e5e669864a8f0fb079b in 1992, it is still the same today, and it will still be the same in 2099.

Now with salt they can't precompute the passwords but they can still brute force them much much easier than many people think if the hashing algorithm is fast.

A rig box = 50 billion hashes per second.  To put that into perspective, to brute force SHA-256 hashed passwords even with a 64 bit random per password salt would only take:
<1 sec to attempt a database of 20 million (known, leaked, common, and dictionary based) passwords.
<15 seconds to attempt all 6 digit or smaller passwords (A-Z,a-z,0-9, and all printable symbols).
< 30 minutes to attempt  all 7 digit passwords.
< 2 days to attempt  all 8 digit passwords.

Now that is with a single RigBox.  Botnets can easily be 10x, or even 20x more powerful.  A hacker which needs password fast (before users change them) can rent 100x as much computing power.    Hell if you need a metric the Bitcoin network is ~10TH/s.  If "rented out" it has the computing power to brute force all 9 digit and smaller passwords in less than a day.

A strong password is not enough.  Three elements are required (and sadly even some in the Bitcoin community treat it as optional):
1) A strong password (which means website checking new password against lists of know and compromised passwords)
2) A slow hashing function (bcrypt, scrypt, pbkdf2, etc)
3) A large random per record (64 bit) salt

Anything less is insecure.  How insecure varies (from trivial to tough) but it can and will be broken given enough time and resources.


On edit: clarified a few points and fixed some horrible spelling.

[justusranvier]

Yes.  It should bother you.

Without salt it is easy to precompute and store passwords years in advance.  When you get a hacked password database you simply "look them up". They password will never change so the hash of  "34IDdka]o43';s/A was "7c6fbf7e2bfceb28c7be5e5e669864a8f0fb079b in 1992, it is still the same today and it will still be the same in 2099.

Now with salt they can't do that but as I pointed out people way way way way (20 magnitudes of way) understimate how easy it is to brute force passwords if the hashing algorithm is fast.

A rig box = 50 billion hashes per second.  To put that into perspective EVEN WITH SALT:
To brute force a database of 20 million (know, leaked, common, and dictionary based) passwords would take: <1 second
To brute force all 6 digit or smaller passwords would take ~ 14 seconds.
To brute force all 7 digit passwords would take ~ 23 minutes.
To brute force all 8 digit passwords would take ~ 1.5 days.

A strong password is not enough.  Three elements are requried (and sadly even some in the Bitcoin community treat it as optional):
1) A strong password (which means website checking new password against lists of know and compromised passwords)
2) A slow hashing function (bcrypt, scrypt, pbkdf2, etc)
3) A large random per record (64 bit) salt

Anything less is insecure.  How insecure varies but it can and will be broken given enough time and resources.

I wonder what it's going to take for authentication systems like gpgAuth to see adoption.

[proudhon]

I understand that they didn't salt and that that makes it easier to get the passwords.  I guess what's worrisome is that from what I've read there were some reasonably secure passwords whose hashes were decrypted - passwords along the lines of "34IDdka]o43';s/A".  I don't think passwords like that can be decrypted in a few days, even using a bunch of GPUs.  So, are we to understand that passwords like that are in some giant rainbow table?  That's what's bothering me about this.

Yes.  It should bother you.

Without salt it is easy to precompute and store passwords years in advance.  When you get a hacked password database you simply "look them up". The hash of an input will never change so the hash of  "34IDdka]o43';s/A was "7c6fbf7e2bfceb28c7be5e5e669864a8f0fb079b in 1992, it is still the same today, and it will still be the same in 2099.

Now with salt they can't precompute the passwords but they can still brute force them much much easier than many people think if the hashing algorithm is fast.

A rig box = 50 billion hashes per second.  To put that into perspective, to brute force SHA-256 hashed passwords even with a 64 bit random per password salt would only take:
<1 sec to attempt a database of 20 million (known, leaked, common, and dictionary based) passwords.
<15 seconds to attempt all 6 digit or smaller passwords (A-Z,a-z,0-9, and all printable symbols).
< 30 minutes to attempt  all 7 digit passwords.
< 2 days to attempt  all 8 digit passwords.

Now that is with a single RigBox.  Botnets can easily be 10x, or even 20x more powerful.  A hacker which needs password fast (before users change them) can rent 100x as much computing power.    Hell if you need a metric the Bitcoin network is ~10TH/s.  If "rented out" it has the computing power to brute force all 9 digit and smaller passwords in less than a day.

A strong password is not enough.  Three elements are required (and sadly even some in the Bitcoin community treat it as optional):
1) A strong password (which means website checking new password against lists of know and compromised passwords)
2) A slow hashing function (bcrypt, scrypt, pbkdf2, etc)
3) A large random per record (64 bit) salt

Anything less is insecure.  How insecure varies (from trivial to tough) but it can and will be broken given enough time and resources.


On edit: clarified a few points and fixed some horrible spelling.

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

[mcorlett]

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

No, because every additional character exponentially increases the effort required to break the key.

[proudhon]

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

No, because every additional character exponentially increases the effort required to break the key.

But, in 10 years?  Imagine that in 10 years a single RigBox is 100x as powerful as today's, and that I can rent 100 of them.  That much compute power still isn't enough to get a private key in, say, a few weeks?

[TangibleCryptography]

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

No, because every additional character exponentially increases the effort required to break the key.

But, in 10 years?  Imagine that in 10 years a single RigBox is 100x as powerful as today's, and that I can rent 100 of them.  That much compute power still isn't enough to get a private key in, say, a few weeks?

Nope not in a 1000 years either.

Large numbers can mess with people's minds but this might help.

A random 10 digit password (95 possible values per digit) is ~ 2^64 or 64 bit.   256 bit isn't 4x as large it is  6,277,101,735,386,680,000,000,000,000,000,000,000,000,000,000,000,000,000,000 as large (roughly excel needs to round).

If you could crack brute force all possible 64 bit keys in 1 second it would still take roughly   19,904,559,029,003,900,000,000,000,000,000,000,000,000,000,000 centuries to have a 1% chance of brute forcing a private key.  

Another way to look at is our sun doesn't have enough energy remaining to power a computer that could count from 0 to 2^256 much less brute force a specific key.  That is you build a computer who could use the sun's complete energy output and operated at 100% efficiency it still couldn't count to 2^256 before our star burned out.

So the only risk to a private key is if the SHA-256 algorithm is broken or more likely degraded.  By degraded I mean some flaw is discovered that allows you to take a "shortcut" and thus eliminate trillions or quadrillions of keys simultaneously.  Even degraded it would likely be very difficult (maybe only of academic interest) to brute force a private key but that would be a good sign to upgrade Bitcoin (and everything else which uses SHA-2) to a stronger algorithm.

[justusranvier]

But, in 10 years?  Imagine that in 10 years a single RigBox is 100x as powerful as today's, and that I can rent 100 of them.  That much compute power still isn't enough to get a private key in, say, a few weeks?

If every atom in the solar system were a computer capable of performing calculations at 10 GHz (assuming all calculations could be done in a single cycle) it would take 300,000 years to count to 2^256

[sadpandatech]

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

No, because every additional character exponentially increases the effort required to break the key.

But, in 10 years?  Imagine that in 10 years a single RigBox is 100x as powerful as today's, and that I can rent 100 of them.  That much compute power still isn't enough to get a private key in, say, a few weeks?

Nope not in a 1000 years either.

Large numbers can mess with people's minds but this might help.

A random 10 digit password (95 possible values per digit) is ~ 2^64 or 64 bit.   256 bit isn't 4x as large it is 6277101735386680000000000000000000000000000000000000000000 as large (roughly excel needs to round).

If you could crack a 10 digit password in 1 second it would take roughly 995227951450197000000000000000000000000000000000 centuries to have a 50% chance of brute forcing a private key.  Even if you could build planetary sized supercomputers and capture the entire energy output of our sun and use it to power a perfectly efficient computer, our sun doesn't have enough energy remaining energy to power a computer that could count from 0 to 2^256 much less brute force a specific key.

So the only risk to a private key is if the SHA-256 algorithm is broken or more likely degraded.  By degraded I mean some flaw that allows you to take a shortcut and thus eliminate billions or trillions of keys simultaneously (even that would still mean it would be very difficult to break but would be a good sign to move to a new algorithm).

This. plus its been mentioned before that Bitcoin can be upgraded to 512 bit keys, etc as the need arises.

[proudhon]

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

No, because every additional character exponentially increases the effort required to break the key.

But, in 10 years?  Imagine that in 10 years a single RigBox is 100x as powerful as today's, and that I can rent 100 of them.  That much compute power still isn't enough to get a private key in, say, a few weeks?

Nope not in a 1000 years either.

Large numbers can mess with people's minds but this might help.

A random 10 digit password (95 possible values per digit) is ~ 2^64 or 64 bit.   256 bit isn't 4x as large it is  6,277,101,735,386,680,000,000,000,000,000,000,000,000,000,000,000,000,000,000 as large (roughly excel needs to round).

If you could crack brute force all possible 64 bit keys in 1 second it would still take roughly   19,904,559,029,003,900,000,000,000,000,000,000,000,000,000,000 centuries to have a 1% chance of brute forcing a private key.  

Another way to look at is our sun doesn't have enough energy remaining to power a computer that could count from 0 to 2^256 much less brute force a specific key.  That is you build a computer who could use the sun's complete energy output and operated at 100% efficiency it still couldn't count to 2^256 before our star burned out.

So the only risk to a private key is if the SHA-256 algorithm is broken or more likely degraded.  By degraded I mean some flaw is discovered that allows you to take a "shortcut" and thus eliminate trillions or quadrillions of keys simultaneously.  Even degraded it would likely be very difficult (maybe only of academic interest) to brute force a private key but that would be a good sign to upgrade Bitcoin (and everything else which uses SHA-2) to a stronger algorithm.

Got it.  Thank you!

[Serge]

a more technical question

what are good standards or principles for generating and handling salts?

from above posts i understand it is recommended to use unique large salts per db record, which obviously should not be stored in database in plain sight along with hashes. when user enters password, how is it recommended to generate random salt for a hash which needs be reused later on when user logs back in into a site; as only other supplied data by user usually is username/handle/email, which again presumably are stored in plain sight along with salted hash of a password?

[TangibleCryptography]

a more technical question

what are good standards or principles for generating and handling salts?

from above posts i understand it is recommended to use unique large salts per db record, which obviously should not be stored in database in plain sight along with hashes. when user enters password, how is it recommended to generate random salt for a hash which needs be reused later on when user logs back in into a site; as only other supplied data by user usually is username/handle/email, which again presumably are stored in plain sight along with salted hash of a password?

Don't use user information it has low entropy.   Salt isn't a secret, it is simply a mechanism used to make hashes unique and defeat precomputation attacks.  It can be stored right in the database next to the hash.

bcrypt for example stores everything you need in a single output

Code:

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

For example you just need to store this single string (bcrypt output is always 60 char).

$2a indicates the version (ensures that if future version are created your hash can always be reconstructed)
$10 indicates a workload of 10 = 2^10 iterations.
$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa is the salt + hash.

vI8aWBnW3fID.ZQ4 is the salt = 128 bit nonce
/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa is the hash (always 184 bit - yeah somewhat unusual).

to verify the password you put the entire string back into bcrypt algorithm along with the plaintext.  bcrypt parses the string to determine the salt, hash, version, and # of rounds and hashes the password and compares it to the stored hash.

If you then want to update the strength (say you now want workload of 14 because computers are faster you simply hash the plaintext again w/ bcrypt but using workload 14 instead of 10.  bcrypt will chose a new random nonce and generate a new output say something like this:

Code:

$2a$14$vIcZEiUP1KUQ4/zo1WBnGDMVr5yW3fIG.q18aD.ZGLlRps.9cOYTa

Update the db to store this string instead and TADA the password is now 2^4 = 16x harder to crack.

[Phinnaeus Gage]

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

No, because every additional character exponentially increases the effort required to break the key.

But, in 10 years?  Imagine that in 10 years a single RigBox is 100x as powerful as today's, and that I can rent 100 of them.  That much compute power still isn't enough to get a private key in, say, a few weeks?

Nope not in a 1000 years either.

Large numbers can mess with people's minds but this might help.

A random 10 digit password (95 possible values per digit) is ~ 2^64 or 64 bit.   256 bit isn't 4x as large it is 6277101735386680000000000000000000000000000000000000000000 as large (roughly excel needs to round).

If you could crack a 10 digit password in 1 second it would take roughly 995227951450197000000000000000000000000000000000 centuries to have a 50% chance of brute forcing a private key.  Even if you could build planetary sized supercomputers and capture the entire energy output of our sun and use it to power a perfectly efficient computer, our sun doesn't have enough energy remaining energy to power a computer that could count from 0 to 2^256 much less brute force a specific key.

So the only risk to a private key is if the SHA-256 algorithm is broken or more likely degraded.  By degraded I mean some flaw that allows you to take a shortcut and thus eliminate billions or trillions of keys simultaneously (even that would still mean it would be very difficult to break but would be a good sign to move to a new algorithm).

This. plus its been mentioned before that Bitcoin can be upgraded to 512 bit keys, etc as the need arises.

Given the above, then isn't upgrading to 512 bit keys a mute issue, or am I missing why that upgrade is important?

~Bruno~

[TangibleCryptography]

Given the above, then isn't upgrading to 512 bit keys a mute issue, or am I missing why that upgrade is important?

Probably.  The most likely scenario where an upgraded is required is because SHA-256 has some sort of flaw.  Since all versions of SHA-2 share the same algorithm (with different block sizes) it would be best to choose a new tested algorithm.  NIST is already conducting testing and competitions to find the algorithm which will become SHA-3.

[Serge]

sweet. thanks TangibleCryptography for a simple explanation. i was puzzled before regarding salts whether they need to be secret or obscure, now everything makes perfect sense. Thank you!

[casascius]

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

$2a$14$vIcZEiUP1KUQ4/zo1WBnGDMVr5yW3fIG.q18aD.ZGLlRps.9cOYTa

 

[TangibleCryptography]

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

$2a$14$vIcZEiUP1KUQ4/zo1WBnGDMVr5yW3fIG.q18aD.ZGLlRps.9cOYTa

 

Good catch.  That is why I said "output say something like this".   You get the point though.  Actually I have no idea what the plaintext is.

[niko]

I understand that they didn't salt and that that makes it easier to get the passwords.  I guess what's worrisome is that from what I've read there were some reasonably secure passwords whose hashes were decrypted - passwords along the lines of "34IDdka]o43';s/A".  I don't think passwords like that can be decrypted in a few days, even using a bunch of GPUs.  So, are we to understand that passwords like that are in some giant rainbow table?  That's what's bothering me about this.

Yes.  It should bother you.

Without salt it is easy to precompute and store passwords years in advance.  When you get a hacked password database you simply "look them up". The hash of an input will never change so the hash of  "34IDdka]o43';s/A was "7c6fbf7e2bfceb28c7be5e5e669864a8f0fb079b in 1992, it is still the same today, and it will still be the same in 2099.

Now with salt they can't precompute the passwords but they can still brute force them much much easier than many people think if the hashing algorithm is fast.

A rig box = 50 billion hashes per second.  To put that into perspective, to brute force SHA-256 hashed passwords even with a 64 bit random per password salt would only take:
<1 sec to attempt a database of 20 million (known, leaked, common, and dictionary based) passwords.
<15 seconds to attempt all 6 digit or smaller passwords (A-Z,a-z,0-9, and all printable symbols).
< 30 minutes to attempt  all 7 digit passwords.
< 2 days to attempt  all 8 digit passwords.

Now that is with a single RigBox.  Botnets can easily be 10x, or even 20x more powerful.  A hacker which needs password fast (before users change them) can rent 100x as much computing power.    Hell if you need a metric the Bitcoin network is ~10TH/s.  If "rented out" it has the computing power to brute force all 9 digit and smaller passwords in less than a day.

A strong password is not enough.  Three elements are required (and sadly even some in the Bitcoin community treat it as optional):
1) A strong password (which means website checking new password against lists of know and compromised passwords)
2) A slow hashing function (bcrypt, scrypt, pbkdf2, etc)
3) A large random per record (64 bit) salt

Anything less is insecure.  How insecure varies (from trivial to tough) but it can and will be broken given enough time and resources.


On edit: clarified a few points and fixed some horrible spelling.

Well, this bothers me on two fronts then.  If there are rentable hashing resources with as much as 100x as much computing power as a RigBox, then it doesn't seem implausible to me to see rentable resources in the next decade that could, within a reasonable amount of time, get a private bitcoin key from a public key.  No?  What am I missing?

Isn't it likely that those strong-looking passwords were phished from the unsuspecting victims clicking on links from "LinkedIn" after the hack? The same thing was going on after the gox hack.

[cytokine]

Can someone explain to me the big practical difference between SHA-256 and SHA-512, other than the larger digest for the latter?

[TangibleCryptography]

Can someone explain to me the big practical difference between SHA-256 and SHA-512, other than the larger digest for the latter?

Not much.

SHA-256 block size (input) is 512 bit and SHA-512 block size is 1024 bit.
SHA-256 digest (output) is 256 bit and SHA-512 digest is 512 bit.
The initialization constants are different.
SHA-256 uses 32 bit "chunks".  SHA-512 uses 64bit "chunks"
SHA-256 has 64 rounds (iterations of the algorithm), SHA-512 has 80.

Other than that they pretty much are the same.  Same basic algorithm.

[cytokine]

Can someone explain to me the big practical difference between SHA-256 and SHA-512, other than the larger digest for the latter?

Not much.

SHA-256 block size (input) is 512 bit and SHA-512 block size is 1024 bit.
SHA-256 digest (output) is 256 bit and SHA-512 digest is 512 bit.
The initialization constants are different.
SHA-256 uses 32 bit "chunks".  SHA-512 uses 64bit "chunks"
SHA-256 has 64 rounds (iterations of the algorithm), SHA-512 has 80.

Other than that they pretty much are the same.  Same basic algorithm.

So is there a significant security advantage to using SHA512 over SHA256, or not really enough of one to justify the extra cost?

[TangibleCryptography]

So is there a significant security advantage to using SHA512 over SHA256, or not really enough of one to justify the extra cost?

SHA-512 actually hashes faster on most CPU (x64 capable) and slower on most GPU.  So I would be inclined to use SHA-512 over SHA-256 for passwords.   The extra "cost" (in terms of computing power, storage, memory) is negligible.   Still SHA-2 is very fast algorthm so some sort of chained function like PBKDF2 is necessary.  If it is a new project I see no reason to not just start with SHA-512.

If you mean upgrading Bitcoin from SHA256 to SHA512 well that is likely futile.  SHA-256 is more than strong enough today.  Any advantages of SHA-512 are at this point theoretical.  It is very possible that whatever weakens SHA-256 will weakens all SHA-2 algorithms.    If you are going to do something as disruptive as change Bitcoin's core algorithm you might as well make a clean break and not do a baby step from SHA-256 to SHA-512.

[Xenland]

Anyone know of a website or something that could explain this formula in some kind of dumbed down English, I understand encryption practices fairly well I've always wanted to know what the formula it self is doing be hind the since I just don't know Alien math quite yet

[TangibleCryptography]

http://en.wikipedia.org/wiki/SHA-2#Examples_of_SHA-2_variants has a pretty good psuedo code of the SHA-2 algorithm. 

The diagram above is used to represent a single round of the SHA-2 hashing algorithm.  SHA-256 uses 64 rounds.  The A to H are variables which compute a running sum.  You will notice on each round the values in those 8 registers move to the right.  The functions on the right S0, S1, t1, t2, maj, and ch are the functions which make up the SHA-2 algorithm. 

The input (block) is broken into 16 32 bit words (w0 to 15) and used by the functions (S0, S1, t1, t2, maj, and ch) to compute a new value A.  That is round #1.  The same process happens 64 times. 

The final set of registers A to H are then concatenated and that forms the hash.

[Tritonio]

My password is not even in that list. So I guess it's not all passwords as some say.

[nimda]

I'm getting skeptical that it is even from linkedin... the # of SHA1 hashes != the number of LinkedIn users, or so I hear...

[BCB]

6M Hashes released -  150M users.

[Stephen Gornick]

This morning, a dump of unique passwords f

And the fun continues.   450K usernames and passwords from Yahoo! Voice:

 - http://www.trustedsec.com/july-2012/yahoo-voice-website-breached-400000-compromised/

[Bitcoin Oz]

This morning, a dump of unique passwords f

And the fun continues.   450K usernames and passwords from Yahoo! Voice:

 - http://www.trustedsec.com/july-2012/yahoo-voice-website-breached-400000-compromised/

The most alarming part to the entire story was the fact that the passwords were stored completely unencrypted

 

[niko]

A class-action suit against linkedin inititiated in US federal court in San Jose. The plaintiffs allege that the company was not securing the user database per industry standards.

I find it disgusting that LinkedIn still claims that "users' accounts were not breached as a result of the leak." I started receiving spam invitations to connect from total strangers- which never happened before the leak. Pathetic.

[finkleshnorts]

Hmm... how does this relate to microcash...