Entropy: characters vs words - what is the best generator for everyday passwords

chris970

Hello,

Can you advise on when I should use words vs characters in the password generator? I've read the blog post (https://blog.agilebits.com/2011/06/21/toward-better-master-passwords/) and understand the importance of a strong master password. But I'm asking in regards to everyday websites, which is the better way to generate a password, say for example gmail.

Should we use words or characters?

I've read through your other posts and it looks like words come from a list of 18,000, with an entropy of 14.1 (using log base 2). Assuming a keyboard has 94 characters, that would give entropy of about 6.5.

A 5 word generated password would be entropy of ~70.6 (log2)(18,000^5)
A 20 character generated password would be entropy of ~131 (log2)(94^20)

So it seems it would be better to use 20 random generated characters than 5 random generated words. Is my math correct (apologies if the formulas above aren't exactly pretty)?

Bottom line, can you advise on what scheme you recommend for everyday passwords (NOT the master password): characters or words?

Thank you.

---

1Password Version: 7.07
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Entropy: characters vs words

AGAlumB

@chris970: Thanks for getting in touch! I think you're on the right track. Probably. I'm not sure what you mean by "for everyday passwords" though. It sounds like you are talking about the Master Password...but I wouldn't personally call that "everyday password s" plural because most of us will have only one. ;)

Long story short, you can use characters or words to make strong passwords, but the specific use case can make a big difference in what's best. That will come down to not only what you're using the password for, but also how it fits into your workflow. If you can give me a better sense of what you have in mind I'll be happy to dig into this with you. :)

chris970

Hi,

Thanks for your response. Would you mind taking another look at my original question, "Bottom line, can you advise on what scheme you recommend for everyday passwords (NOT the master password): characters or words?"

To clarify my original post, I am NOT asking about the master password. I'm specifically asking about every single other password you would generate in 1Password that isn't the master password (hence my use of "everyday" example of gmail: or more generically - email, online shopping, etc).

Can you help answer my question relative to the math I outlined and the strength/entropy of a generating a 5 word password vs a 20 character generated password?

And more globally, what is a stronger password for websites (assuming they can support the length of 5 words and don't require special characters): 5 words vs 20 characters?

Thanks

rickfillion

Hi @chris970,

Your math isn't quite right. If you're using the Mac app, you can actually look at the exact number of bits of entropy for a given generated password after you save it. You can do this by enabling the "Copy Item JSON" under Preferences > Advanced, then selecting the item with the generated password, using Item > Copy JSON then finding the "pbe" value in the JSON.

Assuming you're using the Mac app for generating these, here's what I get:

• 5 words : 70.8 bits
• 20 chars, no digits, no symbols, allow ambiguous characters (this is the strongest 20 char password setting in the Mac app) : 114 bits

Both are strong, but the character based password is far stronger.

If you'd like an explanation of why your math is off or why I said that the settings I used are the strongest (which goes against conventional wisdom) let me know and I'd be happy to elaborate.

As for which type of password should be recommended for most purposes: the character based ones. You get a higher amount of entropy within a smaller space, so you can get a stronger password into websites that don't allow as long of passwords.

I hope that helps.

Rick

chris970

Hi @rickfillion

Perfect, thanks so much - exactly what I needed.

I calculated 70.6 for 5 words, which is close enough to 70.8 for me :).

If you could share the math on calculating the entropy for characters I'd appreciate the explanation if you have time (I did it based on 94 characters on the keyboard, so I'm guessing that might be the difference).

Also, if you could help explain about your comment on using no digits/no symbols/allow ambiguous characters I'd also be curious to understand the reasoning (I do see the entropy is higher, as opposed to using digits/symbols/no ambiguous which shows entropy of 103.7).

And yes, I'm using the MAC app.

rickfillion

I calculated 70.6 for 5 words, which is close enough to 70.8 for me

Yeah, your math wasn't wrong there so much as the exact value you used for the word count.

If you could share the math on calculating the entropy for characters I'd appreciate the explanation if you have time

In general you've got it, again the wrong values. In the case of characters, there's only 52 of them (a-z, A-Z). So log_2(52**20).

The math stays nice and simple like that until you get to...

Also, if you could help explain about your comment on using no digits/no symbols/allow ambiguous characters

Common sense would say that including a digit would make the password stronger. But as you're seeing in the pbe values, it decreases the strength. This is because what we're doing is saying "1 of the characters must be a digit. The other 19 must be alpha.". So instead of log_2((52+10)**20) it's log_2(10**1 + 52**19). If instead of specifying a number of digits we instead allowed you to simply choose to include digits, then the result could be log_2(62**20). Our Windows app and our 1Password X extension have the checkbox instead of the slider, and that's where all of our apps should be moving to. This would more closely match what users expect.

The math to calculate it with all of the current options is really ugly, and hard to calculate. It's a frequent topic of conversation any time Rob and Goldberg find themselves in the same room, as they keep trying to find the ultimate solution for the fun of it. The current calculation has a slight bias towards making the password appear a little weaker than it really is (if I remember correctly it's something like 0.2 bits off in the worst case we could think of).

To give you a small taste of why it gets messy... I mentioned log_2(10**1 + 52**19), but that's an oversimplification. Cause in that case the digit's position can change and that would cause different permutations. In the case of 1 digit in 20 chars, there's 20 positions. So it's closer to log_2(20 * (10**1 + 52**19)). That's relatively straight forward. But as you add digits the number of possible positions change. Same with the symbols. Does the position of the digits affect the position of the symbols?

Once we all switch over to the new way of specifying password recipes it should become trivial again to calculate the bits of entropy. New problems arise though... like sometimes you want to ensure that there's a digit and a symbol. Is it really log_2((52+10+26)**20) if you have to throw out all of the passwords that you generate that end up not having both a digit and a symbol? This kind of stuff is a lot of fun. :)

Rick

jpgoldberg

Short answer: If you don't need to remember it (because 1Password remembers it for you) and you never need to type it (because 1Password fills it for you) go with characters.

chris970

@rickfillion Thanks so much for the detailed explanation - super interesting and really neat to see how things are working under the hood. One thing I'm curious on / can you help answer: for the current Mac app, when you leave the "avoid ambiguous characters" box unchecked, how many characters are being "added" to the alphabet? You referenced using 52 characters (26 letters lower case, 26 letters uppercase), but doesn't using ambiguous characters add to that number? And what are those "ambiguous" characters? (I tried generating passwords in the password generator with the box unchecked and don't really see a difference)? I have some memory in past versions of it showing strange characters with that box unchecked, but it doesn't seem to be generating them anymore.

@jpgoldberg Thank you - this was the short and sweet answer I was looking for. You guys might want to add a blog post about this as a compliment to the Master Password post for those who might be interested in delving into the details.

rickfillion

@chris970 : those numbers were approximations. I have to admit that I was too lazy to look up exact ones in the code.

This should help you out:

ALPHA_ALL = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
NUMBERS_ALL = "0123456789";
SYMBOLS_ALL = "!@#$%^&*()_-+=|[]{}'\";.,>?/~`";

ALPHA_LOWERCASE = "abcdefghijklmnopqrstuvwxyz";
ALPHA_NONAMBIGIOUS = "abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRTUVWXYZ";
NUMBERS_NONAMBIGIOUS = "2346789";
SYMBOLS_NONAMBIGIOUS = "@#$%^&*()+=[]{};.,>?/";

chris970

@rickfillion awesome, thank you! (for some reason I thought ambiguous was generating weird symbols like greek symbols, but clearly I was wrong).

rickfillion

Hah. That'd be fun.

Rick

jpgoldberg

for some reason I thought ambiguous was generating weird symbols like greek symbols

That makes a lot of sense, @chris970. I'm wondering if we can present this better. In cases where you might have to type a password the difference (and visual similarity) between "I", "1", and "l" can be a problem. Our internal terminology of "ambiguous character" isn't something that we should expect people to immediate understand just from the terminology on its own.

Alternatively me might just remove the option from the user interface. Generated passwords, unless they are really short, are so strong that we could just omit those ambiguous characters without having to bother the user with the question.

You guys might want to add a blog post about this as a compliment to the Master Password post for those who might be interested in delving into the details.

Thank you. We definitely should. I and I know others love writing about this stuff. But the question is finding the time. @rob will be presenting about some subtle decisions and even subtler math about our password generator at PasswordsCon in Stockholm this November. So he'll be writing something.

chris970

@jpgoldberg Thanks again - you guys are awesome.

rob

Aww, I missed this thread before all the questions got answered. Sad. ;)