Live data from Hacker News

Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

trustedsec.com

51–60 of 79 posts

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

#51
post #29

Earlier quoted context omitted.

bcrypt uses unique salts per-password. The hash outputted by the bcrypt function is actually several delimited fields that have been joined into a single string. This means that if multiple users use a common password like 'pass123', the hashes stored in the database will still each be unique. Any attacker trying to reverse all of the password hashes will have to reverse every single one individually in a targeted ma…

What are the advantages of bcrypt compared to SHA based hashes with unique salts?

bcrypt is significantly slower to compute. Something like 5 or 6 orders of magnitude slower. (se my other comment in here with numbers for cracking various hash types on an 8gpu rig...)

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

#52
post #34
post #4

85% cracked in a few days is seriously depressing. What does a box like the one mentioned in the article cost? Any estimate on the time to crack the remaining 15%?

> Any estimate on the time to crack the remaining 15%? I know of at least one person on LinkedIn using passwords of the form 2jzAwGyOzfxNoW0u3lTIIa (i.e., 22 digits & mixed-case letters); calculating 209.7 million hashes per second he should be able to crack his first one of that sort of password in about 182,686,540 years. I cordially wish him the best.

Anybody using a modern password safe should be in exactly that position. I use 1Password and default to 25chars including upper/lower/digits/specials. It's occasionally annoying when I need to transcribe one of those passwords from my phone into a system I trust but not enough to keep my password safe on (my work laptop, for example), butthat's rare enough that I just suck it up and cope.

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

#53
post #7

Honest question, how does somebody know whether a dumped hashed/"encrypted" password has actually been broken and exists in plaintext? Some time ago I reset almost all my passwords to 1passwd $RAND, but some of these dumps are ooooold. Is there a legit way to find what's available for my email?

There are several services (including one run by me). https://canar.io (mine) https://haveibeenpwned.com/ Mine lets you free-form search whereas HaveIBeenPwned is there for searching just e-mail addresses.

Yours is fun, in that it's more free-form, but HIBP seems to cover more ground.

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

#54
post #49
post #41

Earlier quoted context omitted.

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 eve…

> ...I can't agree with your overall point that using PAM = problem solved.

I don't think we have the same problem definition. I'm saying that it solves the problem of authentication implementation details - where the just-enough-to-be-dangerous types screw up (salting, keyspace, the keeping current on crypto part). LDAP can certainly be leveraged for defense in depth, authorization vs authentication, but that is much less off-the-shelf. This also provides some separation between the authentication server and braindead PHP scripts that barf the results of ";select * from users;".

> Also, given that the P is for pluggable, what's the backend?

Kerberos is the obvious choice for authentication, LDAP integration for authorization if you're needing a fine granularity. You'd really have to go out of your way to end up with a PAM that dumps right into a DB with a poor crypto policy - I've never seen it. You could use /etc/passwd - but you're right, you wouldn't want to... the option is nice though.

I don't disagree that a company that makes money primarily on identity management could do it better, if you assign a low value to the information that is necessarily leaked. But let me just point out the context in which we are having this conversation: LinkedIn offered such a service, as does Facebook - both have suffered breaches. While that isn't how they made their money, plenty of people used the service - following the letter of your advice, if not the spirit of it.

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

#55
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...

This is the second[0] post I've read this weekend where someone preferred a file-based database system to MySQL. In the other, they explain why MySQL wouldn't be preferable to SQLite in their use case. Here, moving to flat files was faster and easier to work with, at 1/5 the total size, and being much more granular.

[0] https://news.ycombinator.com/item?id=11934826

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

#57
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

This is wrong. Using another login service might introduce all sorts of new issues, a big one is privacy.

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

#58

Earlier quoted context omitted.

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

This is the second[0] post I've read this weekend where someone preferred a file-based database system to MySQL. In the other, they explain why MySQL wouldn't be preferable to SQLite in their use case. Here, moving to flat files was faster and easier to work with, at 1/5 the total size, and being much more granular. [0] https://news.ycombinator.com/item?id=11934826

They essentially built an ad-hoc database complete with sequential keys and indexing. I'm curious to see what the resulting performance would be if they used a database that's appropriate for the type of data they have. I'm not familiar with non-relational databases but I suspect that a key-value or document store would work very well.

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

#59
post #30
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…

> There is no reason to be using anything less than [Argon2, bcrypt or scrypt] and continued use is in my mind negligence. PBKDF2 is fine too.

PBKDF2 is not for password storage.

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

#60
post #51
post #29

Earlier quoted context omitted.

What are the advantages of bcrypt compared to SHA based hashes with unique salts?

bcrypt is significantly slower to compute. Something like 5 or 6 orders of magnitude slower. (se my other comment in here with numbers for cracking various hash types on an 8gpu rig...)

Can I achieve the same by applying SHA x times?
Post reply on HN