Bitcoin Forum
December 07, 2016, 12:38:52 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 »  All
  Print  
Author Topic: [Password Leak] LinkedIn database hacked  (Read 10317 times)
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
June 07, 2012, 05:16:57 PM
 #61

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.
1481114332
Hero Member
*
Offline Offline

Posts: 1481114332

View Profile Personal Message (Offline)

Ignore
1481114332
Reply with quote  #2

1481114332
Report to moderator
Creating a Bitcoin client that fully implements the network protocol is extremely difficult. Bitcoin-Qt is the only known safe implementation of a full node. Some other projects attempt to compete, but it is not recommended to use such software for anything serious. (Lightweight clients like Electrum and MultiBit are OK.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481114332
Hero Member
*
Offline Offline

Posts: 1481114332

View Profile Personal Message (Offline)

Ignore
1481114332
Reply with quote  #2

1481114332
Report to moderator
1481114332
Hero Member
*
Offline Offline

Posts: 1481114332

View Profile Personal Message (Offline)

Ignore
1481114332
Reply with quote  #2

1481114332
Report to moderator
1481114332
Hero Member
*
Offline Offline

Posts: 1481114332

View Profile Personal Message (Offline)

Ignore
1481114332
Reply with quote  #2

1481114332
Report to moderator
mcorlett
Donator
Sr. Member
*
Offline Offline

Activity: 308



View Profile
June 07, 2012, 05:19:51 PM
 #62

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
Sr. Member
****
Offline Offline

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 05:27:08 PM
 #63

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

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

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
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 07, 2012, 05:32:20 PM
 #64

Yes.  It should bother you. Smiley

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
Legendary
*
Offline Offline

Activity: 1148



View Profile
June 07, 2012, 05:42:29 PM
 #65

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

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

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
Donator
Sr. Member
*
Offline Offline

Activity: 308



View Profile
June 07, 2012, 05:46:35 PM
 #66

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
Legendary
*
Offline Offline

Activity: 1148



View Profile
June 07, 2012, 05:52:02 PM
 #67

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
Sr. Member
****
Offline Offline

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 06:05:10 PM
 #68

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
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 07, 2012, 06:13:10 PM
 #69

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
Hero Member
*****
Offline Offline

Activity: 504



View Profile
June 07, 2012, 06:14:25 PM
 #70

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.

If you're not excited by the idea of being an early adopter 'now', then you should come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system. - GA
It is being worked on by smart people. -DamienBlack
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
June 07, 2012, 06:24:07 PM
 #71

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
Legendary
*
Offline Offline

Activity: 1050


View Profile
June 07, 2012, 06:57:21 PM
 #72

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
Sr. Member
****
Offline Offline

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 07:25:31 PM
 #73

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
Legendary
*
Offline Offline

Activity: 1302


Bitcoin: An Idea Worth Spending


View Profile
June 07, 2012, 07:26:18 PM
 #74

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
Sr. Member
****
Offline Offline

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 07:29:20 PM
 #75

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
Legendary
*
Offline Offline

Activity: 1050


View Profile
June 07, 2012, 07:31:23 PM
 #76

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
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
June 07, 2012, 07:34:37 PM
 #77


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

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


 Wink

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
TangibleCryptography
Sr. Member
****
Offline Offline

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 07:43:15 PM
 #78


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

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


 Wink

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
Hero Member
*****
Offline Offline

Activity: 742


There is more to Bitcoin than bitcoins.


View Profile
June 07, 2012, 09:01:49 PM
 #79

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

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

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.

They're there, in their room.
Your mining rig is on fire, yet you're very calm.
cytokine
Donator
Full Member
*
Offline Offline

Activity: 224



View Profile
June 07, 2012, 09:08:36 PM
 #80

Can someone explain to me the big practical difference between SHA-256 and SHA-512, other than the larger digest for the latter?
Pages: « 1 2 3 [4] 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!