[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?"

[DonHopkins]

If their computer system is from the 1950's and they can't modernize it, why don't they also allow smoking and box cutters on the plane, and dress their stewardesses up all sexy?

[gaius]

Yeah, call me when you've got some code running in production for 60 years. Kids these days...

[Fuxy]

There's a reason we invented the term bit rot and this is probably one of the reason only in this case the code works perfectly fine it's just the entire use case that is outdated.

Instead of bringing the code into 2014 they would bring the world into the 1950's.

[dreamfactory2]

i guess requirement rot is partly why we have agile

[chiph]

"Type your password into your telephone"

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.

[chris_wot]

Wow. Passwords on the phone? You've changed the password strength from a combination of 26 lowercase letters + 26 upper case letters + 10 digits + 30 punctuation characters to just 12 characters. For an 8 character password that goes from (92^8)/2 to (12^8) permutations of characters.

But this is silly really, because I've never seen a case sensitive phone keypad, which is part of their complexity requirements.

[Lagged2Death]

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

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.

[DonHopkins]

Neither are a or b or c or ...

[area51org]

Given the other strange, arbitrary restrictions we've seen in the wild over the years — no "special" characters, no longer than 12 characters, ad nauseum — my bet is that someone has it in his head that restricting the usable character set even further will somehow improve security.

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]

[MichaelGG]

So Microsoft Live has a limit of 16 characters, ASCII and some other restrictions. I emailed someone that used to work on that team in a decently high capacity. He said it was a restriction in the original system, designed sometimes in the 90s, and that the password validation code is in several different places in the entire system (different products like Hotmail and so on).

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.

[area51org]

Given the sheer number of arbitrary limits found in websites, I suspect your example is probably anecdotal.

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.

[_kst_]

How does Perl CGI code make it possible to "shell out" to the OS? I'm sure it can do so if the application isn't coded carefully, but how difficult is it to avoid doing the equivalent of passing user input to eval()?

[area51org]

It's not hard to avoid that, but in the nascent days of the web, few people were thinking that way. We were naive in our code. Sloppy, quickly written Perl was the norm.

[eli]

Sure, maybe. But you're guessing at how the system works and how it's used and what the constraints are...

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.

[Lagged2Death]

But you're guessing at how the system works and how it's used and what the constraints are...

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.

[chavesn]

That's quite generous of you. I don't think there's any more reason to assume they are competent than to assume they aren't.

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.

[eli]

Thanks. As I said, it's based on my experience.

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...

[ajuc]

There are some languages using latin script without the letter "Q" in their alphabets.

It may be an attempt to cut down the amount of helpdesk calls when 2 systems used the same passwords among language barrier.

[andrewflnr]

I'm probably out of my depth too, but I think you underestimate the prevalance of legacy systems.

[1stop]

What if the legacy system underneath IS the hashing system?

[Lagged2Death]

Nothing stopping you from hashing more than once.

[lectrick]

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

[ateeqs]

I suspect that this is the likely answer here, since old telephone keypads did not have Q and Z.

[dredmorbius]

And more recent keypads have assigned various characters (particularly Q & Z) inconsistently, as I've posted separately.

[jtheory]

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

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.

[mikeash]

In this case, a legacy system (Sabre) whose origins predate the integrated circuit.

I'm sure a lot has changed since then, but it's a bit scary to wonder what hasn't.

[coldcode]

I doubt that the passwords come from SABRE. There is a lot of stuff between the front end and SABRE. I expect Jet Blue manages their own systems that only call SABRE internally.

[dredmorbius]

I interviewed with an airline in the past few years for a project involving migrating its reservations and management systems (interesting tidbit: both maintenance and reservations were tied to the same underlying system). And integration with SABRE was very much a part of the job req.

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.

[eli]

I don't find that scary. I think it's a testament to the original architects and to the people who maintain it.

[Alupis]

It's 2014. Passwords need to be treated as a serious matter. Legacy system or not, there is no good reason to reduce keyspace. As others have mentioned, this is a sign that passwords are being made compatible with old phones without these letters available... and likely the passwords being reduced to numbers before storage. The prohibition of special characters also seems to corroborate this.

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.

[cbsmith]

Honestly, if you add one extra digit/character to the password, that more than compensates for the loss of Q & Z. There are lots of circumstances where being able to work with legacy phone systems effortlessly would be most helpful. If you are taking passwords seriously, this might be the very last thing you worry about.

[growupkids]

Or emailing them before they hash them.

[eddieroger]

I'm not sure about that. Sabre is an extremely (assumption) functional tool in an extremely niche market. That makes the barrier to enter it very high, and the barrier to rewrite equally so. Underneath the covers it could be a real piece hung together by duct tape and vacuum tubes, but why rewrite it if it's working and keeping planes in the air?

[fennecfoxen]

Because OMG HACKERS. Seriously, why do we have any security on anything?

[zibit]

It's nice to see these thoughts at the top of the thread. I get tired of hearing people in the security industry constantly smirking at "dump developers". They don't have a clue what it's like to develop real code with deadlines. They point fingers at others and call that an accomplishment.

[sqrt17]

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.

[eloisant]

I think it has more to do with Q and Z missing from old phones keyboards.