where can i find 1password entropy score ?

miyone

Hi, can someone please point me where to get the entropy score for a password generated using 1Password? I have used this before, but can't remember the keyboard shortcuts.

Also looking for the article that explains how it's calculated. Thanks.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

mathieu_g

@miyone Even though it is quite old, is this what you're looking for? https://blog.agilebits.com/2011/08/10/better-master-passwords-the-geek-edition/

miyone

@Mathieu_G thanks for the reply but no. I'm looking for information for entropy calculation in 1Password. Or if someone can please explain in this thread, that would be good.

The entropy value I actually read from a discussion (not article) here. https://discussions.agilebits.com/discussion/81041/how-to-calculate-entropy. So it's "Copy JSON" then look for the "pbe" (password bits of entropy) value.

AGAlumB

@miyone: What you're referring to is an estimate for a specific password. This does not apply to all the passwords of varying length, composition, and provenance that you might store in 1Password. Entropy and password strength are not the same thing; the former is objective, while the latter is subjective. We adjust the "password strength" ratings over time according to research in the security field. Entropy itself is a mathematical calculation, not something specific to 1Password. It's calculated using the equation log2(RL), where R is the number of possibilities for each position (a single word or character), and L is the number of positions (total number of words or characters). Hope this helps! :)

miyone

Hi @brenty, thanks but yeah I understand the whole entropy calculation, I should have been more clear.

Since I'm generating word-based passwords only (not characters) through 1Password, the values i randomly select has dependency on the number of words available in its pool list. To properly compute entropy for this, I would need the total number of words (the L in your example). This is the information i'm looking for.

1Pwd itself provides a "pbe" value, so how that was computed (based on the entropy equation) is what I'm after.

AGAlumB

@miyone: Oh! Wordlist! Sure, thanks for clarifying! Currently it has 18,436 items, so that's 14.17 bits per word — just under 57 bits for a four-word password. Cheers! :)

miyone

@brenty awesome! thanks for that.

miyone

@brenty while on this topic, can you help explain one more please:

if i use characters (not words) and get a 20-bit long password, i get a pbe of ~100. I assume we have the entire character set (a-z, A-Z, special characters). Given this, one character should have around 6.56 bits of entropy, which translates to around ~130 for 20 characters. This doesn't match with the pbe i get.

AGAlumB

@miyone: Hmm. Sorry if I'm missing something here, but why are we making assumptions about the character set? What are you using? @rickfillion or @jpgoldberg may also have something more to add.

rickfillion

@miyone : the effective bits of entropy per character will depend on your settings for number of digits and symbols. With 1Password for Mac, you aren't specifying "yes i want digits" but instead specifying an exact number of digits. As you increase the number of digits, the characters that end up as digits were chosen from only 10 characters, so those have less entropy. There are no characters in the resulting password that were chosen from the complete set of all letters, digits and symbols. So the math gets a little ugly. With no symbols and digits here (Which increases overall entropy per char, which is counter intuitive), I get a pbe of 114 for a 20 character password.

Rick

miyone

@brenty thanks. i mean if i generate password with characters (then provide length, number of digits and symbols).

@rickfillion ahh right, thanks for clarifying that. i failed to consider that it's not totally random when I specify the number of digits/symbols to include. otherwise it's just all letters.

AGAlumB

Yeah, I overlooked that too, so I'm glad Rick was able to jump in and set me straight. Part of why I get confused about this (and, certainly customers too!) is that it varies from platform to platform and version to version, if only slightly. And we're also working on some changes to the strong password generator across all of the apps which will make it more intuitive in the future. Cheers! :)

jpgoldberg

As @rickfillion said, the math gets annoying once we start talking about exactly n digits and exactly m symbols. I had thought that I worked it out for the simple case (in which we only considered n or m, but not both together). It was ugly math, but I thought it was correct.

My first approach

If the length is λ and the number of digits is n, n < λ, then the number of letters will be n - λ. I figured that I could take

1. the number of possible combinations of n - λ letters
2. the number of combinations of n digits,
3. the number of different positions that the n digits could be folded into the string of letters

and multiply the three together. (In practice you take the base 2 logarithm of these and add those, but that is just a computational shortcut).

Calculating 1 and 2 is easy. Calculating 3 was a little trickier and relied on a binomial coefficient, but I thought that I had it.

How this was supposed to work

Suppose we are going for a length of 5 and require exactly two digits.

Now suppose that for the letters part we've generated the string abc. The calculation for (1) above makes that one of 52^3 possibilities. Also suppose that the string of digits that we create are 12. That combination is one out of 100 possibilities.

We can insert the 1 in any one of four positions into abc. Suppose we insert that into the second position, giving us a1bc. Now we can insert the 2 into any one of five positions. Suppose it gets put into the forth position, yielding a1b2c.

So in total we have 52^3 times 10^2 times 4 times 5 for a password of length five that requires exactly two digits. Easy. (Well, a general formula for the number of ways to insert the digit involved some cleverness, but it was perfectly doable.

What that is wrong

The problem with the above can be illustrated by taking the example above but making the two digits the same. Suppose that the digits are 88, and suppose we get the final string a8b8c. The problem is that there are two ways to generate that string while there is only one way to generate a1b2c. One way to get a8b8c is to put the first 8 after the a and the second 8 after the b. The other way is to swap where those two 8s end up.

The algorithm that we are using for generating "exactly two digits" introduces a non-uniformelity (some strings are more likely than others) that was not reflected in the calculation.

Multiple approaches

1. One approach to addressing this would be to find a generating algorithm that was truly uniform in these cases and calculate that real uniformity.

2. Another approach is to ditch the whole "exactly n digits" thing and replace it with something that is cleaner mathematically.

3. A third approach is to estimate just how big or little a problem this is and just round down to be conservative in our calculations.

Well many of us had a good think about approach 1. We didn't succeed with it. So what we are decided was to go with 2 in the longer term, but do 3 in the mean time. A few little test cases convinced us that the error was only going to be a fraction of a bit. And so we've just decided that where there are "exactly n something" in a password generating recipe, we will use my original formula and shave off a bit to be conservative.

Accuracy and precision are nice, but ...

The fact of the matter is that if you generate a password with 14 letters in it and some number n of digits, you are already getting more than 79 bits even before the digits are considered. And nobody is going to break a 79 bit password. (For reasons I should explain elsewhere, it is much more expensive to test a password than it is to test a cryptographic key.) So there really is a point, which is reached fairly early with generated passwords, where the password is insanely strong. So we don't mind being a fraction of a bit off in these cases.

I would love to have an exact formula. I, @rob, and @pilar have each spent time on trying to find an exact formula. The whole thing feels like we should be able to find an elegant solution to this. But we haven't, and so in terms of being conservative, the pbe may be slightly lower than the true value given the password creation recipe.

AlwaysSortaCurious

That discuss elsewhere bit would be appreciated at some point... and the distinction between the password and the derived key and why wouldn’t you just go after dk... when you’re hyper bored some day.... or just a couple of really spot on links.... lol. The candor is always appreciated...

AGAlumB

That discuss elsewhere bit would be appreciated at some point... and the distinction between the password and the derived key and why wouldn’t you just go after dk... when you’re hyper bored some day.... or just a couple of really spot on links.... lol. The candor is always appreciated...

@AlwaysSortaCurious: Haha! I don't think he'd have to be bored to discuss it. ;) I'm interested in this too. I suspect that @jpgoldberg is referring to the relative uniformity of cryptographic keys versus the near-universal non-uniformity of passwords making it easier to to test the former compared to the latter, but that's just a guess. :)

jpgoldberg

Testing a bunch of cryptographic keys has several speed advantages over testing password guesses.

1. Keys are just numbers that can be incremented in place. It is very quick to move on to the next key. No new memory allocation is needed, no copying of data. And it is very easy to parallelize.
2. You don't need a password guess generator when testing keys. (This is closely related to the previous point).
3. The passwords we are talking about are hashed with something like PDDKF2, scrypt, Argon2, etc. These involve tens of thousands of cryptographic operations instead of just using a small handful of operations that are built into modern chips.

So I follow Bonneau and Schecter's (§2.1) (conservative) estimate that it is at least a million times (2^20) slower to guess passwords than the test keys.

In most scenarios, we can gain equivalent security with a smaller secret by key stretching, deliberately making the verification function computationally expensive for both the attacker and legitimate users [66, 57]. Classically, this takes the form of an iterated hash function, though there are more advanced techniques such as memory-bound hashes like scrypt [69] or halting password puzzles which run forever on incorrect guesses and require costly backtracking [25].

With simple iterated password hashing, a modern CPU can compute a hash function like SHA-256 at around 10 MHz [1] (10 million SHA-256 computations per second), meaning that if we slow down legitimate users by ≈ 2 ms we can add 14 bits to the effective strength of a password, and we can add 24 bits at a cost of ≈ 2s. While brute-forcing speed will increase as hardware improves [38], the same advances enable defenders to continuously increase [72] the amount of stretching in use at constant real-world cost [19], meaning these basic numbers should persist indefinitely.

What this means is that we can look at a password creation scheme that produces 56-bit passwords (as four words from our list will do) as being as hard to break as a 76-bit cryptographic key. That is going to be assailable by someone willing to spend millions of dollars in cracking, but someone willing to put those kinds of resources into things, would find cheaper ways to obtain your secrets.

AlwaysSortaCurious

OK. That might have been the missing connective bit in my head. So that depending on the cracking approach, the goal is to make either one prohibitive (the smaller and more expensive 56-bit password vs the comparable but much larger 76-bit key) so that it is just cheaper (if you are such a big wig as to be singled out) to hire a couple of guys with a van and a very long rap sheet. :) Thank you @jpgoldberg

jpgoldberg

Yep. Unless you have extraordinary operational security, people who'd spend a 100,000USD to get your 1Password data would just break into your house and tamper with your computer.

That isn't an argument for complacency about cryptographic security. When done right, the cryptography should be by far the hardest part of the system to attack. We aim to do it right.

fractal_sounds

As you increase the number of digits, the characters that end up as digits were chosen from only 10 characters, so those have less entropy. There are no characters in the resulting password that were chosen from the complete set of all letters, digits and symbols. So the math gets a little ugly. With no symbols and digits here (Which increases overall entropy per char, which is counter intuitive), I get a pbe of 114 for a 20 character password.

@rickfillion: Is the reason for the drop in entropy when specifying an exact number of digits due to the lower bound vs upper bound considerations of entropy (as mentioned in this article)? I.e. that we take the lower bound because we are saying an attacker could in theory have some information about the recipe used for generating the password? Or is a password that contains digits actually weaker and easier to break in practice than one of the same length containing all letters? In other words, if a website doesn't require me to have any digits or special characters in my password, am I better off generating a letter-only random password?

I would love to have an exact formula. I, @rob, and @pilar have each spent time on trying to find an exact formula. The whole thing feels like we should be able to find an elegant solution to this.

@jpgoldberg: I'm not sure if I've understood correctly, but are you just trying to find a general formula for the reduction in the number of unique ways to generate a password in the event of duplicate digits? If so, I had a bit of a play around with this and think I've found something that works, but I'll hold off for now in case I have totally misunderstood what you meant and you're trying to find something much more complex! :)

rickfillion

@fractal_sounds : When generating the actual number of bits of entropy we need to assume that the attacker has the exact formula, as it's the actual formula that defines the bits of entropy.

The drop in entropy is due to the fact that when you specify an exact number of digits, what you're saying is "some of the chars in this password are from the numeric set, some are from the letters set". So something like (10**numberOfNumeric) + (26**numberOfLetters) permutations. If it was a simple checkbox that said digits were allowed, then we'd be saying "all of the chars are from the alphanumeric" which would be 36**length. The latter grows much faster. There's additional permutations for the former that technically need to be taken into account for positioning, but compared to the overall numbers it's pretty miniscule.

So it's not that adding digits to a password makes it weaker... it doesn't. But adding a specific number of digits to a password of length A is going to have fewer total permutations than a password of length A that contains only letters.

This is why I'd really like to see our Strong Password Generator change from specifying an exact number of digits to simply asking if you want there to be digits. There's still some messiness there since a password that CAN have digits isn't guaranteed to HAVE digits. And so we'd need to account for that... but overall it would generate stronger passwords.

You can always compensate for these things by simply increasing the length of the password.

Rick

jpgoldberg

@fractal_sounds, I'm not sure if we are talking about the same thing. And perhaps there is a simple solution to a problem that I made overly complex. So if you think you've got a formula, please share it.

jpgoldberg

This is why I'd really like to see our Strong Password Generator change from specifying an exact number of digits to simply asking if you want there to be digits.

Me, too! (As @rickfillion and others well know.) Just goes to show that sometimes even simple features that we pretty much all agree on can take time.

fractal_sounds

But adding a specific number of digits to a password of length A is going to have fewer total permutations than a password of length A that contains only letters.

@rickfillion: Thank you very much for the detailed response. I keep thinking that I understand it and it makes perfect sense, but there's something still not clicking when I try to work out some sample numbers. Can you please read through my reasoning below and let me know where I'm going wrong? By the way, this is purely for educational purposes, I'm not actually worried about any security issues. As you mentioned, using a password of sufficient length will make these factors irrelevant in practical terms. I'm just interested in understanding how the math works in regards to the number of possible permutations under different circumstances.

I'm trying to compare the number of permutations (P) for two passwords of length L, that contain:

1. Only lower case letters
2. Only lower case letters plus exactly 1 digit (to avoid the messiness of duplicate digits)

This is what I came up with:

P1 = 26 ** L
P2 = [26 ** (L - 1)] * L * 10

My reasoning for the calculation of P2 is:

• First we will have (L - 1) characters each of which can have 26 possibilities.
• Multiply the above result by L, since we are adding a single digit which can be inserted into any one of L positions. This is the general case for the "We can insert the 1 in any one of four positions into abc" that was discussed earlier in this thread.
• This single digit can take 10 possible values, hence multiplying the above result by 10.

For a password of length 2, I get P1 = 676 and P2 = 520. But for a password of length 3 or higher, P2 actually ends up being larger than P1, and the gap between them continues to grow as L increases.

I know I must be missing something obvious, but no matter how many times I go over it, I can't figure out what I'm doing wrong to be getting a higher number of permutations for the case that contains a digit.

rickfillion

@fractal_sounds,

P1 seems correct.

P2 isn't what you'll see in 1Password. I mentioned the positioning, but we don't actually add that component. So if you look at your example, with our formula it'd be P2 = [26 ** (L - 1)] * 10, or more generally... if D is the number of digits out of L... P2 = [26 ** (L - D)] * [10 ** (D)].

The fact that we aren't taking the positioning into account is probably where your differing numbers would come from. Technically this means that the passwords we generate are a little stronger than we claim them to be, which we're OK with.

Rick

fractal_sounds

@rickfillion: Ahh gotcha! I didn't know you guys don't take the positioning into account. Oh and yes, definitely a bonus to have the generated passwords be even a little bit stronger in practice. :)

Thank you very much for your help.

rickfillion

You're very welcome. We do love talking about this stuff, so don't hesitate to ping us with more questions.

Cheers.

Rick

fractal_sounds

@jpgoldberg: I'm pretty sure I have actually misunderstood and oversimplified. I thought that you just needed to find a formula for calculating the following: In the event of one or more of the digits being duplicates, by what factor (F) is the total number of unique permutations reduced?

So I just played around and found that:

reductionFactor = factorial(totalDigits - uniqueDigits + 1)

So for example, let's say we have a single letter such as A and we want to add exactly four digits to it.

• There will be 2 * 3 * 4 * 5 = 120 different ways we can insert our four digits around a one-character string. So there will be 120 * 52 * (10^4) ways to generate our password, if all of the digits are unique.
• With three unique digits, RF = factorial(4 - 3 + 1) = 2, thus 60 * 52 * (10^4) ways.
• With two unique digits, RF = factorial(4 - 2 + 1) = 6, thus 20 * 52 * (10^4) ways.
• With one unique digit, RF = factorial(4 - 1 + 1) = 24, thus 5 * 52 * (10^4) ways.

I think I've got that formula worked out correctly, I've tried it with a few sample cases and the numbers match. What I don't know is whether this is of any use in what you're trying to find, namely:

One approach to addressing this would be to find a generating algorithm that was truly uniform in these cases and calculate that real uniformity.

For example, for the case of two unique digits mentioned above, is it correct to say that: "For passwords generated with exactly four digits, those containing only two unique digits are 6 times more likely to be generated than those containing four unique digits."? Does that help in trying to calculate the real uniformity you mentioned, or is it way more complicated than that?

fractal_sounds

As you increase the number of digits, the characters that end up as digits were chosen from only 10 characters, so those have less entropy. There are no characters in the resulting password that were chosen from the complete set of all letters, digits and symbols. So the math gets a little ugly. With no symbols and digits here (Which increases overall entropy per char, which is counter intuitive), I get a pbe of 114 for a 20 character password.

@rickfillion: Is the reason for the drop in entropy when specifying an exact number of digits due to the lower bound vs upper bound considerations of entropy (as mentioned in this article)? I.e. that we take the lower bound because we are saying an attacker could in theory have some information about the recipe used for generating the password? Or is a password that contains digits actually weaker and easier to break in practice than one of the same length containing all letters? In other words, if a website doesn't require me to have any digits or special characters in my password, am I better off generating a letter-only random password?

I would love to have an exact formula. I, @rob, and @pilar have each spent time on trying to find an exact formula. The whole thing feels like we should be able to find an elegant solution to this.

@jpgoldberg: I'm not sure if I've understood correctly, but are you just trying to find a general formula for the reduction in the number of unique ways to generate a password in the event of duplicate digits? If so, I had a bit of a play around with this and think I've found something that works, but I'll hold off for now in case I have totally misunderstood what you meant and you're trying to find something much more complex! :)

rickfillion

@fractal_sounds : yes, it's exactly due to the lower bounding reason as described by that article. We give you the lower bound.

Rick