Feature Request - easier mobile passwords

Vaneyen

This is a feature I'd like to see in every password generator that is compatible with Android devices. It has less value for iOS devices from Apple, but only because the standard keyboard has a separate number row, and there is no capslock that I'm aware of.

I would like the option to restrict the number of state-transitions that are necessary to manually key in a password.

For example, the password (randomly generated 20-char password with lower,upper and numbers):
VjAK31Sj1DuebW37ZO7T
...results in the following when entered on an Android device:
[shift]Vj[capslock]AK[capsunlock][number]31[alpha][shift]Sj[number]1[alpha][shift]Dueb[shift]W[number]37[alpha][capslock]ZO[capsunlock][number]7[alpha][shift]T

(for those paying attention, any pair of capitals can be either [capslock]XX[capsunlock] or [shift]X[shift]X, but that's the same number of transitions.)

This is a total of 37 keystrokes to manually enter the password.

Compare that to the same password, where the transitions are reduced:
VAKSDWZOTjjueb311377
...which results in the following when entered on an Android device:
[capslock]VAKSDWZOT[capsunlock]jjueb[number]311377

This is only 23 keystrokes, for the same strength of password. A huge savings, at no additional cost!

This only requires that the password, after generation, be parsed to determine the order of character sets, in this case, Upper, lower, and number. Then, reorganize the password so that all of the characters of a particular set are together.

The only thing to add is to avoid "easily-confused characters" at the beginning or end of a transition (for example, "hnul16450OHSK", because the "l1" and "0O" are confusing, but "hnlu61405HOSK" is fine because the confusing characters are in the middle of their sets.)

I have been doing this manually for years, but I would love it if this became commonplace for password-generating apps!

Henry

Hi @Vaneyen! Quite simply, we don't do that transformation because the value of generated passwords is that they are completely random. Though I completely agree that your "easier mobile passwords" would be easier to type manually, for most people that benefit would be negated by the decrease in their security due to their lower entropy.

Additionally, part of the value of 1Password (and the apps available for just about every device) is that you never have to type your passwords manually again. On iOS, we have an extension compatible with websites and many apps, along with Quick Copy and drag and drop that can be used all across the OS. On Android, we have two wonderful filling services compatible with all devices Android 5.0+, along with drag and drop (even on phones!) for devices Android 7.0+.

If you need help getting any of those set up so you don't ever have to type out your passwords again, let me know. :)

Vaneyen

Please allow me to politely disagree with the decreased entropy argument, especially in light of many sites blocking keystroke playback and cut-and-paste (notably government websites and banks), quoting attack vectors such as the one now used by the new banking Trojan called ‘BackSwap’ (https://www.cbronline.com/news/banking-trojan-backswap). There are even bloggers who are promoting that websites block cutting-and-pasting passwords as a way of increasing security (https://paul.reviews/dont-let-them-paste-passwords/). To simply view this through a "users never need to manually type passwords" lens is missing the much larger picture. I'd rather see your tool (and others like it) see options to become more relevant in the bigger picture.

This is why it should be given as an option (never as a default), for those users who see the benefit of offsetting the slight decrease in entropy by a major increase in usability, especially since adding just one more character more than offsets the loss in entropy. Even through I use LastPass as my password manager, there are enough times that I still need to key a password in, for one reason or another, and copy-and-paste simply doesn't work. For those times, I see great value in having this option, especially for passwords that have to be manually keyed in multiple times.

I'm not the only user who thinks this could be beneficial, and one developer (https://github.com/cxam/) has actually taken the time to create a javascript to do exactly this (https://www.jasonpearce.com/2015/07/06/generate-mobile-friendly-passwords-with-passed-pw/), though I'd like to see it embedded within a solid password manager, rather than as a browser add-on.

AGAlumB

@Vaneyen: I get where you're coming from, but Henry is right about entropy. Essentially, generating a password according to the criteria you've laid out gives up an incredible amount of entropy. Using your example — VAKSDWZOTjjueb311377 — you've got this situation:

Capitals:
log2(26) = 4.7004397181 <- bits of entropy per character
4.7004397181(9) <- length of password
= 42.30395748 <- bits of entropy total

Lowercase:
log2(26) = 4.7004397181 <- bits of entropy per character
4.7004397181(5) <- length of password
= 23.5021986 <- bits of entropy total

Digits:
log2(10) = 3.3219280949 <- bits of entropy per character
3.3219280949(6) <- length of password
= 19.93156854 <- bits of entropy total

85.73772462 bits of entropy in all — which is already not great, and, in fact, is a bit of a cheat since the whole thing is not truly random. But we'll let that slide for sake of comparison.

The same character set and length with a truly random password looks like this:

log2(62) = 5.9541963104 <- bits of entropy per character
5.9541963104(20) <- length of password
= 119.0839262 <- bits of entropy total

About 34 bits difference. And keep in mind that adding one bit of entropy to a password doubles the number of guesses required. So what you're proposing is not only many orders of magnitude weaker, it's also deceiving in that it looks much stronger than it really is. So I doubt we'll do anything like that. There's a lot to lose and not much to gain.

Fortunately, there's a better way. Apart from Henry's good suggestion to use one of the many filling options available to avoid this whole mess entirely (the practice of blocking filling/paste is not nearly as common as you suggest, and 1Password can often work around it anyway), the 1Password desktop apps already have a way to generate passwords that are not only easier to remember, type, and communicate, but also potentially stronger:

log2(18000) = 14.135709286 <- bits of entropy per word
14.135709286(7) <- length of password (words)
= 98.94996503 <- bits of entropy total

For example, I really don't have much hope of managing something like this myself:

VAKSDWZOTjjueb311377

Which, of course, is why we have 1Password. But Wordlist passwords have the benefit of being much more human-friendly in addition to being secure:

furnace schnapps guy toque folk aweigh sibilant

I can read that to myself and type it in a matter of seconds. So, since we can get strong passwords that way which are even more usable, we'll continue to recommend that for cases where something human-friendly is needed, and character-based passwords for all other cases, since, character for character, those will always be the strongest. :)