I recently saw the movie Olympus Has Fallen.
Like in many action movies, at the end a missile is launched, and the hero (Mike Banning, played by Gerard Butler) has 60 seconds to recall the launch in order to prevent a disaster. (Spoilers!)

The way to recall it is by inserting a password, but Banning doesn't have the password. Instead, he has radio contact with the pentagon, who do have it.

So the person from the pentagon is reading the password to Manning over the radio: "Lima, Charlie, Hashtag...". But Banning doesn't have a clue what a hashtag is, so he yells: "What?" And the pentagon perso repeats: "Hashtag?" And time is running out... And then someone else from the pentagon yells: "Shift 3!".

And America is saved...

After the movie was over, I thought a lot about that scene. I realize that in real-life there are rarely cases in which a password should be read out loud (most of the time, if it happens, it's because people share passwords, and that's a different problem...).
But here is a case in which the only way to get the password is by saying it over the phone, and it's not a personal password - it's a password only used in an emergency, by whomever has access to the missile launch dashboard.

Now, I know there are various guidelines for passwords: How to make them easy to remember but hard to guess, how to avoid confusing characters, etc. But has anyone come up with rules for over-the-phone-read passwords? I agree, it's a small niche, but at least according to Hollywood – it could be crucial…

enter image description here

To be clear, this is not about "how to read it", but rather "how to choose a password that CAN be read, but is still strong".

UPDATE: Here is the scene, 1:30 minutes on YouTube.

  • 21
    Could have been a problem if he was using a UK keyboard like mine - Shift+3 is £ Commented Aug 7, 2013 at 15:47
  • 4
    Can't help but think that saying "pound key" or even "number sign" would have been much easier than saying Shift + 3
    Commented Aug 7, 2013 at 15:57
  • 28
    Imagine a hacker on the phone yelling "Octothorpe! Octothorpe!" :-) Commented Aug 7, 2013 at 17:18
  • 5
    I hear using Japanese phonetics is quite effective.
    – user3490
    Commented Aug 7, 2013 at 23:10
  • 5
    There are far more annoying passwords to read out over the phone, how about "One1TheFirstJustTheNumberTheSecondSpelledOut"
    – Morphed
    Commented Aug 8, 2013 at 7:53

5 Answers 5


The solution is simple and is already widely practiced: don't use any special characters in passwords.

When a password is read out loud, there are many steps that can go wrong:

  • The reader must read the password correctly. Is that a ( or a [ or a {? Is that a - or a _? Is that a l or a I or a 1? Is that a : or a ;?
  • The reader must enunciate the character correctly. Believe it or not, some people don't believe that " is called “parenthesis”.
  • The listener must understand the character name. That's the same problem as with the reader. Remind me which one is backslash? And what would you type if you hear “dash”?
  • The listener must find the character on the keyboard. Shift+3? Imagine you need to save the world from Germany (§) or Spain (') or France (3)!

There are 95 printable characters in the ASCII character set, which is all you can expect to find on a PC keyboard. On a Mac or mobile device, even some ASCII characters can be hard to type. (Try typing | on a French Mac.) If you generate a random password with n printable ASCII characters, there are 95n combinations. If you restrict the password to a smaller character set containing only C characters, then in order to have as many possible combinations (i.e. as much entropy), you'll need to make the password longer. There are Cm passwords of length m, so you need to achieve Cm ≥ 95n, i.e. m ≥ n × log(95) / log(C). Here are a few values for the multiplicative factor:

  • Using only letters of either case and digits: m ≥ 1.103 n. Up to n=9, it's enough to add one more character.
  • Using only letters of either case and digits, excluding l, o, O, 0, and 1: m ≥ 1.127 n. Now one more character is enough up to n=7; for n=8, you get a very slight reduction in strength with m=9.
  • Using only lowercase letters and digits: m ≥ 1.271 n. For example, instead of 7 arbitrary ASCII characters, you'd need 9 characters with this restriction. With n=8 you'd need m=11 (or m=10 if it's ok to slightly reduce the strength).
  • Using only lowercase letters and digits, excluding l, o, 0 and 1: m ≥ 1.314 n. For n=7 you now need m=10, for n=8 you still need m=11.
  • Using only lowercase letters: m ≥ 1.398 m. Instead of 8 arbitrary ASCII characters, you need 12 lowercase letters to achieve the same strength.

In this case where the password needs to be communicated quickly over the phone, I'd go for either the second option above or the last one: mixed case but avoiding the most confusing letter (requiring the password to be about 13% longer), or sticking to letters of one case (requiring the password to be about 40% longer).

A lot of systems impose passwords that contain mixed case and punctuation. This is well-known to be counter-productive. For security, it's the entropy that matters, not the choice of characters used to encode this entropy. For usability, the choice of characters is relevant, and up to a point (where the password gets too long) less is better.

  • For usability, especially on phones, it’s not the number of letters but the number of key presses that counts. Something like a@A1=N takes a lot of key presses.
    – gnasher729
    Commented Jan 22 at 23:02

Microsoft already has done something like this with their product key alphabet. They selected a subset of characters that are distinctive, and excluded characters that could lead to either confusion or offensive words.

The 24 used are: 2346789BCDFGHJKMPQRTVWXY

The 12 unused are: 015AEILNOSUZ

The hyphen character is used to separate five character groups, but is not significant.

Product keys are broken into five character groups, separated by hyphens for readability. The fifth character of each group serves as an independent check character, ensuring only that the group of five was typed correctly. (It's just a check sum, and doesn't indicate if that group is part of a valid password or not.)

Why this relates to you is that if you are generating passwords, these can be completely unambiguous whether spoken or typed. Nobody has to ask "Oh or zero?" "Two or zed?" There are no symbols that can cause the difficulties you encountered. Furthermore, you would translate them to upper case in software to avoid case issues. And they are common to all languages that use the Latin alphabet.

The drawback is that with only 24 possible symbols, one character can offer only 4.8 bits of unpredictability. For equivalent security a password has to be three times longer than a password that can have upper case, lower case, numeric digits, and symbols. To that, add another 20% for the check characters. That makes every 128-bit password a hefty 35 characters long, or seven groups of five. (Microsoft's five group scheme offers 96 bits of uncertainty.)

  • 4
    This is a great answer, but I'm curious about the source of this information. Do you have a reference for this?
    – Steve
    Commented Aug 8, 2013 at 3:22
  • 1
    Thanks for a great answer. But isn't 35 characters a little long, especially if there is a time limit, such as 60 seconds?
    – Lea Cohen
    Commented Aug 8, 2013 at 9:23
  • 3
    @SteveS, this is an observation and analysis of what Microsoft has been very successful at using over the last 10 years. I edited the question to remove the assumption that they did research on the topic (although I'm sure there was usability research done.) The rest of the information is easily observable - the characters in use and not in use, letters with confusingly similar shapes to numbers are omitted, vowels that lead to bad words are omitted, case insensitive, auto-error if any member of a 5 digit group is mistyped, etc. And the rest is just math. Commented Aug 8, 2013 at 17:12
  • 1
    @LeaCohen, I obviously don't know how the military protects their nuclear missile launch codes, nor how much time they allow someone to type a mythical "abort" sequence, but if the end of the world is at stake, is 35 characters enough to protect it? :-) Commented Aug 8, 2013 at 17:16
  • 3
    Your answer removes visually ambiguous letters, which will prevent whoever's reading the password from getting it wrong, but we should also be concerned with phonetically ambiguous ones to prevent the person hearing the password from getting it wrong. If you remove N, for example, then you'd surely want to remove M as well. Otherwise you risk hearing, "did you say em or en?" from the recipient. Whoever is hearing the password wouldn't know that their options have been restricted. So phonetically ambiguous letter groups should be removed too: [M and N], [P, D, and E], [G and J], [C and Z].
    – Nick
    Commented Aug 10, 2013 at 9:31

The ICAO/NATO phonetic alphabet is used primarily to distinguish between letters that sounds the similar when spelling them, like d and b, or n and m. All of the other special characters cannot be spelled, they have their own names.

# is a pound sign or a hash sign, & this is an ampersand, and so on.

The Australian Amateur Radio Service Emergency Communications has a training manual that talks about that.

Alphabet phonetics: Alpha, Bravo, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, India, Juliet, Kilo, Lima, Mike, November, Oscar, Papa, Qubec, Romeo, Sierra, Tango, Uniform, Victor, Whisky, Xray, Yankee, Zulu.

Numeral phonetics: Zero, Wun, Too, Thuh-ree, Fo-wer, Fiy-iv, Six, Seven, Ate, Niner.

Punctuation: Full Stop, Comma, Slash, Dash, Colon, Semi Colon, Quote, Unquote, Open Bracket, Close Bracket, At Sign.

Other sources even list almost all needed special characters:

enter image description here

  • 2
    The problem is that not all of those symbols really lend themselves to being read out loud, unambiguously. Then there is the complications of keyboard layouts, as @razethestray mentioned, and different names for some characters, as DKNUCKLES noted. Bottom line, if you remove the ambiguous characters - and that would (apparently) include any case-sensitivity - how much does that harm the entropy of the password? How should the password selection process be modified, given these constraints?
    – AviD
    Commented Aug 7, 2013 at 16:49
  • 1
    Also note that the question is about generating such a password, that would lend itself well to unambiguous-reading-aloud, as opposed to a general "how do I spell this aloud".
    – AviD
    Commented Aug 7, 2013 at 16:51
  • 1
    @AviD Well, I kind of felt this doesn't fully answer the question, I forgot to post it as a CW.
    – Adi
    Commented Aug 7, 2013 at 16:52
  • 1
    @AviD Also, I don't see how case sensitivity and keyboard layout is a problem here. An Upper Alfa is an Upper Alfa on all keyboards, a Percent Sign is a Percent Sign on all keyboards.
    – Adi
    Commented Aug 7, 2013 at 16:54
  • 7
    And on my keyboard a pound sign is very different to a hash sign. As in, it looks like a pound sign. Surely no one thinks that in Britain we write #5 to mean £5?
    – Rory Alsop
    Commented Aug 7, 2013 at 17:39

"Reading aloud" is about enunciating a sequence of "phonetic symbols" in due sequence. You want these symbols to be unambiguous when pronounced. It so happens that we humans have such a system: it is called words. When I speak a sentence, it consists of a lot of words, which other people don't have trouble understanding because their brains are highly trained, from their prime infancy, to do such a thing.

So what you want is a nice "alphabet" of words which are easy to make apart, as well as a convention for turning the words into the characters you type. The convention with Alpha = A, Bravo = B, Charlie = C... is just that: a set of 26 symbols, each being encoded as one letter. Each symbol, randomly generated in the list of 26, is worth about 4.7 bits of entropy (because 26 is almost equal to 24.7), so just generate as many as needed to reach the appropriate entropy for your target security level. 20 letters ought to be highly sufficient for most purposes, including launching nuclear missiles (that's 94 bits of entropy; anything beyond 80 bits is really good).

Another similar method is the famous one which leads to passwords like "correcthorsebatterystaple". In this case, we have a "list of common words", assumed (in the comic) to contain 2048 words. These are your symbols. Each is worth 11 bits of entropy (because 2048 = 211), so eight words would bring you to the very comfortable level of 88 bits. The symbol-to-keystrokes convention is then: type the whole word. Such passwords have the distinct benefit of being easy to remember, easier than sequences of random letters. However, they imply more key typing.

The longer the symbol list, the more probable confusion can occur. For instance, you say "battery staple" but the secret agent at the other end of the line understands "bat tryst apple". Also, I would not like the idea that the nuclear safety of America relies on the spelling skills of some field agent: he is highly trained at beheading enemy spies with his bare hands, but will he know that "battery" is not spelled "batery"? It's not like password entry fields contain spell checkers...

I thus tend to consider that the best passwords that can be "read aloud" are sequences of random letters. Sequences of digits could be used, too: less entropy per digit (3.32 bits), but we have decades of experience about customers reading out their credit card number through a phone line to some underpaid operators, and this works. In any case, as with all password things, randomness reigns supreme: make each symbol a random uniform choice, independent of the other symbols, and accumulate as many as necessary to reach the entropy goal.

  • You make an interesting point about a long series of numbers and layperson clarity.
    – schroeder
    Commented Aug 7, 2013 at 22:35
  • Thank you for this analysis! However, I'm wondering about the conflict between entropy and length: if the password is too long, it could take too long to read it over the phone, and in this case, time is crucial...
    – Lea Cohen
    Commented Aug 8, 2013 at 9:17
  • If passcodes are assumed to be strings of common words, a system could accept passphrases whose words are sufficiently "close" to the correct ones without really harming security (someone listening for spoken password FAX who rejected "foxglove alpo extra" because it should be "foxtrot alfa x-ray" would ignore the fact that the speaker knew the letters "FAX", which is what's supposed to really matter.
    – supercat
    Commented Feb 2, 2014 at 22:11

The PGP word list comprises 2 × 256 words (two sets are used as an error detection method) chosen carefully for phonetic distinctiveness. For instance, E582 94F2 becomes "topmost Istanbul Pluto vagabond".

  • But are users required to memorize that whole long list, to translate each code word to byte value?
    – AviD
    Commented Aug 9, 2013 at 10:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .