
“correcthorsebatterystaple” is guessed in less than 0.01 seconds - pmontra
https://mobile.twitter.com/taoeffect/status/1197576478298263553
======
aptwebapps
"How costly it is to guess SHA256 passwords:
[https://archive.is/vOn9q](https://archive.is/vOn9q) (instead of 1000
guesses/second, it's more like ~1197962070743187 guesses/second)"

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.

~~~
Semiapies
Also, don't hash passwords with fast algorithms.

~~~
lonelappde
That's not my choice to make

~~~
Semiapies
Given how many systems don't use proper password hashing algorithms, it's a
lot of peoples' choices.

When it's yours, don't fuck it up.

------
mcv
The point is of course to take 4 random words out of a very large dictionary,
not from a very small one.

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.

~~~
rebuilder
I'm too paranoid to ever discuss how I pick my passwords. :(

~~~
eesmith
Ahh, so now we know that you don't use randomly generated passwords!

~~~
rebuilder
Nice try!

------
voidmain
That is why you don't use SHA-256 (or other plain hash function, which is
designed to be _fast_ ) as a password KDF (which needs to be slow).

~~~
geogriffin
Exactly, 1000 guesses per second is probably a reasonable target to tune your
KDF's difficulty to, depending on of course the application and the amount of
resources you're willing to dedicate to running the KDF on every login..

~~~
wahern
Hackers assemble zombie clusters with hundreds of thousands of machines, if
not millions of machines, each with multiple CPUs.

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.

~~~
geogriffin
I think if my password is worth 17.5 trillion CPU seconds then I'm a very
lucky person...

~~~
wahern
That's great, but that's not how you approach security engineering.

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.

~~~
geogriffin
I see your point. Especially since cost-based KDFs rely on the predicted
characteristics of future hardware.

------
bb88
So when that kxcd article came out it became clear to me that even if you took
the most popular 30_000 english words, it was only 30_000 ^ 4 cycles to find
the password, or about 1.8e17 choices.

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"

------
geogriffin
If passphrases are easier to remember, then it may be possible for a human to
be able to recall many such passphrases at the same time. If these passphrases
are used for services with any sort of auth rate-limiting, and they aren't
reused between services, then the difficulty of reversing their hashes isn't
really a problem.

------
WheelsAtLarge
Ok I'm missing the point. I don't understand why the passphrase is wrong to
use. It seems to me that the passphrase would be hard to guess. There might be
ways to shorten the guessing but it would still years to break. How is this
wrong?

~~~
JackRabbitSlim
As one of the tweets pointed out all those words are in OSX's build in
wordlist. If you KNOW its 4 concatenated dictionary words than the speed at
which you can crack it is basically just like brute forcing a 4 digit luggage
lock.

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!

~~~
slooonz
> 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.

------
ehmish
Seems to be a number of assumptions:

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.

~~~
slooonz
> c) there are exactly 4 words

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.

~~~
ehmish
Right but if there's 6 words it goes up exponentially, even if they're short
words

>>> 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

~~~
yabadabadoes
Yeah though grammatical constructs are IMO breaking the rules and their
frequency of use would probably be added to the dictionary as compounds, iama,
youarea, thereis, .. are all more practical in a cracking dictionary than a
few more 18th century salon talk words, etc.

~~~
ehmish
What's more difficult to add to the dictionary before hand are things more
like "samisacorrecthorsebatterystaple". Once you add in proper nouns, the
practicality of pre-loading compounds doesn't work as well, since there's so
many proper nouns. Plus proper nouns are often more memorable because they
have meaning to the person who wrote the password.

~~~
yabadabadoes
If I were building a dictionary I would simply do an analysis with no
punctuation of media to get frequent compound strands, brands, names, etc..

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.

------
tracker1
OT: could someone send me an invite for the site?

lobste.rs at my-username .dev

