Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

trustedsec.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#41

Post by woodman »

lpage wrote: post #36
Matt3o12_ wrote: post #27

Earlier quoted context omitted.

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…

> Outsourcing them is not the answer It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost…

https://en.wikipedia.org/wiki/Pluggable_authentication_modul...

That is pretty much the first thing I do when I inherit a project with authentication. You don't need to make another company your application's doorman, there are a lot of PAM backends that you can run on premises that "do it for you". If you have the competency to manage a LAMP stack - then you can likely handle a well tested and existing authentication server.

All the years in physical security might have broken my brain, because I am always surprised by how willing people are to leak information that doesn't need to be leaked. One project I was pulled into was on the precipice of uploading millions of customer's addresses to Google's geolocation API - had I not been able to bring the lead to his senses I might have made a run for the network closet.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#42

Post by lstamour »

miles wrote: post #15

From a comment by giveen[1] on reddit earlier: "At hashes.org, 87% completed https://hashes.org/public.php " There are loads of cracked hashes from other public leaks as well at hashes.org - worth adding these to your pen testing dictionaries. [1] https://www.reddit.com/r/netsec/comments/4ozdz8/introduction...

A bit on the motivations of hashes.org: https://s3inlc.wordpress.com/2014/05/27/hashes-org/

Seems it was started for the linked in hashes, which are at the bottom of the page, if you were wondering...

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#43

Post by voycey »

Matt3o12_ wrote: post #27
afreak wrote: post #2

Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…

The point of bcrypt though is that it is (more) future proof in that the hash generation is slow as balls and can be made exponentially slower by increasing the difficulty.

Other than some kind of algorithm weakness this slowness will translate through to the brute force attack thus taking longer for an attacker. BCrypt also has something that means it is harder for a GPU to crack it (mutable RAM memory tables or something).

As for migrating passwords - you can use a fallback password hasher that checks against a previous hash should the main one fail - then once the login is successful re-hash with the newest algorithm!

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#44

Post by kevin_thibedeau »

Matt3o12_ wrote: post #27
afreak wrote: post #2

Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…

> How long would it take to implement a change which updates the hashing algorithm for new logins while still using the old algorithm for old logins?

As long as you remember to store the cost parameter along with each hash it's just a matter of increasing the default cost and reusing the old ones.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#45

Post by rincebrain »

criddell wrote: post #39
cm2187 wrote: post #31

Earlier quoted context omitted.

Unsalted hashes in 2012 was negligence already...

I complained to my bank that their 12 character password limit suggests they are storing passwords. Their reply was little more than don't worry about it, you aren't responsible for fraud . I asked for them to add some kind of second factor authentication (I'm a fan of TOTP systems) and was told they are thinking about making that available for their business accounts. It bothers me that my most valuable login is pro…

I'm glad they fixed this, but until relatively recently (last year), Charles Schwab had the following password requirements:

* between 6 and 8 characters

* alphanumeric

* no symbols

* case-insensitive

[1] is a nice writeup of exactly how broken this was until they changed it recently.

[1] - http://www.jeremytunnell.com/posts/swab-password-policies-an...

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#46

Post by Matt3o12_ »

kevin_thibedeau wrote: post #44
Matt3o12_ wrote: post #27

Earlier quoted context omitted.

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…

> How long would it take to implement a change which updates the hashing algorithm for new logins while still using the old algorithm for old logins? As long as you remember to store the cost parameter along with each hash it's just a matter of increasing the default cost and reusing the old ones.

I was talking about the algorithm. Let's say bcrypt is considered insecure in 5 years (even with 100 iterations) and you are supposed to use another hash algorithm. Is your code and database able to handle that? If so, great but I don't think many people implement this and depending on your code, this can get difficult.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#47

Post by Matt3o12_ »

voycey wrote: post #43
Matt3o12_ wrote: post #27

Earlier quoted context omitted.

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…

The point of bcrypt though is that it is (more) future proof in that the hash generation is slow as balls and can be made exponentially slower by increasing the difficulty. Other than some kind of algorithm weakness this slowness will translate through to the brute force attack thus taking longer for an attacker. BCrypt also has something that means it is harder for a GPU to crack it (mutable RAM memory tables or som…

You can't really know how future proof it is, though. As far as I know, nobody has proven it to be unbreakable. Right know we can't break it, we can only brutal force it but maybe tomorrow a mathematician finds some properties to calculate all possible inputs of a certain length for the hash within a reasonable time. Or maybe they find another way that doesn't include brutal force (statistics, ...).

What I'm saying is that passwords are hard in general (to store, to enforce policies properly, ...) and just because bcrypt is "unbreakable" right now, doesn't mean it has to be in 5 years.

Your last paragraph describes nicely what needs to be done, but is your code ready for that? Maybe your database password/salt column only allows X characters, now you need to rebuild the database. Maybe something else expects the passwords to have that specific format (another micro service, some script, ...). Re-hashing a password can be hard if this possibility was not considered from day one.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#48

Post by bluedino »

Keyframe wrote: post #21

I forgot root password on my old IRIX / SGI Octane2 and had to "crack" it a few months ago. Turned out it was using full eight characters and was on the tail-end of the alphabet. It took less than a day to guess it on an older two-gpu 680GTX machine with cudaHashcat. Also, how awesome of IRIX guys was to not allow more than 8 characters in a password?

If it was IRIX it might have been faster to run some old exploit and then reset it

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#49

Post by lpage »

woodman wrote: post #41
lpage wrote: post #36

Earlier quoted context omitted.

> Outsourcing them is not the answer It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost…

https://en.wikipedia.org/wiki/Pluggable_authentication_modul... That is pretty much the first thing I do when I inherit a project with authentication. You don't need to make another company your application's doorman, there are a lot of PAM backends that you can run on premises that "do it for you". If you have the competency to manage a LAMP stack - then you can likely handle a well tested and existing authenticatio…

PAM is great, and it's especially great as a layer of indirection, but I can't agree with your overall point that using PAM = problem solved. To your no harder than LAMP point, most teams can't competently manage a security critical LAMP stack. They're in good company given that big companies/governments get pwned with great regularity. Survival requires defense in depth, and that gets expensive. It's a matter of everything from policy (are there two-man change controls on firewall rules, do separate teams own the route tables and firewall, do separate teams develop/audit/deploy security critical code) to hardware (is private key material stored on an HSM, are sensitive services physically isolated, does entropy come from a hardware RNG). Most small companies aren't thinking about those things.

Also, given that the P is for pluggable, what's the backend? You wouldn't use pam_unix for users outside your org. A DB? Now you're back to square one. LDAP+Kerberos/AD? That beats the DB but it doesn't do anything for your defense in depth requirement.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#50

Post by bigiain »

sgarman wrote: post #9
afreak wrote: post #2

Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…

Most of the attacks described in this article are not solved by any of those though right? They protect against hacking one person but if you just do these advanced dictionary attacks you can still crack people with weak passwords. Maybe I'm missing something?

They're not "solved", but they're made 3 to 6 orders of magnitude more effort:

See https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

"8x Nvidia GTX 1080 Hashcat Benchmarks"

TL;DR:

Hashtype: MD5 Speed.Dev.#.: 200.3 GH/s

Hashtype: SHA1 Speed.Dev.#.: 68771.0 MH/s

Hashtype: bcrypt, Blowfish(OpenBSD) Speed.Dev.#.: 105.7 kH/s

Hashtype: scrypt Speed.Dev.#.: 3493.6 kH/s

Hashtype: PBKDF2-HMAC-SHA512 Speed.Dev.#.: 3450.1 kH/s

Hashtype: PBKDF2-HMAC-MD5 Speed.Dev.#.: 59296.5 kH/s

You can't protect against people using "password123" or "dadada" as their passwords, but for those of us using long randomly generated passwords bcrypt makes cracking it well outside the realms of possibility for anyone short of nation-state attackers. (I bet the NSA can get quite a lot more than 100kH/s for bcrypt if they're determined enough, but I wonder if even _they_ can throw 6 orders of magnitude more compute at the task?)

Post reply on HN