Hacker News Reader

Comment by Privacy846 | Hacker News Reader

I don’t understand what is raw or no-bullshit about this, although it makes it sound very serious.

The entropy depends on how the password is generated. If I choose ten words from my own dictionary then the entropy depends on the size of the dictionary. But if I re-rolled 15 times until I got words that I liked then one would have to decrease the entropy accordingly. But someone else couldn’t distinguish those two cases if they knew nothing about me (modulo common human psychology).

The point is that entropy depends on how the agent generated the password and has nothing to do with character sets or length in itself. So sure, this could be said to be a certain approach to approximating entropy in the general case, but I see no reason to put adjectives in front of “entropy-based password validation” which somehow suggest that it’s the number one, objective way to do it.

View on HN

That seems backwards to me. The entropy should be relative to how the password is guessed, not how it was generated.

It doesn't make any difference to the attacker if I pick "bluecheese" out of a dictionary or as a result of successive random letter draws.

This is the correct answer. Password security is not an absolute thing, it's rather the case that a password is secure or insecure relative to an attackers ability to guess it. Interestingly enough, it's also the motivation for zxcvbn, the open source library chrome uses to evaluate password strength!

https://github.com/dropbox/zxcvbn

It does make a difference because the attackers have comparable sophistication to the generators.

They don't have to brute force all 26^10 lowercase character sequences if they can instead look through 26^3 words in a dictionary. And optionally modifying those words to append "1!" to them, or capitalize the first character, or replace e with 3 or whatever doesn't take much.

Right; so we seem to agree entirely that the entropy is relative to the attacker's generator.

Sure, but the attackers you want to consider are the ones who have generators that can match your minimum entropy to generate the password - assume their dictionary is no longer than yours, their set of punctuation doesn't have any characters yours doesn't, etc.

It depends whether you want to determine an upper bound or a lower bound on #guesses needed.

The article's approach has no assumptions and provides an upper bound. Your approach makes several assumptions and gives a lower bound IFF those assumptions hold.

The upper bound is useful for the general case: no attacker will be worse.

You're trying to account for more sophisticated attackers, which is great! It is however not clear (without further motivation) whether your attacker model is realistic. That is: will their be an attacker who knows this much about your password generation approach, but does not know more?

If no realistic attacker would know this much, your approach gives an overapproximation (real bound is higher). If, otoh, there is an attacker who knows more (eg, seed of the PRNG, or first characters, etc.), it'll be an underapproximation (real bound will be lower).

So, the difference is that the result of the first approach can directly be interpreted, while the result of your approach needs context.

The upper bound is a best case analysis. In the best case, I can choose “1” to be my password, and no one will ever guess it.

In the worst case, we assume that the attacker has done their home work and knows the algorithm by which the password was generated, but not the content of this particular password. So, knowing the algorithm, what can the attacker exploit that would help them discover the contents of this password in the shortest possible time?

I submit that the worst case analysis is really the only one we care about.

My point is that that is not the worst case. Example of a worse case: the attacker knows that + the first 2 characters of your password (real-life example).

The worst case would probably be something like "attacker knows hash, passwd algorithm, full state of machine at passwd generation time incl. random seed and all characters of the password but one". It is clearly far worse than your case, though I find your case more relevant than this one.

Not quite, if you take the a priori assumption that the attacker will test dictionary words, you don't want your password to be a dictionary word.

However, it's so incredibly unlikely a high entropy generator would generate a dictionary word that you shouldn't even have to worry about it.

Yes, entropy can only be measured in relation to an expected probability distribution. You need to have an a priori model for how the password is generated (selected) to estimate its entropy. So the dichotomy you set up is IMO a false one, in that you are guessing about how the password was generated.

But if you assume that the attacker knows the generation process then you can make a very strong case that the password is no weaker than the stated entropy[1], since the attacker would have to effectively brute force the password by generating all possible passwords using that generator.

[1] Although I guess there are caveats: what if your password _happened_ to be weak according to another generation method that you didn’t use but the attacker guessed?

Lets say that you use method such as `openssl rand -base64 6` and out comes "password". The odds of that happening would be crazy low for an individual user. However, if you deploy the same generator for a billion people it could realistically happen, and you might want to filter against outputs like that. Of course if all passwords are autogenerated (users cannot choose), the attacker gains no advantage from choosing "password" instead of "tlnNHJ4x".

I suppose it comes down to a worst-case best-case type of thing. If you're trying to prevent Alan Turing and Bletchley Park (new band name I call it) from guessing your password given spies and psych profiles, you care about the entropy of the generation. In principle the best password actually is whatever the last one your opponent's cracking software tries. In between is the real world, but you can't go wrong with real random generation.

Haha, couldn't agree more. Not to mention the "hacks" they use to artificially lower entropy of repeated characters.

So the password 1010101010101011101101000000010111011011101001010001001101011011 is calculated as only having a length of "2" and a base of 10. So it would be about 6 bits according to this. But the generation method clearly is generating a binary string with length 64, for a total of 64 bits of entropy.

It's related to Qvault, the password manager written by someone who keeps making very fundamental mistakes about cryptography in their blog.

Heyoo I remember you from Reddit. Qvault is no longer a password manager, though that was a fun project. I think I've corrected the mistakes in my articles that you pointed out, if you have found anymore I'm all ears.

Reply on news.ycombinator.com