“correcthorsebatterystaple” is guessed in less than 0.01 seconds
twitter.com
twitter.com
He seems to have taken this bit from the linked article:
"In 2013, Bitcoin miners collectively performed ≈ 2⁷⁵ SHA-256 hashes"
and divided by the number of seconds in a year to figure out how long how many SHA-256 hashes can be calculated per second. But that's all of the Bitcoin miners in the world (in 2013, but still).
Anyway, use a password manager and don't reuse passwords and this is all moot.
When it's yours, don't fuck it up.
No, the US Government isn't going to build a supercomputing cluster to crack "correcthorsebatterystaple", and if they did, you're screwed anyway.
I'm using four games that I happened to have stacked on top of each other at the time. Most are not even in the dictionary, yet it's very easy to remember for me.
I realise that with this hint, I'm making the password a lot easier to crack.
The number of CPUs dedicated to Bitcoin mining must be in the hundreds of millions.
1000 guesses per second * 100 million CPUs... good luck with your linear work factor KDF protecting your short password.
It's like security through obscurity. Operationally it may have value, but you don't premise your security on such an approach.
Relying on a cost factor-based KDF is like relying on the grizzled machine engineer in the basement who keeps things humming along with wire and duct tape. Great if it works for you, but it's ridiculous to sit down at a table among engineers discussing design elements and say, "Hey, this is a crappy and fundamentally broken design, but I got guy who might be able to make it work for a little while."
Imagine if we "fixed" TLS AES-CBC or similar probabilistic active MITM leaks by simply running the AES-CBC cipher a few thousand additional times over each block, reducing the rate at which an attacker could iteratively reveal the plain text by rate-limiting throughput at the ends. It'd be a ludicrous proposal. Yet that's exactly what cost factor-based KDFs do.
On the other hand a password consisting of 8 * 7 bit characters is 2 ^ 56, or about 7.2e16 choices.
So it ends up being only a factor of 2 larger than 8 character ascii passwords.
If you end up choosing words in the most popular 1_000 english words, it's 1e12 total choices. I postulate that it's possible to create an algorithm that will search words by popularity so "cat-dog-house-street" will be found much much faster than "zephyr-quasar-fricasee-parabola"
It's not wrong to use. Its wrong to codify it or enact it as policy because what a corporate security goons published "password requirements" is really just "search space reducers" For example; not wasting my time on guesses below the 8 char minimum. Thanks security guy, that saved a BUNCH of time!
No it didn’t. I saved a ridiculously negligible amount of time to attackers while preventing users to pick really weak passwords.
No it doesn't. And that's a really important point on while length matters for complexity. Assuming upper case, lower case, digits and symbols it takes ~1% of your time to try all of the passwords of length 1-7 chars as it does to try only the passwords of exactly 8 chars.
In practice few people are going to remember how to spell words like "aceanthrenequinone" correctly so the practical dictionary size is a lot smaller, but still in the tens of thousands of possible words. The xkcd comic says 44 bits for a 4-word combination of common words.
a) the words are correctly spelled
b) you're only using words from macOS's /usr/share/dict/words
c) there no more than 4 words
d) there's no punctuation, capitalisation or spaces
Which together produce the relatively low cracking time, and given that you generally can't know any of those things a priori you can't assume them when cracking a password
Edit: As was pointed out, it's strictly having more than 4 words that helps the most with increasing entropy, whereas allowing less than 4 words in the problem space is mostly a rounding error.
Going from "4 words" to "4 words or less" is absolutely negligible for sufficiently large words list. For example, if you take a dictionary of just 3000 words, then "4 words" is 46.20299 bits of entropy while "4 words or less" is 46.20346 bits of entropy. The larger the dictionary, the worse the effect becomes.
>>> math.factorial(4)
24
>>> math.factorial(6)
720
So the password iamahorsebatterystaple is about 30x harder to crack than correcthorsebatterystaple using this approach, and I highly doubt people doing xkcd passwords are strictly sticking to 4 words
You are massively underselling it. It’s n² harder with n being the number of words in your dictionary.
(except that "iam" is certainly not two random words)
But my point was that varying the number of words virtually doesn't add security — the security of this scheme is defined by the number of words in the dictionary, and the maximum number of words you’re willing to remember. Whether that maximum means "pick MAX words" or "pick at most MAX words" has no real impact.
Common names, etc would IMO be very frequent compared to a foreign loan word, like samovar.
So once the rules are lax for password choice, the crack patterns are again julieisborninjuly or what not and the weak users are back in a very small search space.
lobste.rs at my-username .dev