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

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:

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.

-
Never came across a standard recommendation but would be interested to see your outcome later. –  tamimat May 8 '12 at 14:45
Is the length of the activation code flexible? Google's 2-step authentication uses 6 digits and is (I hope) secure. 6 digits would remove the "1/l" issues and still be challenging enough to brute force. –  Andrew Shipe May 8 '12 at 14:55
Could you find a solution that used a coupling between the entered phone number/email address and a phrase, where the user identifier coupled with the phrase is the activation code? E.g Activation code: 00468465599BananasAreBlueIndeed Where the prefix number is the phone number the user entered and the suffix phrase is a phrase provided by you. Just and idea, don't know how it would fit though. –  AndroidHustle May 8 '12 at 15:01
There should be some overlap on guidelines for issuing passwords where you'll get the same problems with ambiguous characters. –  PhillipW May 8 '12 at 15:04
Your sample activation code is also way too long. Over on English.SE someone suggested the character set A B C D E F G H I J L M N P Q R S T U W X Y Z 3 4. With this all-uppercase entropy pool of 25 elements, a code of only 3 characters only has a 0.0064% chance of being guessed ((1/25)^3). You don't need to annoy your user by forcing them to type in 12 characters. Software product activation keys are long expressly to prevent brute-forcing, which probably isn't a problem for you (i.e., expire the account after 3 failed attempts). –  msanford May 8 '12 at 18:06

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.

-
The plain text activation code suggested above work perfectly in URLs, too. Just use a hyphen instead of a space. –  Ben May 8 '12 at 17:44
I'll mention it to the team. –  brightgarden May 8 '12 at 17:45
Yes, do that! We humans should not have to type long, arbitrary strings. :-) –  Ben May 8 '12 at 17:49
On the other hand, this is more difficult for non-native speakers using your system. I can imagine my mom, who's able to use computer products in English, but is quite unable to spell anything. 6-char code is certainly easier for her than two English words, because she really has to treat the words as seperate symbols, instead of something natural. –  yo' Feb 18 '14 at 15:43
I have my doubts whether that is a problem. After all, (i) the words are spelled in the SMS and (ii) the users must understand some English anyway in order to understand the instructions. –  Ben Feb 23 '14 at 21:13

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.

-
I really appreciate the link to Tyler Hall's blog and its link to the source in GitHub. –  brightgarden May 8 '12 at 15:19
+1 for a good link! –  sree May 8 '12 at 17:25
I'd also add "UV" (which are easy to confuse when handwritten) and "9" (which can sometimes be confused for a lower-case g) –  BlueRaja - Danny Pflughoeft May 8 '12 at 20:13

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.

-
+1 for responding to user confusion and the XKCD method. See my answer for more specifics on Microsoft's activation codes. –  peteorpeter May 8 '12 at 15:46
You've still got some ambiguities there. In some typefaces, it's difficult to distinguish rn from m. –  TRiG May 22 '12 at 12:54
Good catch, though it had never come up yet in our case. It does help that we display our passwords in a fixed font for clarity, so the rn = m ambiguity has never hit us. But I have certainly seen that happen in other situations. –  Myrddin Emrys May 22 '12 at 13:16

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.

-
If you break the code sent into chunks please make sure that the form that takes it also does so in the same chunked format. Having a 16 digit code broken into 4 sets of 4 digits doesn't help much when you have to type all 16 into a single box and can't manually input delimiters. –  Dan Neely May 8 '12 at 17:46
@DanNeely: The way the enter-box works for activating MS products actually works quite nicely. –  André Sep 25 '12 at 8:00

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.

-
Nice link, and it's fascinating too. The wikipedia article comes very close to explaining the background and rationale for a character set that is easy for human transcription. –  brightgarden May 8 '12 at 16:51
This was the answer I was going to add when I saw this question. :) –  Fiona Taylor Gorringe Feb 18 '14 at 16:39

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.

Just like in Base-64, 6 bits -> look-up table of 64 Symbols like a A; In the encoding I propose, 10 bits -> look-up table of 1024 Words like Apple Mango –  Ujjwal Singh Oct 2 '12 at 4:27