5 ms·

The only requirement for passwords these days should be that the entropy is high enough [...] Which is at least somewhat non-trivial. What is the entropy of »a

The only requirement for passwords these days should be that the entropy is high enough [...] Which is at least somewhat non-trivial. What is the entropy of »abcd«? Four of four different characters, therefore 8 bit? Four hex digits, therefore 16 bit? Four lowercase letters, therefore 18.8 bit? Or even four letters, therefore 22.8 bit? Ad hoc I would say that 8 bit seems to be the best choice as one does not have to guess the underlying alphabet, but that probably means that you mostly get values quite a bit lower than password length times the logarithm of the alphabet size would suggest.

Tostino 4y ago
The right thing to do is to assume the attacker knows the character set used for a brute force attack so they can limit the search space accordingly, and use that in your entropy calculation. You'd also want to do things like look for patterns, because tools like John the ripper absolutely do more than random guessing.
- danbruc 4y ago
  That was my point, you don't really know the character set used, you only know the characters used. It is reasonable to assume that the characters of »cat« were drawn from the set of lowercase letters but for all you know they could have been drawn from a set of three letters and to err on the side of caution you probably should assume it was indeed drawn from the set of three letters. And of course, password crackers can do a lot more than simply brute force through all possible character sequences, which just underlines my point that calculating the entropy or maybe better the resistance against password crackers is non-trivial. But as others have pointed out, there are are existing implementations like zxcvbn and you do not have to solve this problem from scratch.
  - Tostino 4y ago
    Yup, I understand the problem space. I wrote one of the ports for zxcvbn and have been maintaining it for the past ~7 years. You are absolutely right there, and zxcvbn makes a guess by using the whole character set for a specific type. It groups a whole bunch of special characters together as well, potentially overestimating passwords that contain a special chars. This is mitigated by the fact that it's much less important to be good at estimating the score of a properly random password than it is at estimating poorly (human) constructed password. It's a game of making the best assumptions you can, but total accuracy is not something to shoot for here.

Tostino 4y ago

The right thing to do is to assume the attacker knows the character set used for a brute force attack so they can limit the search space accordingly, and use that in your entropy calculation. You'd also want to do things like look for patterns, because tools like John the ripper absolutely do more than random guessing.

danbruc 4y ago
That was my point, you don't really know the character set used, you only know the characters used. It is reasonable to assume that the characters of »cat« were drawn from the set of lowercase letters but for all you know they could have been drawn from a set of three letters and to err on the side of caution you probably should assume it was indeed drawn from the set of three letters. And of course, password crackers can do a lot more than simply brute force through all possible character sequences, which just underlines my point that calculating the entropy or maybe better the resistance against password crackers is non-trivial. But as others have pointed out, there are are existing implementations like zxcvbn and you do not have to solve this problem from scratch.
- Tostino 4y ago
  Yup, I understand the problem space. I wrote one of the ports for zxcvbn and have been maintaining it for the past ~7 years. You are absolutely right there, and zxcvbn makes a guess by using the whole character set for a specific type. It groups a whole bunch of special characters together as well, potentially overestimating passwords that contain a special chars. This is mitigated by the fact that it's much less important to be good at estimating the score of a properly random password than it is at estimating poorly (human) constructed password. It's a game of making the best assumptions you can, but total accuracy is not something to shoot for here.