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.
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).
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.
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.
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).
As for your voicemail system, that merely gets around the issue of competing standards by enforcing its own. And the mapping has to be repeated to every user for every use of the system. I'd actually consider it an argument in favor of the keypad theory.
Escape codes (or testing codes) is another possible explanation. And legacy code cost is indeed often a consideration.
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.
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.
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.
But you're making the mistake of assuming they're hashing passwords at all ;)
That, I think, is the correct inference.
If the system shows a misunderstanding of security or makes it clear that shortcuts were taken, then what is to make you think the same didn't occur on a deeper and more important level (databases, security, etc).
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.
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'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.
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.
That's why you can't use Q and Z -- it's not on the phone.
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.
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.
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)
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?"
The target breach would be nothing compared to the breach of a system in use for 60 years.
Instead of bringing the code into 2014 they would bring the world into the 1950's.
DTMF/Touch-Tone wasn't introduced until 1963 (and then being an extra-cost option from the Bell System). So more like "Dial your password into your telephone". Rotary phones didn't have Q or Z either.
But this is silly really, because I've never seen a case sensitive phone keypad, which is part of their complexity requirements.
There's a lot of speculation in the thread that this is the reason, and it's not a totally unreasonable guess. If this is the reason, then you're right, my scheme would not be suitable.
While we're all guessing, though, I think there are reasons to doubt a "password via DTMF" requirement. Look at the other rules: Passwords are case sensitive, must contain both letters and numbers, and "Cannot use proper names," whatever that actually means. None of those makes any sense with DTMF, where any string is non-uniquely reduced to a string of digits. Passwords are also limited to 20 characters, which is just as arbitrary with DTMF as with anything else.
How, exactly, a rule like this improves security, I'm sure he cannot say, at least in a sensical way.
Most of the time, these weird rules seem to come about because of misunderstandings. The no "special" characters rule, for instance, dates from a time when most web CGI code was in Perl, and with a specially constructed series of characters in a web input field, it was easily possible to "shell out" to the operating system and even get access to data. So security people told developers: "do not allow special characters! Ever!" Instead of understanding why this rule existed, they blindly followed the order. Over time the rule got distorted, and now, which particular set of special characters is disallowed varies from site to site.
The restriction on length is obviously based on confusion: a minimum length for a password is a good idea, but imposing a short maximum length makes no sense whatsoever. (Apparently someone thinks that too many characters might cause a buffer overflow?)
The char limit, well, they had to pick a limit (you wouldn't want passwords of 2^32 size), and back then security wasn't as big a focus so someone picked 16.
The reason for the original restriction is lost to history, as is apparently the handling of special chars. It may have been as simple as someone piping something to a shell script to setup an account, and not escaping things correctly. Who knows.
At any rate, Live has some extremely competent engineers, and this guy is brilliant. He said despite how bad it looks, every time they review security and prioritize things to work on, the password restrictions on Live never rank very high, compared to other attacks. People simply are not having their passwords brute forced enough for it to be a serious issue. Investing in things like e.g., detecting phishing attempts, has a much better ROI.
eli's comment is right: You shouldn't be too quick to judge the quality of developers when they need to maintain compatibility. At best, you might find out that a developer from a long time ago, operating under who knows what constraints (time, technical), failed to properly foresee the usage of his system.
It may have been as simple as someone piping something to a shell script to setup an account, and not escaping things correctly
This is precisely my point.
Maybe Jetblue's developers a bunch of lazy dummies who couldn't think up the solution in your comment... But my experience suggests to me that they're much more likely to be perfectly competent and that there's simply more to the problem than is apparent from the outside.
I was attempting to come up with a layer that would paper over any constraints of the underlying system, but you're right that I'm guessing.
Maybe Jetblue's developers a bunch of lazy dummies...
I would never be as harsh as that. I would guess that this sort of thing is a matter of institutional culture. Nonsensical password rules are extremely common. The organizations responsible are doubtless full of individuals who know they're not optimal, but fixing the password rules is never on the top of anyone's priority list. And once you've gone live with the bad password arrangement (as you well might under schedule/budget pressure), it becomes hugely more difficult to change things.
The fact is that this sucks for the user. It's also a pretty safe bet to say that there are lots of developers putting code into use solving problems outside their competency. You may not want to assume this evidence makes them terrible developers, but that doesn't make the inverse any more likely, either.
I used to think most other programmers were bad and most legacy systems were terrible, until I had to design and maintain one that lasted for years myself...
It may be an attempt to cut down the amount of helpdesk calls when 2 systems used the same passwords among language barrier.
I'm sure a lot has changed since then, but it's a bit scary to wonder what hasn't.
I passed largely as it seemed that there were some significant organizational issues and wrestling with 60 year old computer systems stopped being my definition of fun a while ago. There were some glitches in the rollout but they got things running by and by.
Furthermore, the poster below who showed screenshots of being emailed their password indicates JetBlue is storing passwords either in plain-text, or encrypting them (both just as bad), instead of properly cryptographically hashing before storage.
Not so much as you may assume. I'd bet (not with much money, admittedly) that you can't get into the web interface with a telephone-digit variant of your password.
I'm not sure where in their architecture phone-keypad-compatibility lies, but it's quite possibly not even in any user-facing system.
In that case, the security of your password is not much reduced -- only if someone has access to that telephone-access system, and can do something bad with it.
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.
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.
Interesting little note from that:
"I learned later that he would be sitting in his office in New York and he'd suddenly wonder how things were getting along in L.A. He would tell his secretary, "I'm going to L.A." He would go to the airport, just walk on a plane, and fly out without a shaving kit, pajamas or anything. Then he would take a look around and catch another plane back."
I doubt many company presidents are taking that sort of approach anymore.
UK -> US east coast works reasonably well that way, given that the flight is 5-6 hours, and 5 hour time difference, so you can get on a flight early morning from London, arrive early morning at the east coast, have your meeting and catch an evening flight back out which'll arrive back in the UK in the morning local time.
That's why they buy a jet with company money now.
> Early in his tenure, Cook was told of a problem with one of Apple's Chinese suppliers. "This is really bad", he said. "Someone should really be in China driving this." 30 minutes later he looked at an operations executive sitting at the table and unemotionally asked, "What are you still doing here?" The executive stood up, drove directly to San Francisco Airport, and bought a ticket to China.
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?
So you just have to provide your last 20 passwords.
Not necessarily. For all we know, Sabre could have scooped T9, and transmitted a "C" by sending three single pulses, or an "N" with two groups of six. (We're talking about the days of rotary phones, not touch-tone, remember.)
(This was burned into my brain years and years ago while watching a "Jeopardy!" episode, in which this mistake caused all three contestants to lose the final round.)
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.
First this screenshot:
Followed by the money screenshot:
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....
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.
Still, if you receive your password back, that is a giant red sign screaming insecurity
This being said, the banks are also in the unusual position of being able to effectively insure themselves against relatively small losses (to them) in order to keep confidence in their business high.
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
All I know is they sent her plaintext passwords to her, which she redacted before sending to me....
Yes, Google sends passwords in plaintext when you have to create an account for another user. But on your first login it requires you to change the password.
You have a new account at Example Association.
Your username is tsmith. Your initial password is ZjAdhUVC
(you will need to change this when you log in).
Your new email address is firstname.lastname@example.org
You can sign in to Example Association services at:
That's 'will need' not 'we ask nicely and you can ignore'. When you create a user, it gives the option of setting their password for them, or using a temporary password, which they have to change.
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.
Q = ABDHCJSKJDHSSS
Z = YYYDUHUHUHSSYS
... to avoid weakening the password.
"Cannot contain special characters or symbols (such as !#$@*, etc)"
Well, damn! Guess that won't work.
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.
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%.
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.
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.
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.
There are a lot more variables at a job than at my house in my locked drawer.
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).
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.
Example: the password 'foobar9' could be mapped to 3662279
Has Sabre at least upgraded their storage mechanism, or do (did?) they reduce entropy on passwords?
>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.
 Like: http://www.cs.utexas.edu/users/scottm/cs307/utx/assignment5....
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.
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...
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.
Guess 2: The characters are column separators in some form of data store.
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.
Also, please let me know what sites you manage so I know where my data is not valued.
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'.
 my grandfather explained it this way back in the early '80s. I couldn't find a good link to a more official source.
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?
etrade - yeah, THAT etrade? Yeah. They make your passwords case-insensitive.
I never knew that their website would truncate passwords at 8 characters, but just checked and sure enough it works. This is indicative of the ridiculousness of the 8 char limit, but given the 8 char limit, I don't think it weakens their system at all.
If you care about keeping your money it may be wise to take the fob and/or find a new bank/broker.