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.

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.

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?)

[edit: wording]

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.

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.

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.