
Passwords for JetBlue accounts cannot contain a Q or a Z - alexdmiller
http://help.jetblue.com/SRVS/CGI-BIN/webisapi.dll?New,Kb=askBlue,case=obj(403864)
======
dredmorbius
As several people have noted, the Q/Z restriction likely arises from inputting
passwords from a telephone keypad.

What I haven't seen is a statement as to why this would have been a problem.
The reason is that Q and Z were mapped _inconsistently_ across various phone
keypads. The present convention of PQRS on 7 and WXYZ on 9 wasn't settled on
until fairly late in the game, and as noted, the airline reservation system,
SABRE, is one of the oldest widely-used public-facing computer systems still
in existence, dating to the 1950s.

[https://en.wikipedia.org/wiki/Sabre_(computer_system)](https://en.wikipedia.org/wiki/Sabre_\(computer_system\))

The 7/9 standard, by the way comes from the international standard ITU E
1.161, also known as ANSI T1.703-1995/1999 and ISO/IEC 9995-8:1994).

[http://www.dialabc.com/words/history.html](http://www.dialabc.com/words/history.html)

Other keypads may not assign Q or Z at all, or assign it to various other
numbers, 1 for Australian Classic, 0 for UK Classic and Mobile 1.

[http://www.dialabc.com/motion/keypads.html](http://www.dialabc.com/motion/keypads.html)

Similarly, special characters can be entered via numerous mechanisms on phone
keyboards.

My suspicion is that there's a contractual requirement somewhere to retain
compatibility with an existing infrastructure somewhere.

~~~
gcb0
so, they have a requirement to maintain compatibility with telephone password
input, but require an uppercase character as well? it does not make any sense.

this is incompetent developers in a dysfunctional environment. there is no
good light anyone can throw at it. and no, having the system live since the
50s is not a good excuse. it is certainly not the same system, for obvious
reason.

~~~
colanderman
That makes perfect sense. 'A' and 'a' are both on the 2 key, along with 'b',
'c', 'B', and 'C'.

~~~
gcb0
Wait. are you saying that phones that didn't even have the Q and Z inputs are
capable of uppercase and lowercase?!

all my really old nokias and ericsson and motorolas (that did have Q and Z :)
did not made uppercase... pressing one key over and over would cycle the lower
case chars only.

~~~
colanderman
We're not talking about text messages; we're talking about DTMF tones. You
push the button once, the remote end receives that digit (say, "2"), not a
character.

Hence, the remote end must assume the "2" to represent either an "A", "B", or
"C". What I'm saying is that it's reasonable to further assume that, if the
user pressed "2", they may have pressed it to indicate one of the three
corresponding lowercase characters. Humans generally ignore case.

What's _not_ reasonable is to assume that a human, faced with a DTMF pad
_without_ a Q or a Z, would press anything. Sure, you could interpret all
digits as a possible "Q" or "Z", but it's equally likely that a human in such
a situation would leave the character out, or give up and call tech support.
It's simpler to just disallow these characters.

~~~
dredmorbius
Assuming the system is capable of being accessed _both_ by phone _and_ by a
fully-keyboarded device (including, I suppose, a fully-keyboarded phone), then
you've got the challenge of authenticating based on _either_ the DTMF tones
_or_ the keyboard input. Which means you'd either have to record the hashes
both forms (and figure out how to supply the keyboard variant if the initial
input is a phone, or allow _all_ compatible keyboard variants), or you're
storing the password and comparing the input directly.

------
eli
I'd caution against making assumptions about the competence of the developers
based only what you can see from the outside. More likely than not there are
good reasons to maintain interoperability with legacy systems. This may well
be the most elegant way to solve a complex problem.

I've certainly written my share of code that would look weird to an outsider
who didn't know the backstory and the constraints and the evolution.

~~~
Lagged2Death
_This may well be the most elegant way to solve a complex problem._

It seems to me that these silly, arbitrary restrictions on password lengths
and contents are far too common to explain or excuse in this way. The full
list of JetBlue's password restrictions looks very much like the restrictions
at a zillion other sites. The "no Q or Z" thing is strikingly weird, but its
probably less harmful than the (very common) low maximum length restriction,
for example.

Maybe I'm out of my depth here, but:

You're generally supposed to run naked user-chosen passwords through some key-
stretching hash anyway. That offers the chance to do away with many of these
common restrictions from the user's point of view, even if you can't change
the capabilities of the old systems underneath. Feed the password through a
hash, run the hash result through a filter that expresses the result in the
required character set. Now you've got a password the old system can store.
The user's chosen password can be arbitrarily long, it can contain any
character, and every character of that user-chosen password will effect the
"real" password in the old system. Every real password will be the maximum
size the old system can store.

~~~
jedberg
How do you type your password into your telephone, something this system has
to support?

That's why you can't use Q and Z -- it's not on the phone.

~~~
SomeCallMeTim
"Type your password into your telephone"; already they're asking me to do the
wrong thing. If my password is anywhere near secure, then typing it into a
phone would be a nightmare. A combination of 16 numbers and letters that I
need to convert to numbers? I'd be pressing zero and hoping for an operator
before I even opened up my password vault to find the secure password to begin
with.

If you want a phone interface, give me a PIN option. Sure you'll not want me
to be able to buy plane tickets with just the PIN, but that should be
sufficient to protect user data.

~~~
ubernostrum
_already they 're asking me to do the wrong thing_

Now, yes.

The original SABRE dates back to the 1950s, and was not an airline-customer-
facing system; SABRE dates to an era when the phone interface was used by
airline ticket agents.

So if you're going to argue that the design is wrong, you need to argue for
why it was wrong for the 1950s use case and interaction patterns, not try to
retrofit 2014's use cases and interaction patterns onto it.

~~~
hellerbarde
The architecture might have been state of the art and completely reasonable
back in "ye olden days". The fact remains that it's not appropriate for 2014.

If the reasons for this behemoth are compatibility with 50 years old
processes, then these processes have to be modernized so this software can be
scrapped. (or fixed, either way a huge project)

~~~
roel_v
" then these processes have to be modernized"

How so? So people can use Q's and Z's in their passwords? What would your
business case look like? "Hey everybody let's spend $500 million so people can
use arbitrary passwords, because [entropy], never mind most people use the
name of their cat anyway?"

~~~
wakeless
But my cat's name is quizzical.

~~~
bela_lugosi
surely you mean quizzicat

------
lvs
Looks like it has to do with the venerable Sabre system (scroll to bottom):

[http://kottke.org/12/06/the-worlds-worst-password-
requiremen...](http://kottke.org/12/06/the-worlds-worst-password-requirements-
list)

~~~
mikeash
It's worth noting that when you say "venerable" you mean it. Basic research
for what would become Sabre first started in 1953, development started in
earnest in 1957, and it was online in 1960.

It's also interesting that the project got its start because an IBM salesman
just happened to be sitting next to the president of American Airlines on a
flight, and that salesman happened to be working on a massive air defense
computer system for the Air Force. Goes to show the power of knowing the right
people, or in this case, coincidentally meeting them on a plane.

~~~
mindcrime
_Goes to show the power of knowing the right people, or in this case,
coincidentally meeting them on a plane._

It's funny how air travel, in some regards, actually turns out to be somewhat
egalitarian, especially on Southwest where you have no "First class cabin".
You can go for "Business Select" but that just means you get in line earlier
to get on the plane, but it doesn't put you in any special area.

Amusing anecdote... I was flying back to NC from San Francisco last week and
started talking to the guy sitting next to me. He mentioned being in the beer
industry, so I asked who he worked for, and he said "Miller-Coors". Later I
happened to ask him what his role there was, and he replied "CEO".

Turns out he's from North Carolina and we had a nice talk on the way in. And
as it was, I wasn't trying to sell him anything (we mostly talked about beer),
but it's funny that I got to sit and chat for an extended period of time with
a big-shot CEO that I never could have gotten a meeting with otherwise.

So yeah, air travel can definitely result in some interesting chance
encounters.

~~~
mendelk
This is the premise of "Delta Innovation Class"[0].

[0]
[http://www.deltainnovationclass.com/](http://www.deltainnovationclass.com/)

------
seanmccann
They use Sabre (like others), and it's an archaic holdover from when phones
didn't have Qs or Zs.

~~~
ryanburk
I then wonder if these passwords are even less secure since the backend system
would have mapped {A,B,C}=1 at some point for the dialer system to work. so my
password "CaB" would be the same as "cab" and "CAB" and "ABC" and "111", etc.

~~~
twistedpair
This entropy loss is standard. Try calling the country's leading 401K provider
or other banks, they'll ask for your password over the phone keypad.

Because of this, most people cannot have punctuation in the password (not on
phone keypad), and aB2CaCb becomes 1111111. So much for 104 keys on the
keyboard.

~~~
ryanburk
the fidelity case scared me years ago. amazed they still do that, but I can
also imagine that they have a system that only allows the crazy phone mapping
when validating over the phone an policy around that on how many times you can
try, phone number you try from, etc to minimize brute force attacks to counter
the loss of entropy.

------
theboss
That's nothing.... A friend of mine forwarded some emails shes gotten from jet
blue.

First this screenshot:
[http://i.imgur.com/oKKpFM1.png](http://i.imgur.com/oKKpFM1.png)

Followed by the money screenshot:
[http://i.imgur.com/DlAlQPt.png](http://i.imgur.com/DlAlQPt.png)

She redacted some of the information before she sent it (obviously). This is
from Jan 21 of this year. It's just so sad.... It's incredible people still
have plaintext passwords serverside....

~~~
iopq
oh come on, man

everyone's sent those emails before you try to do some smart templating, but
your designer changes the template and never actually remembers that those
were FILLER VALUES

~~~
theboss
I actually have no idea what you're talking about.

All I know is they sent her plaintext passwords to her, which she redacted
before sending to me....

~~~
iopq
oh, I thought it was actually PUT_PASSWORD_HERE placeholders it wasn't clear,
you should have put black bars there

~~~
encoderer
Agreed. I thought the same thing.

------
jfoster
If they were OK with applying more duct tape, why not map Q and Z to
characters (eg. A and B) that can be part of passwords? (eg. a password of
"quiz" would become "auib")

It would make their password system slightly weaker perhaps, since freq(a)
then becomes more like freq(a)+freq(q) and freq(b) more like freq(b)+freq(z).
I'm not sure that's much weaker than just excluding Q and Z, though. The user
experience is improved. The major downside would be in technical debt.

~~~
elwell
Or you map them to something like:

Q = ABDHCJSKJDHSSS

Z = YYYDUHUHUHSSYS

... to avoid weakening the password.

~~~
napoleond
I can't tell if you're joking or not, but for the benefit of people who don't
know any better: such a scheme would not meaningfully impact the strength of
the password storage scheme at all. (To prove it to yourself, think about how
rainbow tables work. Then consider how little additional work would be
required to replace all Q's and Z's with the appropriate string before making
the table. It's not much different from having a "salt" that's the same for
every user in your application, which also doesn't meaningfully impact the
strength of the password storage scheme.)

~~~
jpatokal
Actually, it's a classic case of security through obscurity. If _the attacker
doesn 't know about it_ and are using a standard rainbow table, then no, it's
not going to have "ABDHCJSKJDHSSS" in there and it will make their life
harder. Once they do find out, though, it's useless.

------
slaundy
I just changed my Jetblue password to contain both a Q and a Z. Seems the
support documentation is out of date.

~~~
jkubicek
Have you tried logging in with the same password, minus the Q and Z?

~~~
Rizz
Or with different characters that are keyed with the same digit on a phone,
like P, R or S for the Q?

------
phlo
As many sources have pointed, out, this is very likely related to Sabre.
Interestingly, there is another reason why such a restriction might be useful:

There are three popular key arrangements. English/US QWERTY, French AZERTY,
and German QWERTZ. Apart from switching around A, W, Y, Z, and most special
characters, they are mostly identical.

If your goal is to ensure successful password entry even if a user is
unexpectedly using an unfamiliar keyboard scheme, all you need to do is
replace all instances of A or Q by one value; and all instances of W, Y, Z by
another. Or you could, of course, disallow these characters.

I hear Facebook had a similar approach to coping with input problems in the
early days of mobile access: for each passWord1, three hashes were stored:
"PassWord1" (uppercase first letter), "PASSwORD1" (caps lock) and "passWord1"
(unchanged). As far as I remember, they didn't deal with i18n issues -- or
publish the results of their approach.

Edit: This would, of course, _weaken password security_ significantly. If my
very rough back-of-the-envelope calculation is correct, by a bit less than
50%.

~~~
mhandley
Seems more likely that Sabre's restriction was because old phone dials (and
the keypads that replaced them) didn't have Q or Z:

[http://payphonepictures.com/44631-4/IMG_4953.jpg](http://payphonepictures.com/44631-4/IMG_4953.jpg)
[http://www.dreamstime.com/royalty-free-stock-photography-
pay...](http://www.dreamstime.com/royalty-free-stock-photography-pay-phone-
keypad-image1938827)

------
skizm
Actually this kind of gives me an idea: what if modern systems decided to just
tell people they can't use "p" so that people stop using the word "password"
or variants as their password.

Hell, for that matter, tell users they can't use vowels so they can't make
words. They might do leet speak, or whatever which is pretty easy to crack
given time, but it stops things like password re-use attacks (people less
likely to have the same password as their other apps) and simple guessing
attacks (try top 3 most popular passwords on all known emails/accounts).

For such a simple rule set (no vowels) it forces a decent level of password
complexity.

~~~
zhte415
You've reminded me of something I found interesting regarding passwords in
China. Often, faced with minimum password standards, a user will choose the
first Romanised (Pinyin - used for keyboard input as well as phoneticisation)
letter of a word in a phrase, an example being 我看懂中文你呢？ which is Romanised as
'wo neng kan dong zhong wen ni ne?' or to take the first letter of each word
'wnkdzwnn?' (This phrase, meaning 'I can read Chinese, can you?' a somewhat
unlikely candidate for usage).

I doubt the security, given the prevalence of z, w, n, etc that occurs in
Chinese (Mandarin) words (and likewise in other languages), doubly so because
of common phrases that a lot of people would likely pick, and would heed
against such a policy.

~~~
xiaq
You missed a 能 after 我.

~~~
zhte415
Yeah, saw that but couldn't edit any longer. Oh well... IBus was not to blame
this time.

------
amichal
guessing... Touch tone phone keypads dont always show q and z. I suspect that
some older JetBlue system allows you to use your password via a touch tone
system (with a vastly reduced keyspace)

~~~
elsporko
That would also explain the last rule:

Cannot contain special characters or symbols (such as !#$@*, etc).

It seems to be geared toward those with cell phones but not necessarily
'smart' phones (with full keyboards).

------
Iterated
Question to all those saying this is because of Sabre:

How? Does the TrueBlue password somehow go through Sabre's systems? The truly
old business unit of Sabre that everyone is referencing is Travel Network. I'm
not sure why an airline's loyalty program would intersect with Travel Network
other than through the back end of a booking tool.

~~~
cosmotron
I'm guessing that JetBlue allows people to log into their account via
telephone. They could map your alphanumeric password to the series of numbers
you'd punch in on a phone.

Example: the password 'foobar9' could be mapped to 3662279

------
stephengillie
When I saw the Sabre password requirements, I couldn't help but imagine that
passwords are stored entirely numerically - "badpass" would be entered
(hashed?) as "2237277", as in dialing a phone. So the password "abesass" would
collide with "badpass" and grant access.

Has Sabre at least upgraded their storage mechanism, or do (did?) they reduce
entropy on passwords?

~~~
8_hours_ago
I was also curious about this and decided to test it. I created a new account
with the password "badpassbadpass" (minimum password length of 8!), but I was
unable to log in with "abesassabesass". There was also no error when I tried
to put a 'q' and a 'z' in my password, so I'm guessing that they've updated
their system since the documentation was written.

~~~
squeaky-clean
I just tried it with 'abcabcabc' as my password. It claims passwords are case
sensitive, but both 'abcabcabc' and 'ABCABCABC' work and any variation
('ABCabcaBc' works). Variations based on a phone pad don't seem to work.
'123123123' or 'bacbacbac' don't work. I also tried only changing one letter.

>Must contain one letter and one number

Also not true.

>Cannot contain three repeating character

Also not true. I changed my password to 'qqq123123' and could login just fine.
Something like 'zzz123123' does not work.

I put way too much effort into this.

~~~
mentat
So for all those saying that we should just "trust the engineers know what
they're doing" this is a pretty damning refutation as far as I'm concerned.

------
dragonwriter
They also can't contain symbols (so apparently just digits and letters except
Q and Z). The combination suggests to me the horrible possibility that they
actually reduce the password to just digits for storage, and to support entry
on devices that look like old touchtone phones [1] (I say "old" because newer
ones usually have "PQRS" instead of "PRS" and "WXYZ" instead of "WXY"):

[1] Like:
[http://www.cs.utexas.edu/users/scottm/cs307/utx/assignment5....](http://www.cs.utexas.edu/users/scottm/cs307/utx/assignment5.html)

------
gt21
Here's a pic of when phone keypads don't have Q and Z:
[http://www.dialabc.com/words/history.html](http://www.dialabc.com/words/history.html)

~~~
bluedino
I feel so old.

------
Iciloo
The snow glows white on the mountain tonight, not a footprint to be seen. A
kingdom of isolation and it looks like I'm the queen. The wind is howling like
this swirling storm inside. Couldn't keep it in, Heaven knows I tried. Don't
let them in, don't let them see. Be the good girl you always have to be.
Conceal, don't feel, don't let them know. Well, now they know!

Let it go, let it go! Can't hold it back any more. Let it go, let it go! Turn
away and slam the door. I don't care what they're going to say. Let the storm
rage on. The cold never bothered me anyway.

It's funny how some distance, makes everything seem small. And the fears that
once controlled me, can't get to me at all It's time to see what I can do, to
test the limits and break through. No right, no wrong, no rules for me. I'm
free!

Let it go, let it go. I am one with the wind and sky. Let it go, let it go.
You'll never see me cry. Here I'll stand, and here I'll stay. Let the storm
rage on.

My power flurries through the air into the ground. My soul is spiraling in
frozen fractals all around And one thought crystallizes like an icy blast I'm
never going back; the past is in the past!

Let it go, let it go. And I'll rise like the break of dawn. Let it go, let it
go That perfect girl is gone Here I stand, in the light of day.

Let the storm rage on! The cold never bothered me anyway...

------
eigenrick
Everyone in the conversation seems to be pointing out the fact that this is
due to integration with legacy software. That's not an acceptable reason.

In the broader sense, there is a great irony in making password "strength"
restrictions, like "must include" and "must not include" because they often
end up making passwords easier to brute force.

If you start with the restriction that all passwords must have > 8 characters,
you have basically an infinite number of possibilities, smart users will use a
passPHRASE that is easy to remember. Dumb users will try to hit the bare
minimum characters. When you put a restriction of 20 chars, it reduces the
possibility that a persons favorite passphrase and guarantees that the set of
all passwords is 8-20 characters, which means that the set of all passwords is
smaller still.

They disallow special chars, which probably includes space, which further
reduces the likelihood that someone will pick a passphrase.

Disallow repeating characters and you've further reduced the entropy.

Disallow Q and Z and it's reduced it further still.

I can't be arsed to do the math, so I'll reference XKCD
[http://xkcd.com/936/](http://xkcd.com/936/)

But Sabre would do well to correct this, the optimal case is simply making a
single requirement: passwords must be greater than 8 characters. The don't use
your last N passwords requirement isn't bad, but people usually find hacky
ways around this.

------
jamieomatthews
Can anyone explain why this is? I've never heard a security reason for this.

~~~
30thElement
While the other answers about Sabre are probably right, I've heard that banks
intentionally have stupid password policies to prevent password reuse. If one
bank says "no special characters but most contain a number", another says
"must contain a special character, but no numbers", and a 3rd says "must
contain a number and special character", they can guarantee that if one of the
3 is hacked into it doesn't compromise people with accounts at all 3 (of
course ignoring people using "password" with a 1 or ! on the end).

~~~
frogpelt
This would require cooperation.

------
manojit
Why people are still restricting password complexity. As long as passwords are
carefully & cryptographically processed (read hashed with individual salt). I
recently designed a system where the only password policy is the length (8
char minimum) and they are stored hashed with salt being a specially encoded
user id (thus unique for each user).

I also like to contradict myself. Password complexity and and all the policy
are needed to make the social engineering not feasible. I mean a strong and
secure system and with that people are using 'password1234' is a very bad
practice.

~~~
Sami_Lehtinen
I consider passwords as random blobs of bytes. Everyone says that hashing is
important but I don't see any real benefit of it. If I hash random 128 bits
result is random 128 bits.

~~~
SoftwareMaven
It's important because if somebody gets your database, if you haven't hashed,
they have everybody's passwords, and those passwords are often reused many
times at many sites. Hashing at least puts a step between stealing your table
and knowing everybody's passwords (a mathematically hard step for good
passwords).

Also, please let me know what sites you manage so I know where my data is not
valued.

------
rjacoby5
I think everyone is completely missing the reason behind the omission of Q and
Z.

Due to the database storage engine they chose, it was necessary to put a
limitation on the number of Scrabble points that a password would award.

Q and Z are both 10-pointers, so passwords with them frequently blew past the
limit. You can use J and X, but that's really pushing it.

And the "cannot contain three repeating character" rule is due to that being
the trigger for the stored procedure that implements 'triple word score'.

------
jedberg
One of my bank accounts has the same restriction, so that you can enter you
password through the phone system. It's stupid, but at least it has a reason.

------
kirab
For everyone who designs password rules: Please do not require the password to
contain uppercase, lowercase letter, numbers and so on. Because this actually
makes passwords statistically easier guessable. The only thing you should
require is a minimum length, I recommend at least 10, better 12 characters.
Even 12 digits are more secure than say "Apple1".

------
bgia
Why didn't phone have Q and Z? Everyone is mentioning that they did not have
them, but I can't find a reason for that.

~~~
ryanburk
it was the simplest way to map 3 letters to each number 1-9 on the keypad.[1]
that way you didn't have a few numbers with 4 letters and had a consistent
model.

[1] my grandfather explained it this way back in the early '80s. I couldn't
find a good link to a more official source.

~~~
nkurz
Except that 3 * 9 = 27, and there are only 26 letters in the English alphabet.
They are actually mapped to the numbers 2-9, which leaves the question of why
they didn't use 1.

~~~
btgeekboy
The local prefixes of phone numbers don't/couldn't start with 1. If you map
ABC to 1, you can't use those letters as the start of a word. (Your number
could be GET-SOME but not AND-MORE.) This is because when you dial without an
area code, your leading 1 would be interpreted as a long distance call. This
is the same reason they didn't use 0, as that's the start of an international
call (011).

------
sp332
Have you tried it? This person says it works just fine.
[https://twitter.com/__apf__/status/466327291027804160](https://twitter.com/__apf__/status/466327291027804160)
And it doesn't make sense that it's a holdover from phones, because then it
wouldn't be case-sensitive.

------
Sami_Lehtinen
My bank allows only passwords which are six digits like 123456. No longer or
other characters or symbols.

~~~
na85
Find a new bank. Tell your bank why you switched.

~~~
woebtz
My bank only allows email addresses less than 31 characters in length. I filed
a bug report and received a, "thanks, we know..." Fortunately, their password
policy isn't as ridiculous.

------
tn13
There might be some very good reasons why such policy may exist. For example
this system may involve telling the password to someone over the phone or
using a TV remote to enter a password or some other keypad other than QWERTY.

------
brianlweiner
for Bank of America customers, you might notice your mobile app requires you
to use a password < 21 characters . There is no such restriction for desktop
browsers.

Attempting to login to my mobile app requires me to DELETE characters from my
password until the overall length is less than 21. I'm then able to login.

What does this tell us about BoA's password storage?

------
GrinningFool
That's ok, here's a better one.

etrade - yeah, THAT etrade? Yeah. They make your passwords case-insensitive.

~~~
honoredb
As does Citibank. I imagine it's for telling-support-over-the-phone purposes,
which isn't great.

~~~
tokenizerrr
...why would you have to tell them your password in the first place?

------
r0m4n0
Looks like they removed this requirement recently. We have JetBlue in our
presence :O

------
codexon
why not hash the the password and encode it in base34? (36-2)

------
DonHopkins
How can people that stupid be allowed to operate airplanes?

------
jrockway
Shouldn't this mean that the OUTPUT FROM THE HASH FUNCTION can't contain Q or
Z!? Certainly no system other than the web frontend would be looking at the
password itself...

------
maxmem
Also no special characters.

------
coherentpony
[http://xkcd.com/936/](http://xkcd.com/936/)

------
guelo
My guess, some kind of harebrained master password scheme for support.

------
codezero
My guess is that this is just a rule to force people to read the rules.

~~~
gedrap
It's not an Odesk job post where "please include <some word> in your
application" ;)

