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

[gpcz]

As ridiculous as that pitch might sound, it makes the implied security-money tradeoff directly visible to management and causes them to make a formal decision.

[rnovak]

How so? if it's been used for 60 years, how many records do you think would be compromised if someone gained access to the system? Millions? Billions? Sounds like a good reason to 'modernize' to me.

The target breach would be nothing compared to the breach of a system in use for 60 years.

[wakeless]

But my cat's name is quizzical.

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

[imjustsaying]

You're missing out. Try KoreanAir.

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