Eight RTX 4090s Can Break Passwords in Under an Hour(tomshardware.com)
tomshardware.com
Eight RTX 4090s Can Break Passwords in Under an Hour
https://www.tomshardware.com/news/eight-rtx-4090s-can-break-passwords-in-under-an-hour
3 comments
So what’s the new benchmark for safe password length? I’ve been at 24 random characters for awhile, is this too short for HashCat?
It says 300 Gh/s for NTLM and 200 kh/s for bcrypt.
There are 62^12≈10^21 12 character mixed case alphanumeric passwords. At 3*10^11 hashes/second, this would take ~3*10^9 seconds (~100 years) to brute force. For bcrypt, an 8 character password is fine (it would take ~30 years to brute force). Of course, you have no idea what hash function a breached site may have used, so best to err on the side of caution.
That said, avoiding password reuse is far more important than the strength of an individual password (not that it’s unimportant). The vast majority of breaches occur due to credential stuffing attacks on other logins, not from the initial breach itself.
There are 62^12≈10^21 12 character mixed case alphanumeric passwords. At 3*10^11 hashes/second, this would take ~3*10^9 seconds (~100 years) to brute force. For bcrypt, an 8 character password is fine (it would take ~30 years to brute force). Of course, you have no idea what hash function a breached site may have used, so best to err on the side of caution.
That said, avoiding password reuse is far more important than the strength of an individual password (not that it’s unimportant). The vast majority of breaches occur due to credential stuffing attacks on other logins, not from the initial breach itself.
The math says 12+ if randomly generated by something like a password manager and including uppercase, lowercase, numbers, and symbols. 95^12 is too big for pretty much anyone to crack for a very long time, if ever. There is a small caveat to this regarding what type of hashing is being used though. In nearly all cases, even in the case of relatively weak hashes, 12+ is enough, but there are hashes which truncate or break up inputs. Windows LanMan(LM) is probably the most common offender still seen these days that does this and any LM will always be breakable up to 14 characters due to its underlying algorithm leading to a weak separation of 7 + 7 characters. In the case of Windows hashing a default length of 15+ can help to avoid LM being stored but for legacy systems it may be unavoidable.
I don't think the NTLM thing of 7+7 has been true since Windows 2000 and the introduction of Active Directory.
it's been a long time, I know that.
it's been a long time, I know that.
LM is still this way, the algorithm hasn't changed, it's just not often used/stored except in the case of quite old legacy systems. NT hashes, commonly referred to as NTLM hashes, are indeed not length restricted and do not break your password up into 7 + 7 chunks.
if you're using all valid characters (numbers, punctuation, upper and lowercase, etc) then every extra character grows the set of possible passwords exponentially, not linearly. 24 characters is a huge problem space, i don't know exactly how many possible characters there are but let's say it's 50, so that's 50^24 which is 41 digit number, a number so big I don't know what to call it and still in the realm of a password that would take so long to crack you would die before it was finished cracking.
50^24 is roughly 59.6 duodecillion, if you were curious.
There is no mention of how long those passwords are so for me this is clickbait
Article: "The researchers estimate that a purpose-built password hashing rig (pairing eight RTX 4090 GPUs) could crack an eight-character password in 48 minutes."
For further clarity, this is for NTLM hashes. And the entire article is indeed clickbait and considering the numbers they're referencing, they likely came from this tweet [1] which the article doesn't link as a source at all.
[1] https://twitter.com/tinkersec/status/1580722789245280257
[1] https://twitter.com/tinkersec/status/1580722789245280257
How do you fix this? Quite easy really --- simply limit the number of unsuccessful attempts before locking the account --- either temporarily or indefinitely.
Most security focused web sites do this now.
Most security focused web sites do this now.
You're thinking of brute force attempts over the network which are very slow and as you mention should be subject to tarpits and lockouts. This is if you can get your hands on the hashed passwords; I would think a GPU cluster can do something from millions to trillions of attempts per second depending on the algorithm.
Here is my hashed password: Gx5jp2z8,h
Let me know when it has been succesfully decrypted. Or better yet, explain how you can possibly know if a decryption is succesful except by testing it.
You can make 10 test attempts before you're locked out for 1 hour. Another 10 attempts before the account is locked indefinitely.
The number of attempts per second your GPU cluster can make is no longer relevant.
Let me know when it has been succesfully decrypted. Or better yet, explain how you can possibly know if a decryption is succesful except by testing it.
You can make 10 test attempts before you're locked out for 1 hour. Another 10 attempts before the account is locked indefinitely.
The number of attempts per second your GPU cluster can make is no longer relevant.
You are still not understanding how these offline attacks work.
Assuming that was a hashed password (it is not), the way that these boxes crack it is they hash all possible passwords and test the resulting hash to see if it matches your hash. When they find an input that matches your hash, they have "decrypted your password".
What an offline attack does not do, which is where you are mixed up, is try to log into Facebook/Twitter/etc. over and over trying different possible passwords. Some other security breach reveals the stored hashes of user passwords, and that stolen list of password hashes is what gets run through these systems.
Then, when they find a batch of inputs that hash to some of the stolen hashes, then they start trying those both at the site of the breach, and at other sites, often to great success, because they never trip the "10 test attempts" (they have an input that works, first time) and due to the all too common reuse, learning a users craigslist (for example) password is often enough to gain access to their gmail account.
Assuming that was a hashed password (it is not), the way that these boxes crack it is they hash all possible passwords and test the resulting hash to see if it matches your hash. When they find an input that matches your hash, they have "decrypted your password".
What an offline attack does not do, which is where you are mixed up, is try to log into Facebook/Twitter/etc. over and over trying different possible passwords. Some other security breach reveals the stored hashes of user passwords, and that stolen list of password hashes is what gets run through these systems.
Then, when they find a batch of inputs that hash to some of the stolen hashes, then they start trying those both at the site of the breach, and at other sites, often to great success, because they never trip the "10 test attempts" (they have an input that works, first time) and due to the all too common reuse, learning a users craigslist (for example) password is often enough to gain access to their gmail account.
> they hash all possible passwords and test the resulting hash to see if it matches your hash.
This is the key thing to remember. There is no requirement that the password cracker needs to find exactly the same thing you would type for your password, they only need to find an input that has the same hash as your password. You can think of it like an alternate password; there won’t be any way for the site to distinguish between the real password and the alternate(s).
They key to a good hash algorithm for passwords is to make collisions rare (this is accomplished by making the hash longer than the average password; the more bits there are in the hash the rarer collisions will be) and to take a long time to compute (usually by adding rounds to force the attacker to take more time on each input).
This is the key thing to remember. There is no requirement that the password cracker needs to find exactly the same thing you would type for your password, they only need to find an input that has the same hash as your password. You can think of it like an alternate password; there won’t be any way for the site to distinguish between the real password and the alternate(s).
They key to a good hash algorithm for passwords is to make collisions rare (this is accomplished by making the hash longer than the average password; the more bits there are in the hash the rarer collisions will be) and to take a long time to compute (usually by adding rounds to force the attacker to take more time on each input).
When they find an input that matches your hash, they have "decrypted your password".
So correct me if I'm wrong but in order for this to work, the cracker will need both my hashed password AND the hash algorithm that was used AND any salt that was used for the hash.
Why does he need to crack anything --- it sounds like he already has full access to my system?
So correct me if I'm wrong but in order for this to work, the cracker will need both my hashed password AND the hash algorithm that was used AND any salt that was used for the hash.
Why does he need to crack anything --- it sounds like he already has full access to my system?
If by "your system" you mean the one PC upon which you are typing your comments right now, the provided you have used a unique password for that system, and only that system, then yes, by the time they have the hash and salt, they've already gained access.
That's a targeted attack, and that is usually not the direction these GPU Hashcat rigs are aimed.
Instead the attacker is merely playing the odds. Those odds being that a rather good number of users of system X (gmail, for example) will reuse their gmail password at another website (Experian, for example).
So they will target that other website (Experian) and when they find a breach, will hoover out the user names, password hashes, salts, and will know the algorithm Experian used (because somewhere in the data trove they hoovered up, the algorithm was indicated).
They will then set their GPU Hashcat rig upon the Experian breach data, looking for input strings that hash to stored hashes from their data. They don't care which individuals, they care that they will find working password inputs for, say, 15% of their breach data. If their experian dataset was for 50M users, a 15% success rate gives them 7.5M pairs to use further.
Then, armed with user names and working passwords from their Experian breach data they set out trying those users and passwords against gmail. They don't trip any "ten tries and you are out" traps because they only do one try per cracked user/password pair. It the user/password pair fails they simply move on to the next user/password pair. But, if the user/password pair works, then they have now breached someone's gmail account, and can now set out about taking over their other accounts (because gmail is often their recovery email for those other accounts). Some of those other accounts will be the crackers real target, those userss banking/financial accounts.
But the crackers don't care who they are targeting, just that 15% of their Experian data will yield useful pairs, and that 15% of those pairs will work when tested on gmail (15% of 7.5M is 1.125M working gmail accounts they can take over). And that 15% of the gmail accounts they breach will have banking/financial accounts they can do a password reset upon (15% of 1.125M 168,750 users). And even if each user yields merely an average of $1k, that works out to a very nice take of $168M for the crackers.
That's a targeted attack, and that is usually not the direction these GPU Hashcat rigs are aimed.
Instead the attacker is merely playing the odds. Those odds being that a rather good number of users of system X (gmail, for example) will reuse their gmail password at another website (Experian, for example).
So they will target that other website (Experian) and when they find a breach, will hoover out the user names, password hashes, salts, and will know the algorithm Experian used (because somewhere in the data trove they hoovered up, the algorithm was indicated).
They will then set their GPU Hashcat rig upon the Experian breach data, looking for input strings that hash to stored hashes from their data. They don't care which individuals, they care that they will find working password inputs for, say, 15% of their breach data. If their experian dataset was for 50M users, a 15% success rate gives them 7.5M pairs to use further.
Then, armed with user names and working passwords from their Experian breach data they set out trying those users and passwords against gmail. They don't trip any "ten tries and you are out" traps because they only do one try per cracked user/password pair. It the user/password pair fails they simply move on to the next user/password pair. But, if the user/password pair works, then they have now breached someone's gmail account, and can now set out about taking over their other accounts (because gmail is often their recovery email for those other accounts). Some of those other accounts will be the crackers real target, those userss banking/financial accounts.
But the crackers don't care who they are targeting, just that 15% of their Experian data will yield useful pairs, and that 15% of those pairs will work when tested on gmail (15% of 7.5M is 1.125M working gmail accounts they can take over). And that 15% of the gmail accounts they breach will have banking/financial accounts they can do a password reset upon (15% of 1.125M 168,750 users). And even if each user yields merely an average of $1k, that works out to a very nice take of $168M for the crackers.
Usually a hash has certain identifiers that allow you to identify the type and whether it has a salt.
For example, the bcrypt12 hash of the sentence "You're not getting the point"looks like this:
$2y$12$KXbMZhAsPe0z/SpMq2s8t.CtTod.DO3wvzdaJ8OKksTMm02AnCc4K
And an MD5 hash looks like this:
b508398861f7a6df90dd1b909b3dd998
A SHA-1 hash looks like this:
570df4d6bdb79757194b0e6d27d27cc35b3e8c96
> Why does he need to crack anything --- it sounds like he already has full access to my system?
They're not interested in access ingredients. They usually either break into a company's systems and extract the hashed and (hopefully) salted passwords or buy a hashed password dumb from places like breached.to or cracked.to, and formerly raidforums.com.
They don't need access to your computer. They want to get access to as many valuable websites as possible and sell those account or (in rare cases) extract personal information such as Credit Card details or PII used to impersonate you.
For example, the bcrypt12 hash of the sentence "You're not getting the point"looks like this:
$2y$12$KXbMZhAsPe0z/SpMq2s8t.CtTod.DO3wvzdaJ8OKksTMm02AnCc4K
And an MD5 hash looks like this:
b508398861f7a6df90dd1b909b3dd998
A SHA-1 hash looks like this:
570df4d6bdb79757194b0e6d27d27cc35b3e8c96
> Why does he need to crack anything --- it sounds like he already has full access to my system?
They're not interested in access ingredients. They usually either break into a company's systems and extract the hashed and (hopefully) salted passwords or buy a hashed password dumb from places like breached.to or cracked.to, and formerly raidforums.com.
They don't need access to your computer. They want to get access to as many valuable websites as possible and sell those account or (in rare cases) extract personal information such as Credit Card details or PII used to impersonate you.
There’s multiple inputs that can get the same hash. Say if your hashed password was 7, and that came from 2+5. Someone bruteforcing can input 6+1 and get 7, also. They don’t need to know what your input was, they just need to find an input that hashes to match the hash of yours.
That's an entirely different threat model. hotpotamus is right - the article, and the threat model, are about offline attack of back-end password hashes, after they've been stolen or leaked. The speeds against fast hashes are indeed measured in the billions or trillions on ordinary commodity hardware.
Further, password hashes are not "decrypted" - they are cracked, because it's not reversing anything - https://www.techsolvency.com/passwords/dehashing-reversing-d... (disclaimer: my explainer)
Further, password hashes are not "decrypted" - they are cracked, because it's not reversing anything - https://www.techsolvency.com/passwords/dehashing-reversing-d... (disclaimer: my explainer)
hunter2