Passcode generation guidelines?

Question

Is there any kind of guidelines on passcode generation with regards to UX?

In particular I just ran into a site that used auto-generated codes but the codes it made were impossible to tell if a letter was a D an O or a 0. I i l 1 can also be indistinguishable depending on the type style.

This would seem like it should be a common UX guideline, never generate codes with those characters. Maybe even U V u v should be removed. g q and 9, 6 and G as well. Next to each other sometimes these are more obvious but in a random code it's not always clear.

Do such guidelines exist and are there any other characters that should be avoided? Maybe ! is another one?

Note: this question is not about passwords, it's about passcodes (maybe there is another name). A password is something a user can possibly create. A passcode is something a computer creates like emailing you a 6 character code to type in.

For example Apple will popup a 6 digit number, a passcode, on an registered Apple device when you try to log into icloud.com. Apple doesn't have the UX problem above because their passcodes are only digits, no letters.

Conversely some other site had a 10-15 second puzzle to solve, once solved it showed a code

Is that code BB1CA1O8? BB1CA108 ? BB1CA1D8?

Get the code wrong and you have to re-fill out the form and solve the 10-15 second puzzle again

Note: Obviously if you have 0 and O next to each other you can probably tell them apart. But if you the passcode it shows you is Z35O96 it's not going to be obvious to large percentage of users if that's a letter O or a number zero.

Answer 1

Microsoft chose to skip the characters A, E, I, L, N, O, S, U, 0, 1, & 5 for their Xbox Live codes.

Based on this question and answer it appears that they chose to reduce the possible characters to reduce confusion. Some like O & 0, S & 5 were probably dropped for visual similarity, while others like E & N may have been dropped for audial similarity with other letters when spoken.

However, they kept both B & 8 which are visually similar. It is also curious that they removed all vowels (A, E, I, O, U) except for Y, but that could be a coincidence.

Answer 2

There is no UX guideline specific to passwords, but several usability heuristics can be applied to this use case:

• Error Prevention: eliminate error prone conditions (NNGroup Usability Heuristic #5)
• Keep it Simple (Lund's Usability Maxims #10)
• Reduce Short-term memory load (Shneiderman's Golden Rule of Interface Desgin #8)

Mono-spaced Fonts Reduce Ambiguity

Below is an example of how the mono-spaced font differentiates characters often confused with one another.

01OlB8

Use Color to Communicate

Color can easily help differientate characters as well. Lastpass on iOS does this well by assigning a different color to letters, numbers, and special characters.

Skip Memorization Completely

This is the golden solution to eliminate ambiguity and reduce short-term memory load. The character count and ambiguity of the numbers and letters don't matter if the user can use the passcode without memorizing it.

If it is an option, the application should offer to copy-paste the passcode for the user.

In other instances, 2 factor authentication can allow a user to simply verify themselves on the trusted device to give access to the untrusted device. Google handles this particularly well.

Answer 3

There are no standard guidelines of which I am aware; what I've observed most often is that, when dealing with issues of security like this one, companies prefer to evaluate their own security model and implement what they feel is best for their interests, rather than adopt a one-size-fits-all standard model.

Option: Eliminating ambiguity

Conveniently, this same problem is present in another common use case: automobile license plates. Much like the passcode your mention here, the alphanumeric sequences 1) appear to be just a random assortment of meaningless characters, and 2) must be unambiguously legible.

There is some variation in license plate implementations (e.g. each state in the United States determines its own manner in which it issues license plates), however, most states will omit the letters I, O, and often Q to help mitigate some of the ambiguity.

Option: Accepting ambiguous characters interchangeably

There is another solution to consider: if you do not want to limit the character set of the generated code (which, in my opinion, is probably the easiest solution), simply accept both I/1 and O/0 in each others' places. This is sacrificing only a hair of entropy for the convenience of automatically resolving ambiguities in the passcode. Whether or not this increases or decreases the mental load of your users could be the topic of some quick user testing.

As @Džuris mentions, this strategy is employed by Crockford's Base32 encoding scheme.

Answer 4

LastPass's password generator has three options:

• easy to say (avoid numbers and special characters)
• easy to read (avoid ambiguous characters like l, 1, O and 0)
• all characters

Unfortunately, I could not find anything more specific about the implementation.

1Password has a 'memorable password option' which concatenates 4 random English words together similar to the famous xkcd comic (correct-horse-battery-stable).

Answer 5

There are 2 solutions here:

1. You can use a monospaced font that is solving this problem. One example is IBM Plex font. You can check it here: https://www.ibm.com/plex/specs/

To consider: You need to put in balance where you will display this code too. For smaller sizes screens you might still have a problem with any font you choose. Also, this is not great when you need to send the user an email with that code, you will need to use a system font for that and you hit this problem again.

2. You can avoid using those characters that generate confusion for the user and solve this problem from the start. If it's a passcode that is generated automatically it will not be a problem if you remove those problematic characters. This solution will not work if the user will set this code manually.

After analyzing this I would pick solution number 2, it's solving the problem from the beginning and you don't have to deal with it anymore.

Answer 6

The only published guidelines I know of are about making sure that any text displayed is legible by appropriate choice and usage of fonts, contract, size, etc. The guidelines are intended to make sure all text is legible and require you to have a fairly high degree of control over the final display. If you are printing 5x7 dot matrix characters in red on a black background, you are going to have serious problems no matter what symbols you use.

The rule of thumb, as I know it, is to

• Use only uppercase Roman letters, excluding I, O, Q, and S, and numbers 2-9
• Accept lowercase letters for their uppercase counterparts.
• Accept i and I for 1, o and O for 0, s and S for 5
• Eliminate B you are concerned about differentiating it from 8 (based on the range of output devices). If you eliminate B, accept b and B for 8.
• Likewise eliminate M and W if your display is low resolution and those characters are difficult to make out, but this is rarely a problem these days.
• Eliminate A, E, U also if you are worried about words showing up in the code.
• If the code is more than 7 characters, break it up into smaller chunks, separated by hyphens.

Side note: it still bugs me that images on the "Golden Record" sent out on Voyager to introduce ourselves to some alien culture use the same glyph for zero and capital oh. Like it was not hard enough to figure out an alien alphabet, you had to also figure out that one of the characters was actually 2 different ones.

Answer 7

IF the generator for the text strings in question is a fixed technical requirement and can not be changed.

If possible use BOTH a font that makes the characters as distinguishable as possible such as a font intended for software development like JetBrains Mono AND colour code the character classes (alphabetic, numeric, other) NEITHER is a is a perfect solution by itself and even BOTH together is less than ideal, but it should give the user the best chance possible given a generator that produces potentially ambiguous characters. As with any colour based UI you should consider colourblindness.

Even with other solutions that alter the generated string, its still a good idea to use a font optimized for individual character recognition. Especially important, if the digit zero is possible, even if the capital letter O is not, use a font with a dotted or slashed 0 glyph, preferably dotted. It would also be a good idea to use a font with lining rather than old style digits if the string contains digits.

IF the generator can be altered to accommodate usability concerns and compactness of the string is concern

A very simple solution would be to just use hexadecimal. Just about any platform you might be using should have the ability to produce a hex representation of a number easily and many people have seen it before even if they don't recognize what it is so you gain at least some potential familiarity. If you use hex, make it case insensitive.

Even just decimal would be viable although a comparable string would need to be somewhat longer.

A curated character set that eliminates potentially confused pairs and is case sensitive using characters readily typed on most keyboards can be notably shorter but it much less friendly to a human. This set is 50 characters for instance but it requires the user type random capitalization correctly.

34678ABCDEFGHJKLMNPQRTUVWXYabcdehkmnprsuvwxyz@#%&*

A longer but easier type string is probably better for most users.

If using numeric codes, make sure to use a font with a dotted or slashed zero to be safe. For hex or curated characters it might still be worthwhile to highlight the character classes in different colours just to provide a bit of additional context for the random string of characters.

IF the generator can be altered to accommodate usability concerns and readability is more important than compactness

Use a string of randomly selected words. This is conceptually no different from a string of random character except using a dictionary of words in place of an alphabet of characters. Fewer words are needed than characters provided the number of words in the dictionary is larer than the alphabet. The overall length of the string will still be longer than a comparable "character" based string though.

If you see the word "call" that's obviously two lower case 'L's even in a font that makes 'l', 'I', and '1' hard to distinguish. This is a particularly useful approach if the string might need to be dictated to another person.

You can improve the human friendliness by giving the random string a grammatical structure to mimic a sentence. "adjective noun(plural) verb(plural 3rd person simple present) adverb" works well for English. It could be extended with "preposition adjective noun(plural)".

The result is semantically nonsense, but it fits the random information into a form where humans are good at handling it.

Besides length, the downside of this approach is it's more complicated to create, and if you need to handle different languages they each need their own dictionaries and if used, grammar templates. You also need to be aware of homonyms and other easily confused words and words with multiple spellings (their/there, colour/colour, accept/except)

Examples of this idea in slightly different contexts are the Diceware password scheme, the Jitsi Meet conference software which generates nonsense sentences as meeting IDs, or the PGP Word List for dictating key fingerprints over the phone. The EFF also provides alternate word lists for Diceware that could be leveraged for your use case.

Hybrid approach

You could even use multiple approaches together.

Start by generating a random 32bit unsigned integer.

Present it as hexadecimal.

Turn each byte into a word from a list of 256. You could use the PGP Word List or use 4 lists of 256 (Adjectives, Plural Nouns, Verbs, Adverbs) and fit them into the template "adjective noun verb adjective"

That gives a set of words that have the exact same information as the hexadecimal. The validator can then look at what the user types and decode it as either hex or code words to get the number.

You can send both and instruct them to use whichever they prefer, or have a toggle to switch which is displayed to them, or make it an option they set ahead of time depending on the situation. Similar word lists of 256 could be made for other languages that need to be supported and the hex provides a fallback for unsupported languages.

If you want to up it to 64bit you could use the template "adjective noun verb adjective when adjective noun verb adjective"

Abstract skies drop how when urban carbons teach this.