Naive question: how is brute-force cracking still a thing in real-world systems? Aren’t there time-outs/bans for guessing wrong after like 3-5 guesses? How does one get the opportunity to try millions/billions/etc of times?
Databases get dumped, well, not all the time, but fairly often. See haveibeenpwned for example, they post a new breach once a week, if not more often [0].
HIBP even is basically tip of the iceberg in terms of how much data is floating around - Troy and his team only get the ones that are publicly leaked, or privately shared with them.
They also have historically had a backlog of data to process - leaked databases can be a pain to parse and turn into something usable.
Well if not setup properly, it is possible to dump the Windows password hashes (and linux too).
You take that list of hashes, and copy to your password cracking rig, where it can run for a few days to see how many password hashes you can find a match for. Then once you have identified a password hash match, you now know an account password.
However, if things aren’t properly secured where an attacker can dump password hashes, they likely can utilize “pass the hash” style attacks as well where you don’t even need to know the password to be able to sign in as a user.
Windows networks are notoriously bad about this. If you find yourself on a Windows network, either because you found an active ethernet jack in the lobby, or you get on the wifi, phishing, or you land on a citrix box or whatever, you can run a tool called Responder.
Windows machines on a network are constantly scanning around, looking for new devices, and when they find them, they like to see if they can access them so they show up in network manager or whatever. They do this by trying to log in. Obviously logging in with a password would be insecure, so they try to log in with a hash. Responder pretends to be any sort of server that a Windows machine would try to log in to, so right when you run it, all the nearby machines hand over their hashes.
Crack even one of those hashes, and now you can log in to Active Directory. This will let you get the full list of all users, permissions, groups, machines, and sessions, etc, and basically tell you exactly what you need to do to get anywhere you want (Bloodhound is the main tool people use for this).
That AD account also lets you dump all the SPNs (service accounts) on the network, and because Windows is Windows, of course that gives you something like 20-30 password hashes, many of which are almost certainly Domain Admins on the network.
Crack a Domain Admin account, and you can basically do whatever you want on the network, including doing a dcsync, which is normally used to back up a domain controller, but also dumps every account and NTLM hash straight into your lap. These hashes can be used with pass-the-hash to impersonate any account, or you can just crack them and basically have free access to the network for the rest of your life.
The entire security of Windows networks is based on the premise that password crackers don't exist, which is why they have been fundamentally fucked for decades, and there's zero chance that any of this will ever get fixed.
What you generally feed into password cracking software is hashes of passwords that you've found by listening on the network, dumping from memory, or obtained by chaining another vulnerability.
These are in a text file locally (offline), so there is no system that you are submitting hashes to for verification. It simply tries md5(your_password_guess) until it computes the same hash that you supplied.
This is oversimplified and you can replace md5 with any hash alg that you need, but i hope it makes it clear that guesses don't happen against the auth server.
You don't need to do this online in many cases. For instance, the hash of WPA-secured Wi-Fi networks can be captured during the handshake of other devices.
This is for cracking password _hashes_. Most websites won't store a user's plain-text password but will only store the hash of it. Then a hack/exploit might later reveal the website's password hashes. This program helps you turn the hash back into the original password. Assuming you have a hash already, you own the hash, so it's not possible for anyone to impose a rate limit on how quickly you can attempt to break it.
Offline vs online brute forcing, as I like to call it.
As others have said, if you have the hashes, you can brute force them offline and there won't be any limits on how fast it can go besides your algorithms and compute resources.
But even online, attackers can be pretty smart. For example, something we detected was an attacker rotating both through a bunch of accounts and a bunch of IP addresses. That way you never saw many incorrect login tries per account and IP in a timeframe. It's not millions/billions of tries, but it can get around naive limits per IP or per account and you need some SIEM tooling to detect that.
Modern KDF algorithms are designed to guard against offline attacks by massively increasing the cost per hash. Online or offline, brute forcing shouldn't be an issue nowadays.
Saying "there's no limit besides your resources" is basically saying "there's no limit besides the very real and insurmountable limit there is".
Yeah, I fell into my usual security questionaire wording there.
I'm not even contradicting you there. You can go as fast as you can go. Even if every atom in the current estimation of the universe had a couple thousand computations available, we couldn't brute-force some passwords. Except, now customer security asks you "but what about millions of computations per atom? Checkmate!".
Being too concrete and absolute with these kinds of people ends up with so many stupid discussions.
This is true, it's just that, with modern KDFs, that's still too slow to matter (unless someone broke them and we don't know). If you use a modern KDF, you basically don't have to worry about brute forcing at all, even for fairly weak passwords.
I know that. You're missing the second part there.
I have been asked by customers about the reliability of our software platform if major german cities have been hit with either nuclear, natural or military disaster. It's that level of silly you sometimes have to deal with.
Eventually I got fed up enough and told those kinda people that I'm volunteering in disaster prevention services and their systems wouldn't be my problem at that point.
I found the comments regarding checking your power supply quite interesting - I guess in Europe with 220V as standard we don't really need to worry about it? (Assuming your plugs aren't on a lighting ring or something silly like that)
While 230 V is now the nominal voltage everywhere, the previous 220 V has been intentionally included in the tolerance range of the voltage.
There are many places where the power stations have not been updated for many years, so 220 V remains the actual voltage that can be measured on the outlet.
I'm very wary downloading and running software on my computer in general, but I'd be even moreso with software from some unknown company providing a hacking tool.
Definitely better to do this in a VM, but then your performance would take a hit
Keep in mind 10 character spaces should be represented by the selection pool size (A-Z = 26, a-z = 26, 0-9 = 10, so 26+26+10=62). You now can say 62^10 = total possible guesses available. Certainly you can start to make intelligent decisions on guessing properties and priorities to reduce your time.
Also I didn't discuss entropy here in order to represent it more basically for the parent comment.
View the source of the pdf, find the trailer dictionary (ctrl-f "/Encrypt"), and note the object number of the encryption dictionary. An example trailer below, here the encryption dictionary happens to be object ID 94,0
% Trailer dictionary
trailer
<<
/Size 95 % number of objects in the file
/Root 93 0 R % the page tree is object ID (93,0)
/Encrypt 94 0 R % the encryption dict is object ID (94,0)
/ID [<1cf5...>] % an arbitrary file identifier
>>
Use the object id to find the encryption dictionary:
Ah, that's the exception to my "generally" comment. That "/CFM /AESV2" means AES-128, instead of the much weaker RC4...which would be if you saw "/CFM /V2".
So you're left with brute force or dictionary attacks for your 10 char A-Za-z0-9 password.
Also, is the password completely random? If it's not, you'd have a much easier time using a large dictionary rather than every possible 10-character word.
As in the article, it looks like on a consumer GPU you'd get on the order of 10MH/s, or 10 million hashes per second. I need someone to check my math on this, but 36**10/10_000_000 GPU-seconds (36 characters, optimistically assuming [a-z0-9] lowercase) is about 4000 GPU-days, so out of reach. The A100 attempt from the article only made it about 15x faster, so you'd still need to wait a few months at best. (This is with the assumption you know it's pure lowercase.)
tl;dr it's about building a rig and playing with it, and totally not about any novel password cracking methodologies for 2024 (which are IMO more important that hardware).
I just read that Facebook is going to have 600 000 units of Nvidia H100 class GPUs by the end of year. What does that kind of processing power do for password cracking?
Think what if NSA could order FB to run their infrastructure for one hour? How long passwords would need to be to still resist this?
Given that some countries/nations now have access to 150-500+ superfast Nvidia cards, what kind of processing power (cpu/gpu) does the NSA have? Have they placed similar orders at Nvidia?
Their chips aren't any better, in fact they're probably quite a few generations behind what's available commercially due to various certification requirements etc. HOWEVER, last I checked, their budget for this sort of thing was 11 billion dollars a year, and that's where their advantage lies. Their chips are designed to be maximally power performant for the tasks they're doing, and they have a fuckton of them.
We have no reason to believe you. However, there is one party who really benefits from people considering all encryption weak and all cryptography broken: the NSA.
It's not that cryptography is "weak" or "broken", but people should be aware that (except from God Himself), there is also a purely human instance you cannot hide from...
Remember the "We have it all", pronounced by "45"? Maybe he simply told a FACT?
I'm curious if someone could comment on something. If a bunch of strings, let's say email address, are concatenated with a single, secret 128bit string, and then the resulting concatenation is hashed. Let's say sha256.
Is something like this safe against the kind of rigs and attacks being built in 2024?
You can assume the hashes are publicly downloadable, but the secret remains secret.
EDIT: Thanks for the replies. The use case is that I made a commenting system that accepts submissions via email. However, it's only being used by my personal website right now, because I'm gathering feedback on it. You can see it at https://r3ply.com. Two things to protect are privacy of commentators, and to prevent tampering of the subject line. I had plans to use an HMAC, but right now I just naively sha256(message+pepper).
The standard answer is “use bcrypt and don’t try to roll your own”
Example when you say concatenation, do you mean hash(email + secret) or hash(secret + email)? The choice matters: off the top of my head, I know the former lets an attacker reuse state between hashing attempts if the emails are known because hashing occurs one block at a time, so knowing. I wouldn’t be surprised if the later had weaknesses too.
Keep in mind most emails appear in public databases, so it’s not clear what you’re trying to protect.
true. SHA-256 is vulnerable to length extension attacks because it uses Merkle–Damgård. one reason to consider SHA-3 which is a sponge. except not for password hashing because that requires a resource-intensive function like Argon2
Not sure what's your use-case and threat model, but HKDF is likely what you want, the concatenation is done in a way to prevent attacks:
https://www.rfc-editor.org/rfc/rfc5869
An attacker in a position to grab password hashes is also going to be in a position to grab that secret. No matter how you shuffle and try to hide it, there's not really a way around that.
I meant, for the purpose of my threat model, I am not concerned with defending against attacks on the secret and we can just assume the storage of it is safe or out of scope, whichever interpretation you prefer.
But your system is relying on sha256 providing a guarantee that it wasn't designed to provide. It's better to only rely on dependencies in ways they actually were designed for.
Cybersecurity is a large set of security concerns and password strength is only one of them. This is mostly a solved problem and a minor consideration when store the passwords correctly on the backend (https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor..., have reasonable password restrictions (16 characters, no complexity, changes once or twice a year "just in case"), ideally a basic checker when people set their passwords (against a leaked passwords db such as rockyou) and correct identity management (especially disabling an account when the user leaves).
There is really nothing exciting in that part of cybersecurity and with the above in place you are safe and can move towards the real risks. Online password cracking does not matter in practical terms and for offline one you have other problems to urgently address.
What are these risks depends on who you are but if you address aggressive, stubborn and coercive patching + development security (if you develop) + enthusiastic awareness you are ahead of 99% of the world already.
Add to this some endpoint protection and monitoring of the events and, man, you are a company I can trust my HN rep.
> “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
They also don't recommend having rules about like, a certain number of symbols, etc.
You should not require users to change their passwords periodically, as this will piss them off and make them use many weak passwords rather than one strong password. Only require a password change when there is reason to believe their old password has been compromised.
To explain the other side of the comment, "cargo cult security" refers to some groups of tribal people in New Guinea who build giant wooden airplanes and control towers in the hopes of attracting airplanes delivering food[1][2].
It's very common in the security space for people who have zero understanding of underlying security models to build elaborate structures that kind of look like and feel like they're doing security, but it's actually providing no value. These practices get blindly passed on for decades despite all the best effort of actual experts to explain to them why the practices are, in fact, completely useless. Password rotation is a mindbogglingly persistent one, as described in the other comment.
It says right in the intro that the goal is part of penetration testing, which is about far more than just your web app. The target is typically to compromise the central IDM (e.g. Active Directory) get the password database which contains hashed passwords, then crack those to allow further movement or escalation around a network. This could happen via a vulnerability that allows a normal user to get the database, and then cracking the admin password from there.
So many people these days seem to completely forget that not everything is in the cloud, and there are many services in a company that you don’t see as a regular user or developer.
70 comments
[ 3.4 ms ] story [ 94.9 ms ] thread[0] https://feeds.feedburner.com/HaveIBeenPwnedLatestBreaches
They also have historically had a backlog of data to process - leaked databases can be a pain to parse and turn into something usable.
You take that list of hashes, and copy to your password cracking rig, where it can run for a few days to see how many password hashes you can find a match for. Then once you have identified a password hash match, you now know an account password.
However, if things aren’t properly secured where an attacker can dump password hashes, they likely can utilize “pass the hash” style attacks as well where you don’t even need to know the password to be able to sign in as a user.
Windows machines on a network are constantly scanning around, looking for new devices, and when they find them, they like to see if they can access them so they show up in network manager or whatever. They do this by trying to log in. Obviously logging in with a password would be insecure, so they try to log in with a hash. Responder pretends to be any sort of server that a Windows machine would try to log in to, so right when you run it, all the nearby machines hand over their hashes.
Crack even one of those hashes, and now you can log in to Active Directory. This will let you get the full list of all users, permissions, groups, machines, and sessions, etc, and basically tell you exactly what you need to do to get anywhere you want (Bloodhound is the main tool people use for this).
That AD account also lets you dump all the SPNs (service accounts) on the network, and because Windows is Windows, of course that gives you something like 20-30 password hashes, many of which are almost certainly Domain Admins on the network.
Crack a Domain Admin account, and you can basically do whatever you want on the network, including doing a dcsync, which is normally used to back up a domain controller, but also dumps every account and NTLM hash straight into your lap. These hashes can be used with pass-the-hash to impersonate any account, or you can just crack them and basically have free access to the network for the rest of your life.
The entire security of Windows networks is based on the premise that password crackers don't exist, which is why they have been fundamentally fucked for decades, and there's zero chance that any of this will ever get fixed.
These are in a text file locally (offline), so there is no system that you are submitting hashes to for verification. It simply tries md5(your_password_guess) until it computes the same hash that you supplied.
This is oversimplified and you can replace md5 with any hash alg that you need, but i hope it makes it clear that guesses don't happen against the auth server.
As others have said, if you have the hashes, you can brute force them offline and there won't be any limits on how fast it can go besides your algorithms and compute resources.
But even online, attackers can be pretty smart. For example, something we detected was an attacker rotating both through a bunch of accounts and a bunch of IP addresses. That way you never saw many incorrect login tries per account and IP in a timeframe. It's not millions/billions of tries, but it can get around naive limits per IP or per account and you need some SIEM tooling to detect that.
Saying "there's no limit besides your resources" is basically saying "there's no limit besides the very real and insurmountable limit there is".
Plus, nowadays, most (all?) big frameworks have used KDFs by default for years.
I'm not even contradicting you there. You can go as fast as you can go. Even if every atom in the current estimation of the universe had a couple thousand computations available, we couldn't brute-force some passwords. Except, now customer security asks you "but what about millions of computations per atom? Checkmate!".
Being too concrete and absolute with these kinds of people ends up with so many stupid discussions.
This is true, it's just that, with modern KDFs, that's still too slow to matter (unless someone broke them and we don't know). If you use a modern KDF, you basically don't have to worry about brute forcing at all, even for fairly weak passwords.
I have been asked by customers about the reliability of our software platform if major german cities have been hit with either nuclear, natural or military disaster. It's that level of silly you sometimes have to deal with.
Eventually I got fed up enough and told those kinda people that I'm volunteering in disaster prevention services and their systems wouldn't be my problem at that point.
Fwiw; Europe did standardize on 230V back in 1992. 220V hasn't been used in a generation or so.
There are many places where the power stations have not been updated for many years, so 220 V remains the actual voltage that can be measured on the outlet.
I once had a blade server chassis delivered with a cable for this.
Are there legit services offering brute-force cracking? How long would it take, and how much it would it cost?
Definitely better to do this in a VM, but then your performance would take a hit
[0] https://security.stackexchange.com/questions/61346/how-long-...
Also I didn't discuss entropy here in order to represent it more basically for the parent comment.
More info on the values of /V and /R here: https://qpdf.readthedocs.io/en/stable/encryption.html
So you're left with brute force or dictionary attacks for your 10 char A-Za-z0-9 password.
Also, is the password completely random? If it's not, you'd have a much easier time using a large dictionary rather than every possible 10-character word.
As in the article, it looks like on a consumer GPU you'd get on the order of 10MH/s, or 10 million hashes per second. I need someone to check my math on this, but 36**10/10_000_000 GPU-seconds (36 characters, optimistically assuming [a-z0-9] lowercase) is about 4000 GPU-days, so out of reach. The A100 attempt from the article only made it about 15x faster, so you'd still need to wait a few months at best. (This is with the assumption you know it's pure lowercase.)
Can someone confirm my math on this?
Think what if NSA could order FB to run their infrastructure for one hour? How long passwords would need to be to still resist this?
And there is also Space Force. They can crack EVERYTHING.
Of course I cannot prove this, but I trust my sources. Will not tell here.
It's not that cryptography is "weak" or "broken", but people should be aware that (except from God Himself), there is also a purely human instance you cannot hide from...
Remember the "We have it all", pronounced by "45"? Maybe he simply told a FACT?
Is something like this safe against the kind of rigs and attacks being built in 2024?
You can assume the hashes are publicly downloadable, but the secret remains secret.
EDIT: Thanks for the replies. The use case is that I made a commenting system that accepts submissions via email. However, it's only being used by my personal website right now, because I'm gathering feedback on it. You can see it at https://r3ply.com. Two things to protect are privacy of commentators, and to prevent tampering of the subject line. I had plans to use an HMAC, but right now I just naively sha256(message+pepper).
Example when you say concatenation, do you mean hash(email + secret) or hash(secret + email)? The choice matters: off the top of my head, I know the former lets an attacker reuse state between hashing attempts if the emails are known because hashing occurs one block at a time, so knowing. I wouldn’t be surprised if the later had weaknesses too.
Keep in mind most emails appear in public databases, so it’s not clear what you’re trying to protect.
An attacker in a position to grab password hashes is also going to be in a position to grab that secret. No matter how you shuffle and try to hide it, there's not really a way around that.
But your system is relying on sha256 providing a guarantee that it wasn't designed to provide. It's better to only rely on dependencies in ways they actually were designed for.
There is really nothing exciting in that part of cybersecurity and with the above in place you are safe and can move towards the real risks. Online password cracking does not matter in practical terms and for offline one you have other problems to urgently address.
What are these risks depends on who you are but if you address aggressive, stubborn and coercive patching + development security (if you develop) + enthusiastic awareness you are ahead of 99% of the world already.
Add to this some endpoint protection and monitoring of the events and, man, you are a company I can trust my HN rep.
Please stop cargo culting this.
> “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
They also don't recommend having rules about like, a certain number of symbols, etc.
https://pages.nist.gov/800-63-FAQ/#q-b05
To explain the other side of the comment, "cargo cult security" refers to some groups of tribal people in New Guinea who build giant wooden airplanes and control towers in the hopes of attracting airplanes delivering food[1][2].
It's very common in the security space for people who have zero understanding of underlying security models to build elaborate structures that kind of look like and feel like they're doing security, but it's actually providing no value. These practices get blindly passed on for decades despite all the best effort of actual experts to explain to them why the practices are, in fact, completely useless. Password rotation is a mindbogglingly persistent one, as described in the other comment.
[1] https://www.youtube.com/watch?v=qmlYe2KS0-Y
[2] https://en.wikipedia.org/wiki/Cargo_cult
So many people these days seem to completely forget that not everything is in the cloud, and there are many services in a company that you don’t see as a regular user or developer.