Bitcoin Forum
December 08, 2016, 08:27:51 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 »  All
  Print  
Author Topic: [Password Leak] LinkedIn database hacked  (Read 10321 times)
weex
Legendary
*
Offline Offline

Activity: 1062


Give me your tired, your poor, your huddled...


View Profile
June 07, 2012, 07:44:49 AM
 #41

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.

1481228871
Hero Member
*
Offline Offline

Posts: 1481228871

View Profile Personal Message (Offline)

Ignore
1481228871
Reply with quote  #2

1481228871
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Serenata
Sr. Member
****
Offline Offline

Activity: 251



View Profile WWW
June 07, 2012, 07:46:23 AM
 #42

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.

BitcoinX.gr - Το ελληνικό στέκι του Bitcoin

My GPG Key
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
June 07, 2012, 08:35:58 AM
 #43

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

Activity: 742


There is more to Bitcoin than bitcoins.


View Profile
June 07, 2012, 09:00:57 AM
 #44

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.

They're there, in their room.
Your mining rig is on fire, yet you're very calm.
zhoutong
VIP
Hero Member
*
Offline Offline

Activity: 490


View Profile WWW
June 07, 2012, 11:02:25 AM
 #45

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

Founder of NameTerrific (https://www.nameterrific.com/). Co-founder of CoinJar (https://coinjar.io/)

Donations for my future Bitcoin projects: 19Uk3tiD5XkBcmHyQYhJxp9QHoub7RosVb
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1442



View Profile
June 07, 2012, 11:50:27 AM
 #46

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

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 01:58:09 PM
 #47

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

Activity: 1050


View Profile
June 07, 2012, 01:59:30 PM
 #48

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

Activity: 1232


View Profile
June 07, 2012, 02:04:07 PM
 #49

https://intersango.com/security.php

Intersango uses SHA512 + salt + site wide secret
TangibleCryptography
Sr. Member
****
Offline Offline

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 02:07:47 PM
 #50

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

Activity: 521


Free BTC for listening to radio! INFORM THE MEN!


View Profile WWW
June 07, 2012, 02:32:29 PM
 #51

And remember to always salt your passwords  Wink

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

Activity: 966


BCJ


View Profile
June 07, 2012, 02:56:11 PM
 #52

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

Activity: 666



View Profile
June 07, 2012, 03:30:35 PM
 #53

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

Activity: 1400



View Profile WWW
June 07, 2012, 03:35:28 PM
 #54

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

Activity: 1148



View Profile
June 07, 2012, 04:42:40 PM
 #55

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

Activity: 530


View Profile
June 07, 2012, 04:44:53 PM
 #56

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

Activity: 308



View Profile
June 07, 2012, 04:52:09 PM
 #57

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

Activity: 980


I'm not just any shaman, I'm a Sha256man


View Profile
June 07, 2012, 04:53:58 PM
 #58

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 Cheesy

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

Activity: 476


Tangible Cryptography LLC


View Profile WWW
June 07, 2012, 05:00:11 PM
 #59

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

Activity: 980


I'm not just any shaman, I'm a Sha256man


View Profile
June 07, 2012, 05:05:27 PM
 #60

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 Cheesy
Might have to update myCheaper In Bitcoins Library to have this option.
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!