Live data from Hacker News

Entropy isn't sufficient to measure password strength

benwr.net

111–120 of 124 posts

Re: Entropy isn't sufficient to measure password strength

#111
post #32

Earlier quoted context omitted.

The point of public key cryptography is that there isn't a shared secret.

A shared secret is not an attack vector though, a reused secret is. If you reuse an asymmetric key, it will identify you across the world. But if you don't reuse an asymmetric key, then the point of asymmetric cryptography is moot and is no better than a password manager.

Identifying yourself is the whole point of logging in to a website. Yes, if you want to maintain a distinct digital identity for each website you’ll need to use a different key pair for each website, which by the way is actually feasible.

With our current email-address-and-password scheme that is so difficult to do it might as well be impossible. You’d need a distinct email account for each distinct digital identity that you want to maintain.

Re: Entropy isn't sufficient to measure password strength

#112
post #25
post #18

When will we stop using passwords?! They are an elementary school kid “secret club” game taken way, way too far. They are totally broken. Nobody can come up with and remember good passwords. Nobody can store passwords securely. 100% busted. Instead of continuing to debate what makes a good password, we need to put our energy into better techniques altogether! No more shared secrets! Let’s talk about one-time codes, a…

Hopefully never. Or at least not in the near future. Almost every other method is going to have privacy implications because they will rely on something you have or something you are. You can't compel passwords in a similar way that you can compel people to give physical tokens or fingerprints or retina scans.

Fingerprints and retinal scans are not something I proposed. Your point is valid for those. Your point is not valid for hardware tokens vs. passwords. Especially when you consider that passwords used for authentication have to be written down somewhere and shared with a third party for them to work at all.

Re: Entropy isn't sufficient to measure password strength

#113
post #107

Earlier quoted context omitted.

Of course. I can type a password from memory, or it can be auto-filled by the browser/password-mgr. No interruptions before signing in. Having to open email inbox means switching tabs/context.

You never forget a password and/or your password manager generates passwords and auto fills them with no hiccup for every website and app out there? Also changing passwords when a site policy requires it or when (not if) a breach happens? Because that is NOT my experience.

Yes, occasionally there is a hiccup with the password system. But email link or code is disruptive and irritating 100% of the time.

Re: Entropy isn't sufficient to measure password strength

#114
post #4

Kolmogorov complexity/entropy is more suitable for this purpose, under the implicit assumption that password crackers don't have tailored prior knowledge and are just enumerating "simple" sequences. It only agrees with Shannon entropy on long ergodic sequences. The author basically constructed an example where the two notions don't agree.

How would you estimate the Kolmogorov complexity for the author's example?

By giving the password to a good compressor? (and then computing the shannon entropy of the result) Yet i'm not sure i know a good compressor for short strings... Perhaps something like gpt2tc tailored to passwords instead of english text.

Re: Entropy isn't sufficient to measure password strength

#115
post #95

Earlier quoted context omitted.

Having to check my e-mail for each login is a major annoyance. Perhaps something like SQRL[0] may help. [0]: https://sqrl.grc.com/pages/what_is_sqrl/

More annoying than passwords?

My password manager fills them in for me. E-mail means switching tabs and remembering which account I used to sign up for the service to know where to check.

Re: Entropy isn't sufficient to measure password strength

#116
post #4

Kolmogorov complexity/entropy is more suitable for this purpose, under the implicit assumption that password crackers don't have tailored prior knowledge and are just enumerating "simple" sequences. It only agrees with Shannon entropy on long ergodic sequences. The author basically constructed an example where the two notions don't agree.

The implicit assumption however isn't good. Password crackers regularly make use of prior knowledge. A password that consists of a Shakespearian Sonnet for example has very high complexity but makes for a bad password.

Kolmogorov complexity kinda does account for "prior knowledge" (that's why it's not computable). A shakespearian sonnet will have low kolmogorov complexity (there's redundancy).

Re: Entropy isn't sufficient to measure password strength

#117
post #110
post #49

Earlier quoted context omitted.

Further to this point, the shared item is moved to a public key and the infrastructure to facilitate communication. Such that it is not a panacea. Getting away from trust in the system is... Likely you will envision a system to register your key. And then you have to have a bootstrap to authenticate to this system. Probably a password.

Right, if it’s not a panacea then we should definitely not pursue it.

Not my point. Just not clear that the alternatives actually are better. Again, I use hardware tokens. Not seeing my family join me on that anytime soon.

List of problems with every approach always falls back to, "what happens if you lose it?"

And the resolution to that is always outside of the technical chain.

Re: Entropy isn't sufficient to measure password strength

#118
post #99
post #26

Earlier quoted context omitted.

I'm curious how you think these other items work. They ultimately boil down to a shared secret that is beyond what you can remember. Which... isn't the best thing, necessarily. Consider, if I leave my hardware token at home when I go on vacation, I'm basically locked out of all of my accounts. This is fine, as I typically plan for this to be the case. But it is an attack vector. I can't even audit my protected assets…

How is any of that worse than passwords? I only see improvements. Still not perfect, but big improvements.

My question is how is it any better? A weak link is the trust chain, in both.

For problems, easy ones to consider is that of access. Easy to forget to take a key with you. Or lose it in a fire/disaster.

You can also be compelled to turn over a hardware token. Or a digital file.

Re: Entropy isn't sufficient to measure password strength

#119
post #94
post #22

Earlier quoted context omitted.

I'm curious if you have a rotation/audit practice for those? With 600 odd passwords, I'm not even sure how I would keep track of access to the items being protected.

Rotating/expiring random 25 char passwords is unnecessary. One big advantage of a password manager is you _can_ audit accounts/passwords. I do a once a year sweep of my personal ones in KeePass, and use it as an opportunity to close accounts on services I no longer use. (Not that I believe any 3rd party service can be trusted to actually delete your data when you close your account, but spending 5 minutes updating yo…

That is auditing your access to a password. It is not auditing the use of said password at the service. Consider, social hacking to reset one of your passwords cannot be determined by inspecting your manager.

And rotation is still needed. Less likely that you're password is busted, I agree. But, you still need to rotate, if only to make sure it was never intercepted.

Re: Entropy isn't sufficient to measure password strength

#120

Earlier quoted context omitted.

I don't understand your argument at all. Why does an attacker need to try a full set of characters? Real attackers try from dictionaries or password generation methods (eg dictionary + numbers, dictionary + dictionary + number + symbol, etc), and "password" is one of the first passwords they'll try. They do this because they don't know exactly how you generated the password, but due to password leaks, they do have a…

> I don't understand your argument at all. Why does an attacker need to try a full set of characters? Real attackers try from dictionaries or password generation methods (eg dictionary + numbers, dictionary + dictionary + number + symbol, etc), and "password" is one of the first passwords they'll try. They do this because they don't know exactly how you generated the password, but due to password leaks, they do have…

> I'm well aware. How does this help the attacker attacking the higher-entropy string I outlined?

Well, suppose the attacker is aware of your password generation method (e.g. it's in an open-source password generator, or you wrote down your method and someone stole the description). You have specified the generator as { 5/6 "password", 1/6 "hj5^@l2jl9GGk;Clkm(0]" }. In this case, the attacker will guess the password pretty quickly -- on the second guess at worst -- even in the 1/6th case that it is "hj5^@l2jl9GGk;Clkm(0]".

This is because the string "hj5^@l2jl9GGk;Clkm(0]" doesn't intrinsically have entropy. The generation method is what has entropy -- but in this example, not very much entropy, which is why you got hacked.

> How difficult is it for an attacker to attack a password consisting of four lower case english dictionary words?

It depends on the dictionary and the cost to guess a password. If you choose from, say, the 3000 most common dictionary words, then it will take the attacker 3000^4 = 81 trillion guesses to guess 4 of them. If the application has appropriately used salt and strengthening, such that it takes eg 10 core-ms to check a guess (with a function like argon2 that's annoying to run on a GPU), and the attacker throws 1000 cores at the problem, then this will take about 81e12 * 10e-3 / 1000 / 86400 / 365 = 25 years to exhaust the entire space, or half that on average.

Of course, the attacker could use more than 1000 cores, so this difficulty is surmountable, but it is pretty expensive to break. If your account is high-value, then 5 or 6 words would be a better choice. Also, if the service doesn't strengthen the password, and the attacker can acquire the hash, then 4 words is definitely not enough.

> I'm not sure who has dictated that this is supposed to be how entropy is used for password management.

I'm not sure what you mean by "supposed to be used" or "dictated". You don't have to use entropy to analyze password management, but it does make for a good analysis. The theory has been around for decades. See eg https://diceware.dmuth.org.

Theorem: if you sample a fresh secret (e.g. a password) from a distribution D of min-entropy x bits, and if an attacker then tries to guess it based on no other information (i.e. they might know D but they didn't like, already phish the secret), then in N guesses they will succeed with probability at most N/2^x.

Proof: By definition, the probability that any one guess is correct is at most 1/2^x, so the overall probability is at most N/2^x by the union bound. Easy peasy.

Note that this theorem does not hold if min-entropy is replaced by Shannon entropy, which is usually what people mean when they say "entropy" without qualifications. Note also that it makes no assumptions about character sets. The character set would only be relevant if each character were chosen iid, or if the attacker decides to attack the password as if this were so.

Post reply on HN