Password Generator Doesn't Always Include Numbers Or Symbols When Checked
I've filed this under 1Password X as that's the app I use the most, but from my testing this may affect all versions of the app.
Issue:
Despite having both symbol and number keys checked, the password generator does not always provide a password with those requirements filled.
Why this is an issue:
1. Most sites I visit require numbers, symbols, or both to be in the password
2. Additional numbers or symbols can be boon to security
How to repeat it:
While your mileage may vary, I've been able to reliably reproduce this issue at least once in every 10 refreshes of the password generator button. This holds true even if I don't click the refresh button. Out of 70+ attempts (each attempt consisted of as many references as it took to generate a password without the requirements), only about 5 of those took more than 10 refreshes to reproduce and all stayed under 20 refreshes.
Which products are affected:
So far as I've been able to test:
1Password X running on:
* Chrome 67 on Windows 10 (tested on 2 computers)
* Chrome OS 67 on an older Asus Flip
1Password Windows Desktop App
* Windows 10 (2 computers)
1Password Android App
* Android 8 on a Samsung S8
Odd Quirks:
As Android is slower to test password generation, I had a smaller sample size, but noticed less issues in the 30 or so refreshes I did.
The windows native program seems to actually have worse issues in my testing than the chrome app, but given my sub 1,000 sample size, it's pretty easy to come to false conclusions.
There always seems to be either a number or a symbol when both options are checked, but roughly once in every ten-ish times it's missing one of them.
Numbers go missing WAY more often than symbols, possibly because the generator favors symbols over numbers, reliably giving more symbols than numbers in almost every single password generated. I assume the symbols get favored over numbers due to there being 32 symbols on the US keyboard vs only 10 numbers.
Possible Cause:
It's possible from what I've seen on these forums about your password generation that the numbers and symbols are being grouped together.
Example: 32 character password w/ symbols and numbers calculated as 23 letters and 9 symbols or numbers.
If this is the case, the solution would be to separate them and give both numbers and symbols a priority.
Example: 32 character password w/ symbols and numbers calculated as 23 letters and 3 symbols and 5 numbers
As I'm not sure this is how it's calculated, I can't say this is a solution or even related to the cause, but it's the best I can guess without more information.
Closing comments:
I'm aware that forcing a user to use symbols and numbers rather than simply allowing it, does not make a password much more secure, but in the world we live in, many sites absolutely require this. Because of this, I need a password generator that forces these things into the password or it isn't particularly useful for me. I'm in the process of switching all my passwords over and have had more than one occasion where the password generator spit out multiple (more than 3) incompatible passwords in a row, either missing numbers, symbols, or using incorrect symbols.
While I'd absolutely love an overhaul of the password generator allowing you to choose how many numbers and how many symbols you want in your password along with which symbols should be allowed (i.e. disallowing the < > symbols), I don't expect this any time soon (though hopefully at some point in the future). Right now, I just want a way to force numbers and symbols, if I have to refresh a few times to get the right number of symbols or numbers, for the time, that's fine, as long as it gives me at least one to start with.
1Password Version: 7.1.567
Extension Version: 1.8.2
OS Version: Windows 10
Sync Type: Not Provided
Referrer: forum-search:password generator
Comments
-
After additional testing, It seems I was likely wrong about my assumption on how it decides to grab numbers/symbols. I've been able to generate quite a few passwords in the last couple minutes in 1Password X that have just the numbers checked (no symbols) and do not include numbers (only letters). All passwords used in the above attempts were of 20 characters or higher, so this isn't an issue with the password just being too small. Six sites that I've replaced passwords on in the last week have required 6-16 characters (though they only actually accept a 15 char max) and at least 1 uppercase, 1 lowercase, 1 number, and 1 symbol, so I'm assuming this is just an odd bug, but an annoying one nonetheless.
My new assumption on the process is that the random generation function can sometimes be set to generate 0 of the selected type of character. Something akin to a php rand(0,5); where it will choose either 0,1,2,3,4,5 randomly.
Example: 20 character password with numbers and symbols selected
first chooses how many numbers between 0 and 5
chooses 0
then picks symbols between 0 and 8
chooses 5
generates 5 random symbols
then generates the 15 remaining upper/lowercase letters0 -
Despite having both symbol and number keys checked, the password generator does not always provide a password with those requirements filled.
@WakeArray: That's a perfect encapsulation. It's a difficult problem to solve without messing up entropy, but it's something we're actively working on. To be clear, 1Password isn't making a "decision" here; it's simply choosing a character for each position completely at random from the chosen pool of characters. But what you describe is a real usability problem. I think that @rob and @jpgoldberg may have come up with a good solution for this though, and as we roll out improvements to the password generator across all platforms you'll see the fruits of that labour. Thanks for bringing this up! :)
0 -
@WakeArray: I don't believe we have this in any public-facing version yet (though I could be forgetting something), but it's something we're testing internally. Looking forward to having the new password generator rolled out across all platforms in the future though. Cheers! :)
0 -
Hi, @WakeArray.
@brenty summed things up nicely, but since he mentioned me and you went to all the trouble of those tests not knowing how our generator works, I thought I'd help clear some additional details up.
I assume the symbols get favored over numbers due to there being 32 symbols on the US keyboard vs only 10 numbers.
This is correct. Although as Brenty said, we aren't actively favoring one set over another, rather simply choosing a character at random. We use about 20 symbols, and there are of course 10 digits and 52 alphabetic characters (uppercase and lowercase). Each time a character is chosen, the chance that it is a letter is higher than the chance that it is a number or symbol. And the chance that it is a symbol is about twice as high as the chance that it is a number.
It's possible from what I've seen on these forums about your password generation that the numbers and symbols are being grouped together.
In reality, as I started to describe above, all of the characters are grouped together in the same pool. You could picture it like a bag full of marbles: 52 red ones, 10 green ones, and 20 blue ones. They're all together in the same bag, and each time you pick one out at random, you return it to the bag. If you picked out 10 marbles this way, you'd likely end up picking at least one red, one green, and one blue marble, but you're not guaranteed to. In fact, you could pick out a green marble all 10 times, though it's not very likely. Similarly, with our current password generator, you could get a password that is entirely numbers, even if you have letters and symbols enabled.
I'm aware that forcing a user to use symbols and numbers rather than simply allowing it, does not make a password much more secure, but in the world we live in, many sites absolutely require this.
As you've noticed, this isn't practical. When you turn on numbers, you expect to get at least one number in the result. This means that there are actually fewer possible results because you are eliminating all results where the password has no numbers. However, for a password over 10 characters, the difference in password strength (entropy) is negligible, so we plan to change the generator to behave as expected rather than its current form, which can be confusing.
The way we will do this, though, is not by determining how many letters, numbers, and symbols to include, but rather by regenerating the password behind the scenes until there is a password that fits the requirements. In other words, it's like you hitting refresh until you get a good password, but the generator will simply do it for you rather than make you analyze the password. :)
Brenty mentioned "messing up entropy". Basically, it's a lot easier to calculate the true strength of a password the current way we generate them. But I've been working on the algorithm that will give us the strength of the passwords generated using this new method. It's been quite fun, and now we just need to get it into the apps.
I'd absolutely love an overhaul of the password generator allowing you to choose how many numbers and how many symbols you want in your password
This is actually how our password generator used to work, allowing you to select 0-10 numbers and 0-10 symbols. We changed it to its current form because it is better to have a random number of these characters than to choose the number explicitly. We don't plan to change this back. We've found that most sites require "at least 1" number and/or symbol, so being able to specify the exact number isn't that useful.
...along with which symbols should be allowed (i.e. disallowing the < > symbols)
We already disallow
<, but we are considering decreasing our symbol set even further. Choosing a longer password helps more than having more symbols to choose from.I hope that satiates your curiosity a little. If you have any other questions, I'd love to hear them. :)
0 -
@rob Thanks for taking the time to answer, the solution makes me laugh a little, but I imagine it's probably the best solution for the given issue and it should be fairly quick to implement. One thing though,
We already disallow
<, but we are considering decreasing our symbol set even further. Choosing a longer password helps more than having more symbols to choose from.Why disallow
<, but not>? I have yet to see a site that disallows one without the other.0 -
the solution makes me laugh a little, but I imagine it's probably the best solution for the given issue
It's the best we've come up with that also preserves our requirement of completely uniform distribution. Ideally there would be a way to deterministically generate a password that conforms to these rules, but we've not been able to create a deterministic algorithm that also produces a uniform distribution. If you know an expert in combinatorics that can solve this, we're hiring. ;)
Why disallow
<, but not>? I have yet to see a site that disallows one without the other.Good question. I think you're probably right, and it's one of the reasons we're looking at decreasing our symbol set. I believe the idea at the beginning was to avoid "opening" code symbols but allow "closing" symbols, but I will have to defer to @jpgoldberg for further explanation.
0 -
Our removal of “
<” from the list of symbols was prompted by a report from @Sc00bz several years back about a shopping cart system used by a number of websites that silently truncated passwords at that character. So if that were the 4th character in a 20 character password you created for such an afflicted site, you would actually end up with a three character password.0 -
Our removal of “<” from the list of symbols was prompted by a report from @Sc00bz several years back about a shopping cart system used by a number of websites that silently truncated passwords at that character. So if that were the 4th character in a 20 character password you created for such an afflicted site, you would actually end up with a three character password.
@jpgoldberg Thanks for the clarification, that is an amazingly bad bug for anyone using a password generation system. I understand why you removed that symbol.
It's the best we've come up with that also preserves our requirement of completely uniform distribution. Ideally there would be a way to deterministically generate a password that conforms to these rules, but we've not been able to create a deterministic algorithm that also produces a uniform distribution. If you know an expert in combinatorics that can solve this, we're hiring. ;)
@rob The mere fact that I think the solution can't be too hard is the exact reason why I pay for 1Password. I don't think I could hope to learn everything I'd need to know to build my own password keeper half as secure as this in only a couple years. I'm pretty sure I only know enough to get into trouble. :)
0 -
:lol:
0 -
The way we will do this, though, is not by determining how many letters, numbers, and symbols to include, but rather by regenerating the password behind the scenes until there is a password that fits the requirements. In other words, it's like you hitting refresh until you get a good password, but the generator will simply do it for you rather than make you analyze the password. :)
That made me chuckle, as I was reading this thread, I was thinking, they'd have some clever solution to generate the password so it matches the desired structure.
The thing I found most amusing, was that, that solutioni is exactly how I managed a random generation thing that had to fit a specific pattern for a silly game I created a few years back :).
websites that silently truncated passwords at that character. So if that were the 4th character in a 20 character password you created for such an afflicted site, you would actually end up with a three character password.
Yikes, that's awful.
I ran into a website registration form a while back that did something similar, but different. It silently removed all non-alphanumeric characters from the password. So a 20 character password with 5 non-alphanumeric characters would be changed to a 15 character password. The really weird bit, is that it only did that for the first password field, the 2nd password field it left alone.0 -
That made me chuckle, as I was reading this thread, I was thinking, they'd have some clever solution to generate the password so it matches the desired structure. The thing I found most amusing, was that, that solutioni is exactly how I managed a random generation thing that had to fit a specific pattern for a silly game I created a few years back :).
@numpty: Totally. But I think it's awesome that it's going to be automated and transparent to the user. I suspect once it rolls out in all the apps we'll get questions about how it works. It seems like magic. hehe
Yikes, that's awful. I ran into a website registration form a while back that did something similar, but different. It silently removed all non-alphanumeric characters from the password. So a 20 character password with 5 non-alphanumeric characters would be changed to a 15 character password. The really weird bit, is that it only did that for the first password field, the 2nd password field it left alone.
Yep. I think many of us have seen things we cannot unsee. :dizzy:
0
