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.
And as others have noted, this doesn't make sense given that passwords are case-sensitive and are required to include uppercase characters.
If there's a mechanism for specifying case on the phone, there can be a mechanism for specifying Q and Z unambiguously. I certainly have used VM systems that explicitly told me to "use 7 to represent Q and 9 to represent Z."
A contractual requirement is one possibility that could explain it, but my suspicion is rather that some legacy code in the system uses Q and Z as special escape characters or delimiters (because of their absence on the phone dial), and it's not worth the cost to try to fix the ancient code (or do all the testing necessary to be confident of deploying a workaround).
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.
A lot of the comments under this top level one are a bit absurd in decrying that this means they aren't doing anything right and have a bunch of devs in bad environments.
It's as simple as:
1) On password change/account create, run through a small algorithm that turns the password into a series of digits that represent the password as if it were entered on a phone.
2) Hash both password and "digitized" password into 2 separate fields in your store.
You don't see how it might have been a problem for the original system to allow you to set a password on one phone that (appears to be) impossible to enter on a different phone?
I've encountered telephone login systems which ask me to type in my password in its numeric form (e.g. if my password was 'password', I'd type 72779673)
If JetBlue has a similar logic system via the phone, I can see why Q and Z or prohibited to allow this existing authentication system to work.
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.
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.
No. If there is a bizarre password restriction like this, it is almost certainly because they are storing the password in cleartext somewhere (bad) or because they expect users to be able to enter the password in via a telephone keypad, which vastly reduces the number of possible combinations since every number substitutes for 3-4 letters (also bad).
Intuitively, the reason for forbidding Q and Z could be that those passwords can't be typed in blindly on QWERTZ and QZWERTY keyboards (which you're likely to find if you travel internationally). But then they'd have to be consequent and also forbid Y and maybe A.
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.
Who says just because JetBlue uses Sabre, it uses it for storing customer profiles? Sabre system is a system for agents and services, not for end users.
From that list, the first one mentioned is the worst of the bunch. "8) A password cannot be too similar to a previous password.”
How can you possibly know this without storing the password in plain text or without storing something in the database that reveals critical information about the pattern?
Sabre Red and JetBlue's customer loyalty program (of which these requirement are for) probably have nothing to do with each other. I'm trying to think of how they could be related in a way that would affect what passwords could be used but I can't.
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.
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....
While I can't stand passwords sent as part of a welcome email, this does not actually mean that they store the passwords in plaintext. Often, companies will send the username and password as part of a welcome email upon the user registering (and the above screenshots look exactly like that). This does not preclude the company from then hashing the password and storing it hashed.
That said, it still is a terrible practice, as any records of that email on the origin server or servers in between will thus contain the plaintext password.
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
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.
At the time the underlying system was designed, Q and Z weren't mapped.
Subsequently they were mapped, but inconsistently across phonesets.
The ITU E 1.161 / ANSI T1.703-1995/1999 / ISO/IEC 9995-8:1994 standard didn't become established until relatively recently. Guessing from the nomnclature, I'd assume subsequent to 1995 / 1999.
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%.
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.
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.
Correct Horse Battery Staple[1] is a good example of a good password with high entropy, bzzl123 is not. Something like that would surely do more harm than good.
Better to simply utilize one of the many, many, many, many, many lists of most frequently used passwords.
There are lists extending to the tens of thousands if not millions, but simply forbidding the 10 or 100 most frequent combinations would be a huge win. Using full lists as available would be great -- and is actually what password security should be based around. A known password is a bad password.
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)
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.
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
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?
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"):
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...
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.
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.
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.
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.
[+] [-] dredmorbius|12 years ago|reply
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)
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
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
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.
[+] [-] breadbox|12 years ago|reply
If there's a mechanism for specifying case on the phone, there can be a mechanism for specifying Q and Z unambiguously. I certainly have used VM systems that explicitly told me to "use 7 to represent Q and 9 to represent Z."
A contractual requirement is one possibility that could explain it, but my suspicion is rather that some legacy code in the system uses Q and Z as special escape characters or delimiters (because of their absence on the phone dial), and it's not worth the cost to try to fix the ancient code (or do all the testing necessary to be confident of deploying a workaround).
[+] [-] gcb0|12 years ago|reply
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.
[+] [-] rjbwork|12 years ago|reply
It's as simple as:
1) On password change/account create, run through a small algorithm that turns the password into a series of digits that represent the password as if it were entered on a phone.
2) Hash both password and "digitized" password into 2 separate fields in your store.
3) Now support phone inputs for passwords.
[+] [-] eli|12 years ago|reply
[+] [-] krunk4ever|12 years ago|reply
If JetBlue has a similar logic system via the phone, I can see why Q and Z or prohibited to allow this existing authentication system to work.
[+] [-] eli|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] lectrick|12 years ago|reply
[+] [-] mikeash|12 years ago|reply
I'm sure a lot has changed since then, but it's a bit scary to wonder what hasn't.
[+] [-] sqrt17|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] lvs|12 years ago|reply
http://kottke.org/12/06/the-worlds-worst-password-requiremen...
[+] [-] mikeash|12 years ago|reply
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.
[+] [-] bumelant|12 years ago|reply
[+] [-] chinpokomon|12 years ago|reply
How can you possibly know this without storing the password in plain text or without storing something in the database that reveals critical information about the pattern?
[+] [-] Nicholas_C|12 years ago|reply
[+] [-] Justsignedup|12 years ago|reply
[+] [-] seanmccann|12 years ago|reply
[+] [-] drdeadringer|12 years ago|reply
[+] [-] ryanburk|12 years ago|reply
[+] [-] theboss|12 years ago|reply
First this screenshot: http://i.imgur.com/oKKpFM1.png
Followed by the money screenshot: 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....
[+] [-] rallison|12 years ago|reply
That said, it still is a terrible practice, as any records of that email on the origin server or servers in between will thus contain the plaintext password.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] xanderstrike|12 years ago|reply
[+] [-] SnakeDoc|12 years ago|reply
[deleted]
[+] [-] iopq|12 years ago|reply
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
[+] [-] ams6110|12 years ago|reply
[+] [-] jfoster|12 years ago|reply
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|12 years ago|reply
Q = ABDHCJSKJDHSSS
Z = YYYDUHUHUHSSYS
... to avoid weakening the password.
[+] [-] dredmorbius|12 years ago|reply
Subsequently they were mapped, but inconsistently across phonesets.
The ITU E 1.161 / ANSI T1.703-1995/1999 / ISO/IEC 9995-8:1994 standard didn't become established until relatively recently. Guessing from the nomnclature, I'd assume subsequent to 1995 / 1999.
[+] [-] slaundy|12 years ago|reply
[+] [-] phlo|12 years ago|reply
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%.
[+] [-] skizm|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] tokenizerrr|12 years ago|reply
http://xkcd.com/936/
[+] [-] dredmorbius|12 years ago|reply
There are lists extending to the tens of thousands if not millions, but simply forbidding the 10 or 100 most frequent combinations would be a huge win. Using full lists as available would be great -- and is actually what password security should be based around. A known password is a bad password.
Don't get me started on PINs.
[+] [-] amichal|12 years ago|reply
[+] [-] Iterated|12 years ago|reply
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|12 years ago|reply
Example: the password 'foobar9' could be mapped to 3662279
[+] [-] coldcode|12 years ago|reply
[+] [-] stephengillie|12 years ago|reply
Has Sabre at least upgraded their storage mechanism, or do (did?) they reduce entropy on passwords?
[+] [-] dragonwriter|12 years ago|reply
[1] Like: http://www.cs.utexas.edu/users/scottm/cs307/utx/assignment5....
[+] [-] gt21|12 years ago|reply
[+] [-] Iciloo|12 years ago|reply
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|12 years ago|reply
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/
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|12 years ago|reply
[+] [-] manojit|12 years ago|reply
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.
[+] [-] rjacoby5|12 years ago|reply
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|12 years ago|reply