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

61–70 of 79 posts

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

#61

Post by OrpheanBeholder »

bigiain wrote: post #50
sgarman wrote: post #9

Earlier quoted context omitted.

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

Some of these don't make sense. The point of bcrypt, scrypt, and pbkdf2 is the difficulty of them is configurable.

Digging into the comments on that gist, it says that the bcrypt benchmark used a workfactor of 5 (= 32 rounds). The lowest possible bcrypt workfactor is 4 (= 16 rounds).

For comparison, the default for the login hashes on OpenBSD is 8 (= 256 rounds) for standard accounts and 9 (= 512 rounds) for the root account, and OpenBSD's bcrypt_pbkdf(3) function uses a workfactor of 6 (= 64 rounds) and that's intended to be called with multiple rounds itself eg. in signify(1) it uses 42 rounds (a bit over the equivalent of bcrypt with a workfactor of 11) and ssh-keygen(1) defaults to 16 (roughly equivalent to bcrypt with a workfactor of 10 (= 1024 rounds).

The point I'm trying to make here is that bcrypt benchmark uses a ridiculously low workfactor, and it looks like the scrypt and pbkdf2 ones did to.

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

#62

Post by 13of40 »

If you want to throw a wrench in a password cracker's gears, why can't you just run your 'crypt' function on its own output a thousand times in a row, so that anyone attempting to crack it will need to run it a thousand times with every candidate password? What I mean is 'crypt(crypt(crypt(p)))' should take three times as long as 'crypt(p)', right? And scale 'a thousand' to however many iterations takes one second on contemporary hardware.

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

#63

Post by [deleted] »

Matt3o12_ wrote: post #47
voycey wrote: post #43

Earlier quoted context omitted.

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

[deleted]

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

#64

Post by zamalek »

13of40 wrote: post #62

If you want to throw a wrench in a password cracker's gears, why can't you just run your 'crypt' function on its own output a thousand times in a row, so that anyone attempting to crack it will need to run it a thousand times with every candidate password? What I mean is 'crypt(crypt(crypt(p)))' should take three times as long as 'crypt(p)', right? And scale 'a thousand' to however many iterations takes one second on…

Use scrypt or bcrypt: both are computationally expensive by design. Both are largely unapproachable on GPUs and ASICs.

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

#65

Post by Ambroos »

ralala wrote: post #60
bigiain wrote: post #51

Earlier quoted context omitted.

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?

If X is millions (or even billions), maybe, but you shouldn't. Just use one of the real password algorithms. Never ever roll your own hashing system assuming it's secure enough. It won't be.

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

#66

Post by masklinn »

zamalek wrote: post #64
13of40 wrote: post #62

If you want to throw a wrench in a password cracker's gears, why can't you just run your 'crypt' function on its own output a thousand times in a row, so that anyone attempting to crack it will need to run it a thousand times with every candidate password? What I mean is 'crypt(crypt(crypt(p)))' should take three times as long as 'crypt(p)', right? And scale 'a thousand' to however many iterations takes one second on…

Use scrypt or bcrypt: both are computationally expensive by design. Both are largely unapproachable on GPUs and ASICs.

> Both are largely unapproachable on GPUs and ASICs.

Not true with respect to bcrypt. Bcrypt is not designed to be memory hard, it uses a constant and relatively small amount of memory (~4kB IIRC) which is only incrementally better than PBKDF2.

However its memory access pattern means it needs fast RAM, which is what makes GPUs inefficient for it: they have lots of memory[0] but it's slow to access from the parallel cores[1]. You can absolutely have small amounts of fast ram in FPGA and ASICs.

[0] and a good amount of memory/core, a 1080 has ~3MB/core, a 1070 has 4 (they both have 8GB RAM but the 1080 has 2560 CUDA cores versus 1920 for the 1070)

[1] GPUs have very high memory throughput but very high latencies even for caches[2] e.g. on Kepler (a few generations back) the L1 was already 48 cycles, Skylake can go up to L3 in 42 cycles

[2] which are shared by multiple cores and are very very small: from what I've found Pascal has 64KiB of L1 per SM (with each SM grouping 64 CUDA cores) and 4MB of L2 for the entire chip

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

#67

Post by masklinn »

afreak wrote: post #59
zeveb wrote: post #30

Earlier quoted context omitted.

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

PBKDF2 is absolutely for password storage. In fact RFC 2898 specifically notes that use case (for KDFs in general):

> Another approach to password-based cryptography is to construct key derivation techniques that are relatively expensive, thereby increasing the cost of exhaustive search.

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

#68

Post by zamalek »

masklinn wrote: post #66
zamalek wrote: post #64

Earlier quoted context omitted.

Use scrypt or bcrypt: both are computationally expensive by design. Both are largely unapproachable on GPUs and ASICs.

> Both are largely unapproachable on GPUs and ASICs. Not true with respect to bcrypt. Bcrypt is not designed to be memory hard, it uses a constant and relatively small amount of memory (~4kB IIRC) which is only incrementally better than PBKDF2. However its memory access pattern means it needs fast RAM, which is what makes GPUs inefficient for it: they have lots of memory[0] but it's slow to access from the parallel c…

Thanks for the correction.

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

#69

Post by ralala »

Ambroos wrote: post #65
ralala wrote: post #60

Earlier quoted context omitted.

Can I achieve the same by applying SHA x times?

If X is millions (or even billions), maybe, but you shouldn't. Just use one of the real password algorithms. Never ever roll your own hashing system assuming it's secure enough. It won't be.

Of course. I just wanted to get an idea of the reasons without going too much into mathematical details. For projects I would just use argon 2 or bcrypt.

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

#70

Post by timje1 »

afreak wrote: post #59
zeveb wrote: post #30

Earlier quoted context omitted.

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

Do you have a source for that? It was my understanding that PBKDF2 is 'good enough for now', but not necessarily the most future-proof of techs, given how easily the algorithm is optimised for GFX cards.
Post reply on HN