7 ms·

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

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.

jbay808 6y ago
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.
- LeifCarrotson 6y ago
  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.
  - jbay808 6y ago
    Right; so we seem to agree entirely that the entropy is relative to the attacker's generator.
    - LeifCarrotson 6y ago
      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.
      - Beldin 6y ago
        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.
        bradknowles 6y ago
        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.
        Beldin 6y ago
        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.
- Privacy846 6y ago
  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?
  - nakkijono 6y ago
    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".
- ravi-delia 6y ago
  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.
- Godel_unicode 6y ago
  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 https://github.com/dropbox/zxcvbn
- dheera 6y ago
  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.
- uoaei 6y ago
  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.
ggggtez 6y ago
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.
SAI_Peregrinus 6y ago
It's related to Qvault, the password manager written by someone who keeps making very fundamental mistakes about cryptography in their blog.
- wagslane 6y ago
  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.

jbay808 6y ago

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.

LeifCarrotson 6y ago
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.
- jbay808 6y ago
  Right; so we seem to agree entirely that the entropy is relative to the attacker's generator.
  - LeifCarrotson 6y ago
    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.
    - Beldin 6y ago
      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.
      - bradknowles 6y ago
        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.
        Beldin 6y ago
        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.
Privacy846 6y ago
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?
- nakkijono 6y ago
  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".
ravi-delia 6y ago
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.
Godel_unicode 6y ago
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 https://github.com/dropbox/zxcvbn
dheera 6y ago
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.
uoaei 6y ago
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.

ggggtez 6y ago

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.

SAI_Peregrinus 6y ago

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

wagslane 6y ago
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.