score // how crackable is it

password strength isn't a vibe

people talk about passwords like strength is a feeling. "this one feels strong." "add an exclamation point, that's spicy now." it's not a feeling, it's math. every password lives inside a search space defined by two numbers: how many possible characters you could have used, and how many characters long the password is. that search space is the character set raised to the power of the length. change either number and the size of that space explodes or collapses. this post is about understanding that math using your own hardware, so you can see exactly why "password1" dies in under a second and why length is the only variable that actually saves you.

the command, benchmarking your own gpu

hashcat -b -m 1000 | grep Speed

run this on a machine you own, ideally one with a decent gpu. here's what each piece is doing.

hashcat is a password cracking tool used by security pros to test how fast hashes can be recovered. it's legitimate, it's used in audits, and it's on every pentester's laptop for a reason.

-b tells hashcat to run its built in benchmark mode instead of actually cracking anything. no wordlist, no target hashes, just a speed test of your own hardware.

-m 1000 picks the hash mode. mode 1000 is ntlm, the hash format windows uses to store password hashes locally. it's a fast algorithm, which is exactly why it benchmarks so high and why it's a bad choice for anyone still relying on it for anything sensitive.

| grep Speed just filters the benchmark output down to the line that shows raw hashes per second, so you're not scrolling through device info you don't care about.

run it and you'll probably see a number in the billions of hashes per second if you've got a modern gpu. that number is the whole point of this post.

the actual math

search space equals character set size raised to the power of password length. an all lowercase 6 character password only pulls from 26 characters, so that's 26^6, roughly 309 million combinations. sounds like a lot until you remember your benchmark number is in the billions per second. that password is gone in under a second, sometimes literally instantly because it's probably already in a wordlist.

now bump the character set to include uppercase, numbers, and symbols, that's about 95 characters, and bump the length to 12. now you're looking at 95^12, a number so large it doesn't fit in a normal calculator display comfortably. that's the difference between "cracked before you finish reading this sentence" and "not happening with current hardware in your lifetime."

the takeaway inside the takeaway: length matters more than complexity. adding one more character to the length multiplies the search space by the full size of your character set. adding one more symbol option barely nudges it. length wins, every time.

why ntlm and why it matters for you

ntlm hashes fast on purpose, it was built for speed of authentication, not resistance to cracking. that's why -m 1000 benchmarks so high compared to something like bcrypt or argon2, which are deliberately slow and expensive to compute, sometimes thousands of times slower per guess. if you run your own systems, check what's hashing your passwords. if it's still relying on ntlm alone for anything internet facing, or storing credentials in a legacy format from a decade ago, that's your actual exposure, not the length of your users' passwords.

where the real risk lives

attackers rarely brute force from zero. they use wordlists built from breached password dumps, then apply rules, capitalize the first letter, swap a for @, tack a 1 on the end, the stuff everyone does. that shrinks the effective search space back down no matter how big your theoretical character set is. this is why "P@ssword1" feels complex but cracks instantly, it's a pattern that's already in every wordlist on earth. run hashcat against your own test hashes with a public wordlist like rockyou if you want to see this in action on your own gear.

the takeaway

run the benchmark, look at the number, then go check where your own passwords or your organization's hashes actually stand against it. use long, random, unique passwords, ideally generated and stored in a password manager, not typed from memory. move any system you control off fast legacy hashes like ntlm alone and onto slow, salted algorithms like bcrypt or argon2. length beats complexity, unpredictability beats both, and a gpu that can guess billions of times a second doesn't care how clever your substitution pattern felt when you made it up.