1. 20
  1. 3

    I wish he took the last step to figure out how many characters that is given an alphabet you can easily type on a keyboard.

    If we define that as the 95 displayable ascii characters, would that be bitlength/sqrt(95), or am I mixed up? So for the 327 suggestion, that’d be 34 randomly selected characters?

    Of course, I get a simple number is probably not a good idea because people wouldn’t pick a truly random 34 character password in practice unless they’re using dice or a password generator, so that’d be irresponsible if he was quoted out of context.

    1. 1

      I think it would be bitlength/log2(95), because log2(95) gives you how many bits needed to represent 95 possibilities. log2(95) ~= 6.5. So, 327/6.5 = 50-51 displayable ASCII characters. For the higher estimate of 405.3 bits, this results in ~62.3 displayable ASCII characters.

      1. 3

        Passwords of the same length using the same charset can have different levels randomness, and thus different entropy measurements. For this reason, I’d recommend using a tool like zxcvbn (many implementations exist) or KeePassXC to calculate password entropy; they take into account things like dictionary words and non-random patterns. I’ve generally found KeePassXC to give much better results than zxcvbn.

        I do understand the need to connect this to “acutal” passwords, so I updated the article with some sample passwords. Diff.

        Thanks for the feedback.