23

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.

enter image description here

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

enter image description here

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.

2
  • 7
    I don't think this is a UX question. If it is difficult to read the password than that is a font issue, not a password issue. Security of a password should not be compromised by limiting available characters. – musefan Jul 28 '20 at 9:13
  • 13
    Security is compromised if you end up having to copy and paste the passcode somewhere else with a readable font and the user experience is poor if you can not distinguish characters. – gman Jul 28 '20 at 9:35
27

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.

2
  • 23
    removing the vowels helps prevent random bad words. You can still get SHT and FCK but those aren't words – gman Jul 28 '20 at 13:39
  • 10
    FCK is a very famous word: google.com/search?q=FCKGW – Nayuki Jul 28 '20 at 17:34
21

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

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.

a Lastpass password using color for each type of character a Lastpass password using color for each type of character

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.

iPhone keyboard offering to paste one-time code from text message

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.

Google account verifying sign in

13
  • 8
    As mentioned in a comment on another answer, the monospace font only reduces the ambiguity if both similar characters are present. In your example, if the zero and one weren't at the start, e.g. R7OlB8 - I wouldn't know if that was supposed to be a letter (O) or a number (0) as the third character, and a letter (l) or a number (1) as the fourth character. Also, just using colour as the sole distinguisher isn't advised due to colour-blindness. – crazyloonybin Jul 28 '20 at 15:40
  • 2
    I do like the last option though, giving buttons to select whether to approve or reject the request, and get rid of the passcode altogether. – crazyloonybin Jul 28 '20 at 15:42
  • 2
    @crazyloonybin Good point about the monospaced being ambiguous without the reference between the similar characters and the color-blindness. Those 2 options are not meant to be applied in isolation but instead used together to balance each other's shortcomings. Color-blindness is common, but it is not a reason to avoid using color to communicate information; instead color should not be the only method of communicating info. – Benjamin S Jul 28 '20 at 15:49
  • 6
    "Use Color to Communicate" And now you have an accessibility problem. – Mast Jul 29 '20 at 10:01
  • 4
    @BenjaminS I'm normally sighted and that contrast makes the code difficult to read. – chrylis -cautiouslyoptimistic- Jul 29 '20 at 14:33
8

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.

6
  • +1 for the last paragraph about allowing confused characters to be accepted interchangeably. – Nathan Rabe Jul 28 '20 at 13:26
  • Crockford's Base32 is a good example of the suggestion in you final paragraph. – Džuris Jul 28 '20 at 20:56
  • @Džuris Clever! Thanks for the info! – maxathousand Jul 28 '20 at 20:57
  • 1
    Yes, typing the character I think it is and having it not be accepted is frustrating and accepting ambiguous characters interchangeably deals with that. But it's still frustrating to not be able to tell which character I'm seeing, on the assumption that ambiguous characters won't be accepted interchangeably (which is usually the case). Clarifying this in the UI could partially remove the frustration, but that probably wouldn't be worth it just to be able to increase your character set a bit. – NotThatGuy Jul 29 '20 at 10:24
  • Why is accepting 1 as an alternative for the letter I more secure than excluding I from passcode generation entirely? – Llewellyn Jul 30 '20 at 18:18
7

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).

1
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/

enter image description here

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.

  1. 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.

4
  • 3
    I can't tell that the glyph to the left of the 1 is a 0 or an O. If the random passcode ends up being 31523O62GW only a few geeks might notice that zero is an letter 'O' Similarly the glyph to the left if 'i' is only distinguishable if there are other characters to compare it to 742l934 – gman Jul 28 '20 at 9:37
  • 1
    Check the font specimen. They have a crossed 0 too. That makes more sense, to be honest. That's why I would incline to solution 2 here. – Lonut Jul 28 '20 at 9:43
  • 6
    My point is it doesn't matter the 0 is crossed. It matters that unless there is a zero on the page to compare the letter 0 to most people won't notice an O in the middle of several digits. – gman Jul 28 '20 at 10:42
  • (2) is not a magic solution either. German passport numbers do not contain the letter “O” so there’s no ambiguity with “0”. But few people know this, and because the font on the passport does not use a slashed zero, people routinely enter a wrong passport number into forms (using “O” instead of “0”), e.g. when booking airline travel. Of course electronic forms could catch this mistake, but only if they all encode country-specific rules and keep them up to date at all times. – Konrad Rudolph Jul 29 '20 at 8:25
3

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.

1

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.
4
  • The font advice has arguably been thoroughly discredited in comments. It doesn't matter that the characters are designed to be distinguished because if they aren't available for comparison then the differences don't help. If you get a code like 749O13 can the average user tell if that's seven four nine zero one three or seven four nine letter O one three. – gman Jul 30 '20 at 10:24
  • 1
    @gman Even if an elliptical glyph is potentially ambiguous, it's still better to use a font that makes it distinguishable than not. Just because it's not perfect doesn't mean it doesn't help. Likewise colour coding isn't a perfect solution either (It isn't necessarily intuitive, the user may be colour blind, or the display may be monochrome) I specifically said that bit of advice was for the case of the password generator itself being something that can't be changed. – smithkm Jul 30 '20 at 22:54
  • You seem to be mis-understanding. This topic is not about passwords, it's about passcodes. Entirely different topics. – gman Jul 31 '20 at 0:47
  • 1
    @gman Presenting arbitrary strings to humans so they can enter them elsewhere presents the same UI consideration whether they are generated by the system that's validating them or a separate system, and whether they are used for authentication, as checksums or as identifiers. Call it a "password", "passphrase", "passcode", "PIN", "checksum", "ID Number", or whatever, it's fundamentally a random or otherwise arbitrary number (or if it's not, something has gone wrong) presented in a way that hopefully makes it easier for a human to deal with. – smithkm Jul 31 '20 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.