We may discuss about proper authentication mechanisms here, but I guess the real lesson learned is "don't gather data if you really don't need to".
Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
71–79 of 79 posts
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#72I 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
I looked at one where you would twiddle the bytes on filesystem, but this was easier. Fire and forget until the results are in.
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#73Pretty good writeup. My takeaway is that it's more important to use a long password than to mix and match letters/digits/special characters if that's the choice you have (since the cracking process is greedy and going from short to long not from low entropy to high entropy...for lack of a better description). Would that be a correct assumption?
Just to pose a silly example...take a password of 300x"x" (maybe turn the 42nd into an "o" for good measure)...since many attacks probably won't enumerate that many characters before they reached a sufficient mass of cracked PWs that would be reasonably safe even though it is kind of a silly PW, right?
Edit: no need to do that in practice since you can just use a randomly generated PW with a PW safe but maybe there's a case where you need to remember the PW just in case.
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#74If 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.
I think my question is still valid no matter what crypt function you use. Why can't you just stack it N times to make it N times harder to compute?
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#75Any 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.
How is this better than double salted sha256. I.e sha256("secret", sha256("secret2", $pwd))
The double sha/md5 would even give rainbow tables a super hard time right?
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#76Earlier quoted context omitted.
Use scrypt or bcrypt: both are computationally expensive by design. Both are largely unapproachable on GPUs and ASICs.
I think my question is still valid no matter what crypt function you use. Why can't you just stack it N times to make it N times harder to compute?
In general, you can. Just remember that you are stacking it N times on a CPU and, depending on the function, there is hardware that can do it more efficiently than a CPU: you're technically inconveniencing yourself more (in comparison to a hacker) by using a cheap function. You're going to gain a lot more by using a function built for high computational cost from the outset.
Furthermore,
> It can be shown that the repeated hashing reduces the space of possible values, but should reach an inner "cycle" of size roughly sqrt(N) if the hash output values are in a space of size N[1]
Using the correct type of function just makes more sense.
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#77Earlier 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.
How is this better than double salted sha256. I.e sha256("secret", sha256("secret2", $pwd)) The double sha/md5 would even give rainbow tables a super hard time right?
> How is this better than double salted sha256. I.e sha256("secret", sha256("secret2", $pwd))
ITYM hmac-sha256("secret", hmac-sha256("secret2", $pwd)), but that's neither here nor there; the operation requires either two (your version) or four (my HMAC version) SHA256 operations, which really isn't much: your version would make an exhaustive password search twice as expensive; mine would make it four times as expensive. Neither is very much.
Note too that salts are not secret; they must be stored with the password.
> The double sha/md5 would even give rainbow tables a super hard time right?
If you're using even a single high-entropy salt, a rainbow table is useless. What's not useless is just trying lots and lots and lots of potential passwords: first sha256("salt", sha256("salt2", "12345")), then sha256("salt", sha256("salt2", "hunter2")), then sha256("salt", sha256("salt2", "opensesame")), then sha256("salt", sha256("salt2", "love")) and on and on and on.
'But that will take forever!' you might cry. Not really: the article noted a 209.7 million hashes per second rate. At that rate, one could try every possible date in a century (36,525 possibilities: lots of people use birthdays or anniversaries in passwords) in U.S., British, German, French date formats (x4) with the top 100 male and female names prepended and appended (x400: 100 each, before & after), with and without spaces between (x2) in approximately half a second. If one adopted your approach, it'd slow it down to just over a second; under my approach, it'd be 2¼ seconds. Not very good.
PBKDF2, bcrypt, scrypt & Argon2 all attempt to slow this down by not requiring one or two or four hash operations, but rather by requiring thousands or hundreds of thousands of operations. scrypt goes even further by requiring lots of memory access, since memory access is slow on GPUs while just hashing is very expensive. Argon2 goes even further still.
Under any of the above, it might require a full second on even a GPU cluster to verify a password, which would mean that it'd take 3 years and 8 months to try all of those possibilities earlier. While a real-world system wouldn't be tuned to take a full second on a GPU cluster (it'd be slower on a server), it might very well be tuned to take say 10 or 100 milliseconds, which is still relatively slow for someone trying every single hash but relatively fast for validating a user login.
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#78Earlier quoted context omitted.
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…
Yep - and even in it's "ridiculously low work factor" configuration, it's around 6 orders of magnitude slower than SHA. In context, the author of that piece was trying to show off the hashrate, so would be expected to err on the side of making his monster 8 gpu rig look better rather than worse.
Any of bcrypt, scrypt, or PBKDF2 can easily (as in, by design in the hash function parameters) be made however much slower is needed for you (so long as your normal login process is then still "fast enough", I had a WordPress site a while back where I couldn't wind the bcrypt plugin up much past 11 before the inexpensive webhosting would time out before login succeeded... (And yeah, feel free to mock me for "securing" WP with bcrypt - it was mostly because I wanted to be confident if/when the site got exploited, the hashes in the DB weren't going to be too easily attackable for anyone who'd used a decent password))
Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
#79Pretty good writeup. My takeaway is that it's more important to use a long password than to mix and match letters/digits/special characters if that's the choice you have (since the cracking process is greedy and going from short to long not from low entropy to high entropy...for lack of a better description). Would that be a correct assumption? Just to pose a silly example...take a password of 300x"x" (maybe turn the…
> My takeaway is that it's more important to use a long password than to mix and match letters/digits/special characters
Yes. Trivially, if you use only two symbols (eg: "0" and "1"), a (random) password of 128 letters should be pretty safe. Note that your example of just 300 of one letter wouldn't be all that safe. In general, a good password won't really be easy to remember, because it needs to encode a lot of entropy.
More generally, you probably want log2(Nsymbols^length) >= 64, possibly => 96 (ie: equivalent to at least 64 or 96 bits of entropy). If you're using big and small letters, digits, and say ten printable symbols, every single letter (each random pick of one of the 226+10+10=72 symbols) adds roughly 6.17 bits of entropy. So you'll need at least eleven letters in your password. If you just use small letters, every character in your password adds about 4.7 bits - so to "climb over" 64 bits of entropy, you'd need at least 14 letters in your password.
Using just digits, each digit 0-9 adds about 3.32 bits, so for 64 bits you'd need a string of 20 random* digits.
To enumerate half of 2^64 passwords at 200 million tries/second, would take about 2^63/(200 000 000 * 3600 * 24 * 365) ~ 1 499 years. Clearly, if you had 3 000 machines, you could do this in about half a year - so depending on your risk profile, you might choose to aim for 96 bits: 2^95/(200 000 000 * 3600 * 24 * 365) ~ 6 439 554 927 618 years ... (That's eg: 29 random digits).