3 ms·

The only requirement for passwords these days should be that the entropy is high enough and that the password is not in password leak databases. Anything other

The only requirement for passwords these days should be that the entropy is high enough and that the password is not in password leak databases. Anything other than that is simply asking users to reuse passwords across sites or annoying people who use password managers that generate too complex passwords. Passphrases are perfectly reasonable choices for passwords, but often run foul of the number and special character rules. Worst part is some sites even have very short max length rules for passwords. One can only suspect they either go around thinking people still memorize passwords, or worse, they store passwords in a varchar(12) DB column. The best bet would be to eliminate passwords alltogether using some combination of webauthn key authentication and some other user friendly factor (e.g. TOTP). But as long as passwords are here to stay, make them user friendly.

pbhjpbhj 4y ago
I was on a major UK broadband suppliers website yesterday, password required to be <= 16 characters ... /jackie-chan-meme ... doh, that's 17 characters
danbruc 4y ago
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
On the note of entropy, and checking for a breach at the same time... I have been toying with the idea of adding hibp api support to Nbvcxz which would give an integrated solution for ensuring you aren’t storing weak or already leaked passwords (hashed) in your system...but I was hesitant because adding network calls to a library like this can be a security risk. I may just try and implement and see what it looks like.
- dns_snek 4y ago
  > but I was hesitant because adding network calls to a library like this can be a security risk HIBP works by having the client SHA1 hash the password and send a 5 character hash prefix to the API. What you receive in response is a list of all breached password hashes which you can then compare the full hash against. https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByR... HIBP never receives the password or the full hash. Did you have any other risks in mind?
  - Tostino 4y ago
    Understood, but imo any network calls at all are a something to raise eyebrows with a library like this, and I figured that would raise the barrier of adoption. I was thinking if people wanted to do that they would integrate both nbvcxz and HIBP api themselves... No specific risks, I was just trying to keep a very low footprint with this library to give little reasons for a security department to tell developers "no, don't use that".

pbhjpbhj 4y ago

I was on a major UK broadband suppliers website yesterday, password required to be <= 16 characters ... /jackie-chan-meme ... doh, that's 17 characters

danbruc 4y ago

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

On the note of entropy, and checking for a breach at the same time... I have been toying with the idea of adding hibp api support to Nbvcxz which would give an integrated solution for ensuring you aren’t storing weak or already leaked passwords (hashed) in your system...but I was hesitant because adding network calls to a library like this can be a security risk. I may just try and implement and see what it looks like.

dns_snek 4y ago
> but I was hesitant because adding network calls to a library like this can be a security risk HIBP works by having the client SHA1 hash the password and send a 5 character hash prefix to the API. What you receive in response is a list of all breached password hashes which you can then compare the full hash against. https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByR... HIBP never receives the password or the full hash. Did you have any other risks in mind?
- Tostino 4y ago
  Understood, but imo any network calls at all are a something to raise eyebrows with a library like this, and I figured that would raise the barrier of adoption. I was thinking if people wanted to do that they would integrate both nbvcxz and HIBP api themselves... No specific risks, I was just trying to keep a very low footprint with this library to give little reasons for a security department to tell developers "no, don't use that".