Passwords not random
When generating the password I can use a slider to select how many numbers the password contains. At which setting are the passwords random, if at all?
I find this slider completely superfluous and confusing. Please replace it with a simple switch to include/exclude numbers.
Comments
-
The sliders are important to generate acceptable passwords for sites that have very specific requirements.
0 -
Password requirements usually concern the length and the type of characters (letters, numbers, special characters). Requirements to e.g. "have at least 5 numbers in your password" exist nowhere.
The sliders are superfluous. Replacing them with switches would bring the benefit of random passwords.
Currently 1PWs generated passwords may look random (as long as a 10 char password wasn't set to include 5 numbers), but they are not.
0 -
OK, if you say so. I'll have to defer to the security gurus among the developers.
0 -
If we for a moment put aside the question whether or not adding N numbers to a password significantly lowers the entropy of your passwords, and if we for a moment put aside the question whether or not the slider is confusing we can at the very least answer your statement whether or not "have at least N numbers" exists as password requirements anywhere.
must: …include at least one number and/or punctuation mark.
Source: http://its.virginia.edu/accounts/passwords.html
And Apple:
And Github:
And eBay:
… all require a minimum number of digits. I can bet you can actually find a dozen more like these if you tried looking for them.
0 -
On the question whether or not your password is less random (less safe) because you have a slider to choose a set number of digits. Let's do some on-the-napkin kind of calculation:
A truly randomly chosen case sensitive symbol from the entire ASCII character set has about 7.75 bits of entropy. A truly randomly chosen case sensitive symbol from the ASCII character excluding digits set has about 6.9 bits of entropy. A truly randomly chosen digit (0-9) symbol has an entropy of about 3.3 bits.
Therefore a 10-symbol password with 8 non-digits and 2 digits should therefore have an entropy of about 61,8 bits.
Where it instead chosen from the entire ASCII character set it would have an entropy of about 77,5 bits. In other words your password is at 80% strength compared to the mathematically perfect solution.
However, a 16-symbol password with 13 non-digits and 3 digits would have an entropy of about 110,7, which compared to a password randomly chosen from the entire ASCII character set which would have 124 bits of entropy. The less random password is now at 89% strength.
In other words, the penalty for using something less random is significant on short passwords, but diminishes quickly.
Please note: I am not a professional cryptographer and might have gotten something wrong.
0 -
So what? If such requirements exist, a user could press a "generate a new one" button until the pw contains a number or a special character. I guess some users like the playful interaction with the current sliders but there should at least be the option to override them.
Password generation, a core feature of a password manager, is done simply bad in 1PW.
0 -
You have claimed as such three times now.
Unfortunately I don't think you are making a good case for why you consider it bad.
If you look back at my post history you will note that I have asked for improvements to the symbol generation formula, so I don't think it is the best Agile Bits can do, but we have to be rational about the situation.
0 -
My reply was to your first post. My suggested improvements are to replace the sliders with four buttons (a-z, A-Z, 0-9, special characters) and a button to generate a new pw.
0 -
Plus maybe an option to force at least one char of each type to be in the password.
0 -
I have to agree with Florian here, every restriction on a password reduces the search space. The best passwords are long, unrestricted, random passwords.
In World War II the Germans used the Enigma cipher which was eventually broken by a Polish mathematicians and then improved on by the British. Breaking the code was still a brute force search but the search space was reduced because the procedures used by the Germans. Cables were used as a simple swap mechanism between any two characters and the correct cable arrangement was part of what was required to decode the message. Believing it made the encryption more secure, they wouldn't allow keys to be mapped to any of their immediate neighbours on the keyboard. The reality is this reduced the search space and the British used this knowledge against them.
In all the examples above they required the presence of at least one entry from each group (eBay didn't phrase it as such but actually it's no different). I don't know what the ideal interface looks like but I'd agree one that specifies the exact number of items from a group probably isn't it - just my opinion.
Just off the top of my head a password generator should be picking from as large a set of characters as possible unless told not to use a certain group, say under the title this site can't handle. You could then say this site can't contain symbols or maybe a text box for the only valid ones. If there are minimum or maximums on any other common group e.g. numbers, symbols etc. then you could stipulate that too but without having to say I want just x of from this set.
Times escaping me so I'll post this now.
0 -
Thanks for the suggestions. :)
0
