Are there numbers and letters to avoid for activation codes via SMS?

Question

We are at a fairly early stage in our application development and have run into a usability issue related to typing an activation code sent via SMS into a browser URL.

Here's the basic scenario:

1. You can sign up with email or phone
   • if you sign up with email, you get an email with a link to activate;
   • if you sign up with phone, you get an SMS with a link to activate.
2. You click the link to activate, then set a password.

We had someone attempt this with a "dumb phone" (standard clamshell with no web browsing ability). This person did not have an email she felt comfortable sharing or using for our service. She proceeded to type the activation url into a browser on a desktop computer.

However, it turned out the activation code had enough confusing numbers and letters in it to require multiple attempts before getting it right (e.g., ones and zeros were hard to distinguish, "l" or "1" or "O" or "0").

Sample activation code: AX6elp90grPo

Initial Fix

We plan to address the immediate issue by "guessing" which letters and numbers seem easy to confuse with each other and eliminating them, or always using one (e.g., anything that looks like a "1" is always a "1").

Question:

I was wondering if there is already a standard recommendation or practice for situations like this (specifically, which letters or numbers should be eliminated)?

I'm also open to any other relevant suggestion, including how better to handle activation information over SMS.

Answer 1

Since you really seem to care for your users and think through your interface, I have one suggestion: Users should never have to manually type arbitrary codes!

Instead, just generate a code from a freely available English wordlist:

Your activation code is "Large Sinister"

Of course, interpunctuation, capitalization and spacing should not matter.

Edit: http://wcodes.org/ , as pointed out by other answers, is probably a good library to use.

Answer 2

Yes there are examples of how to solve your issue. pwgen has a list of ambiguous characters: B8G6I1l0OQDS5Z2 (it's in this file if you can read C code).

Another code-snippet is here, in PHP this time.

The former approach is using a "blacklist" approach, the latter instead a "whitelist" one.

Answer 3

In general, assigned passwords should avoid ambiguous characters. An example is Microsoft activation codes; they do not use the letter O because some people might type a zero (0). Similarly, you should trim your allowed characters to remove any ambiguous or confusing ones from the set of possibilities. For example, this is the character set I use in generated passwords:

abcdefgh  k mnop rst  wx zABCDEFGH JKLMN PQR T  WXY 34 6 89

Any time a user called in because they failed to differentiate a character properly, it got removed from the list. This is why 2, 5, S, and Z got removed... I didn't think they were ambiguous, but they were after the user wrote them down.

I would like to add... if I recreated this password generator today, it would use the xkcd method (also used by AOL) of random short words.

Answer 4

Base 32 encoding is a standard defined with this purpose. There are several variants, but all of them try to avoid ambiguous characters. This is the rationale from the article linked:

Base32 is a notation for encoding arbitrary byte data using a restricted set of symbols which can be conveniently used by humans and processed by old computer systems which only recognize restricted character sets.

Answer 5

Microsoft has has to deal with user-legible activation codes for a long time. I suspect they have put some science into their decisions. I had a pile of activation codes from work to analyze. Here's a faked example code:

V3MKH-7GMWJ-PHRWW-Q9RD3-M84FR

Firstly, all letters are UPPERCASE. This move alone should eliminate quite a bit of confusion. (I realize that removes entropy - if you had to, you could make that up by increasing the length slightly. What I'd actually recommend is presenting uppercase letters, but accepting either case for input.)

Looking across 31 codes with 25 characters each (775 characters total), the characters they did not use were:

A E I L N O P S U Z

0 1 5

Lastly, note that they break up their codes into chunks. I won't venture to guess how long a code would be before breaking them up would be useful, but you might consider this for experimentation.

Answer 6

What you seek is an efficient Human-Computer code. What I recommend is to encode the entire data with literal(meaningful) words, nouns in particular.

I have been developing a software to do just that - and most efficiently. I call it WCode.
Technically its just Base-1024 Encoding - wherein you use words instead of symbols.

Here are the links:
Presentation: https://docs.google.com/presentation/d/1sYiXCWIYAWpKAahrGFZ2p5zJX8uMxPccu-oaGOajrGA/edit
Documentation: https://docs.google.com/folder/d/0B0pxLafSqCjKOWhYSFFGOHd1a2c/edit
Project: https://github.com/San13/WCode (Please wait while I get around uploading...)

Answer 7

One more vote (if I'd have reputation) for making the string itself easier to remember, like WCode or Ben's answer with "Large Sinister". On the international and technical side of things, the character set used should be http://en.wikipedia.org/wiki/GSM_03.38