Passwords for JetBlue accounts cannot contain a Q or a Z | Hacker News Reader

Passwords for JetBlue accounts cannot contain a Q or a Z

help.jetblue.com

295 pointsalexdmiller211 comments

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.

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.

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

Case-sensitivity is an interesting observation. It makes it 1) more likely that the passwords are being stored and that 2) there are multiple interfaces used: the Web front-end which can handle capitalization (something which can be unambiguously transformed) and a back-end SABRE system which likely cannot but a case-shifted password could still be passed to it.

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.

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.

That makes perfect sense. 'A' and 'a' are both on the 2 key, along with 'b', 'c', 'B', and 'C'.

Wait. are you saying that phones that didn't even have the Q and Z inputs are capable of uppercase and lowercase?!

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.

We're not talking about text messages; we're talking about DTMF tones. You push the button once, the remote end receives that digit (say, "2"), not a character.

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.

Assuming the system is capable of being accessed both by phone and by a fully-keyboarded device (including, I suppose, a fully-keyboarded phone), then you've got the challenge of authenticating based on either the DTMF tones or the keyboard input. Which means you'd either have to record the hashes both forms (and figure out how to supply the keyboard variant if the initial input is a phone, or allow all compatible keyboard variants), or you're storing the password and comparing the input directly.

but thats my point. if that password rule were to support phones, which i doubt, why the other rule demands a lower case and an upper case char?

Does this mean that passwords entered on the phone are hashed/encrypted in a case-insensitive manner? I don't understand how this can work unless you're doing the equivalent of .ToLower()/.ToUpper() on everyone on the back end.

Not just case-insensitive, but character-group-agnostic. All the backend knows is that the user pressed "2"; it doesn't know whether that "2" means "A", "B", or "C". (Or, to my point, "a", "b", or "c".)

But you're making the mistake of assuming they're hashing passwords at all ;)

But you're making the mistake of assuming they're hashing passwords at all ;)

That, I think, is the correct inference.

you make too many assumptions. why not A and a instead of a and A? ...the letter on the key is usually the uppercase.

Consider how important air travel is and the wide range of situations people use to book or change travel plans. It's completely unsurprising that someone would be reluctant to say that no device or system in use anywhere in the world would have a problem with this.

How far we've come that incompetent only means "enforces strange password rules" while still putting out a large, complex (and functional!) system instead of, well, incompetent.

Password rules is one place that is relatively visible that shows business rules and tech limitations in play.

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

Definitions of competence vary with time and circumstance. The formerly competent may become the currently incompetent, with no change in skillsets or capabilities.

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.

3) Now support phone inputs for passwords.

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?

That's specifically the problem that the Q/Z restriction works around.

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.

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.

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

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.

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)

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

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.

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.

But my cat's name is quizzical.

surely you mean quizzicat

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?

You're missing out. Try KoreanAir.

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

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.

i guess requirement rot is partly why we have agile

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

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.

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.

Neither are a or b or c or ...

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]

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.

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.

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

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.

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.

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.

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.

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

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.

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

What if the legacy system underneath IS the hashing system?

Nothing stopping you from hashing more than once.

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

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

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

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

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.

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.

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.

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

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.

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.

Or emailing them before they hash them.

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?

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

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.

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.

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

Looks like it has to do with the venerable Sabre system (scroll to bottom):

http://kottke.org/12/06/the-worlds-worst-password-requiremen...

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.

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.

This is the premise of "Delta Innovation Class"[0].

[0] http://www.deltainnovationclass.com/

Less of a coincidence when flying was expensive enough to be reserved for the "jet set".

No doubt. Interestingly, this meeting didn't happen on a jet and probably predates the term "jet set", as the first jet airliner had only entered service the year before. The IBM salesman thinks it might have been a DC-6:

http://conservancy.umn.edu/bitstream/11299/107637/1/oh034rbs...

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.

I know of British Airways executives who flew from London to New York on Concorde only to attend meetings from which they returned again the same day without having left the airport.

I've done Heathrow -> Dulles -> meeting in Sterling, VA -> Dulles -> Heathrow same day. It's not fun, but it's also not that unusual, even without the Concorde.

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.

Granted, I'm not in the same boat as exec's, but I'm a student and have had dealings with people from other universities in the UK (I'm irish), and I have flown, met them in airport hotels, and flown home same day or first flight following morning.

Yeah but New York => LA is over 5 hours. Is there any flight from Ireland to the UK that takes more than 1:30?

Flying UK-Ireland takes less time than most intercity train journeys, so that is not surprising.

> I doubt many company presidents are taking that sort of approach anymore.

That's why they buy a jet with company money now.

Sure, but how often do they just decide, on a lark, to go check out how operations are going at one of their sites on the other side of the country?

It depends on the executive, but I would say it's not uncommon. Perhaps not on a lark, but because something pops up at the last minute. This portion of Walter Isaacson's Steve Jobs biography comes to mind:

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

That's not even remotely similar.

Known as 'management by walking about' in the UK and fairly common (small, densely populated country).

We do NY -> LA -> meeting -> red eye back to NY on a "regular" basis. It works out great if you're able to sleep 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?

You can ask for the old password and the new password twice. Solves your concern without storing anything critical.

Also: "Must not have been used within your last 20 passwords."

So you just have to provide your last 20 passwords.

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.

jaw drop omg crappy sites that don't do more than store a grocery shopping list have better security.

Crappy sites that don't do more than store a grocery shopping list haven't been in continuous operation for five decades.

Given that the web is only really 35 years old, that's a truism.

Nothing says that legacy systems which are on the internet today can't have started out well before the internet. The legacy system that JetBlue is dealing with in this case has, in fact, been in continuous operation for over five decades.

They use Sabre (like others), and it's an archaic holdover from when phones didn't have Qs or Zs.

Today, I learned that phones didn't have Qs or Zs. Things you don't notice on that one rotary phone your parents used to have when you were 5.

Well, they had to make room for that tetragraph that has since sadly fallen so out of favor, "OPER".

Or the rotary phone your parents still have right now in my case.

Or the antique Bell candlestick rotary phone that my mom has, still hard-wired into a phone nook inset into the plaster walls during construction nearly 100 years ago. And that bad boy still works flawlessly.

Do they still rent it?

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.

since the backend system would have mapped {A,B,C}=1

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

Random tidbit: The "1" digit on a telephone has no letters associated with it; "2" is assigned "ABC".

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

This entropy loss is standard. Try calling the country's leading 401K provider or other banks, they'll ask for your password over the phone keypad.

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.

the fidelity case scared me years ago. amazed they still do that, but I can also imagine that they have a system that only allows the crazy phone mapping when validating over the phone an policy around that on how many times you can try, phone number you try from, etc to minimize brute force attacks to counter the loss of entropy.

That's nothing.... A friend of mine forwarded some emails shes gotten from jet blue.

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

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.

Oh yeah. It's impossible to know who has your plaintext password on the backend (even steam who RSA encrypts your pw with a public key before sending), but this certainly is a bad practice and certainly makes it look like they do not have robust security practices.

If you use the "forget password" link and receive your old password by email, then they more then likely have your plain-text password unless they crack it on the fly?

If you receive your old password then yes, they do have it stored in plaintext. Usually these days forgotten password pages just ask you to create a new one, but if they don't that's a sure sign.

Not so sure; it could still be encrypted (also bad practice)

Still, if you receive your password back, that is a giant red sign screaming insecurity

Or too many end users that forget their passwords. Never underestimate the costs of supporting password resets for nontechnical users.

This is a sentiment often missed by the security community. Good security is good to have, but if it makes the service unusable, it's worthless. And when it comes to the general public, that's a low bar set. Banking PIN codes are laughably poor security, but in general they do quite a reasonable job - people get their banking done, and the banks haven't collapsed in a heap due to PIN-based security violations.

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.

Did you tell her to make sure that password isn't used anywhere else?

She's a computer person too so she knows all this jazz.

oh come on, man

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

I actually have no idea what you're talking about.

All I know is they sent her plaintext passwords to her, which she redacted before sending to me....

oh, I thought it was actually PUT_PASSWORD_HERE placeholders it wasn't clear, you should have put black bars there

Agreed. I thought the same thing.

Is that what they did? Cuz that's not what your edited images show.

those are redactions that were edited into the image - the original had the actual information in it

Google does the same thing, so I guess Jet Blue is in good company.

I don't know about that. Have a source? This is a pretty bad practice so I would be very surprised to see google doing this.

If you have a google apps account, and you create an account for a user (or adminstratively reset their password for them) they will get an email like:

  Hi Tina,
  
  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 tsmith@example.com
  
  You can sign in to Example Association services at:
  
  http://www.google.com/a/example.com

What's the issue? They force a reset so there is no difference between giving a temporary password like this or a URL which is unique to them?

(you will need to change this when you log in)

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.

I can't reply to the post below you for some reason, so I'm posting here.

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.

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.

Or you map them to something like:

Q = ABDHCJSKJDHSSS

Z = YYYDUHUHUHSSYS

... to avoid weakening the password.

I can't tell if you're joking or not, but for the benefit of people who don't know any better: such a scheme would not meaningfully impact the strength of the password storage scheme at all. (To prove it to yourself, think about how rainbow tables work. Then consider how little additional work would be required to replace all Q's and Z's with the appropriate string before making the table. It's not much different from having a "salt" that's the same for every user in your application, which also doesn't meaningfully impact the strength of the password storage scheme.)

Actually, it's a classic case of security through obscurity. If the attacker doesn't know about it and are using a standard rainbow table, then no, it's not going to have "ABDHCJSKJDHSSS" in there and it will make their life harder. Once they do find out, though, it's useless.

Or just map them to asterisks, and call it a hunter2 transform...

"Cannot contain special characters or symbols (such as !#$@*, etc)"

Well, damn! Guess that won't work.

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.

I just changed my Jetblue password to contain both a Q and a Z. Seems the support documentation is out of date.

Have you tried logging in with the same password, minus the Q and Z?

Or with different characters that are keyed with the same digit on a phone, like P, R or S for the Q?

Yes, and it didn't accept them.

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

Seems more likely that Sabre's restriction was because old phone dials (and the keypads that replaced them) didn't have Q or Z:

http://payphonepictures.com/44631-4/IMG_4953.jpg http://www.dreamstime.com/royalty-free-stock-photography-pay...

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.

You missed a 能 after 我.

Yeah, saw that but couldn't edit any longer. Oh well... IBus was not to blame this time.

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.

http://xkcd.com/936/

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.

Don't get me started on PINs.

One issue for IT is having employees write down their passwords. I can imagine something like this would have the same effect and probably decrease security somewhat. Although, take what I say with a grain of salt. I'm not sure how prevalent having your passwords physically stolen outside of a closed environment like a workplace is.

There are a lot more variables at a job than at my house in my locked drawer.

From a usability standpoint I would say it is easier to advise the user that using a commonly used password is a bad idea. Suggest alternatives but ultimately it is their choice.

psswrd123

assword123

Looking through old scripts, you'll sometimes see a matching query for "sername", so you get both Username and username (pseudo case-insensitive) and there's usually a second matching query for... "ssword", because removing "P" gives you "assword", which clearly is improper to put in a script! Harrumph!

Sounds like that script has a back door.

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)

That would also explain the last rule:

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

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

No, there is no way their loyalty program has anything to do with SABRE, any more than Expedia's passwords are stored in SABRE.

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?

I was also curious about this and decided to test it. I created a new account with the password "badpassbadpass" (minimum password length of 8!), but I was unable to log in with "abesassabesass". There was also no error when I tried to put a 'q' and a 'z' in my password, so I'm guessing that they've updated their system since the documentation was written.

I just tried it with 'abcabcabc' as my password. It claims passwords are case sensitive, but both 'abcabcabc' and 'ABCABCABC' work and any variation ('ABCabcaBc' works). Variations based on a phone pad don't seem to work. '123123123' or 'bacbacbac' don't work. I also tried only changing one letter.

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

So for all those saying that we should just "trust the engineers know what they're doing" this is a pretty damning refutation as far as I'm concerned.

It's possible they store both the original password, for use on the web, and the numeric version, for phones.

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"):

[1] Like: http://www.cs.utexas.edu/users/scottm/cs307/utx/assignment5....

Here's a pic of when phone keypads don't have Q and Z: http://www.dialabc.com/words/history.html

I feel so old.

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.

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.

Can anyone explain why this is? I've never heard a security reason for this.

On some older keypad layouts, Q and Z aren't associated with a number. It could be some misguided attempt at backwards compatibility.

Shit poor security? It almost sounds like they end up converting the stored password to digits, based on letters associated with numbers on a standard phone (originally 'Q' and 'Z' were omitted). I wonder if they consider 'ad4jmp' and '2ehkn7' different passwords. That would be an interesting test.

While the other answers about Sabre are probably right, I've heard that banks intentionally have stupid password policies to prevent password reuse. If one bank says "no special characters but most contain a number", another says "must contain a special character, but no numbers", and a 3rd says "must contain a number and special character", they can guarantee that if one of the 3 is hacked into it doesn't compromise people with accounts at all 3 (of course ignoring people using "password" with a 1 or ! on the end).

This would require cooperation.

Guess 1: They append either one of those characters to the password to store some form of information.

Guess 2: The characters are column separators in some form of data store.

Marketing? A sane password policy doesn't get you to #2 on HN.

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.

I consider passwords as random blobs of bytes. Everyone says that hashing is important but I don't see any real benefit of it. If I hash random 128 bits result is random 128 bits.

It's important because if somebody gets your database, if you haven't hashed, they have everybody's passwords, and those passwords are often reused many times at many sites. Hashing at least puts a step between stealing your table and knowing everybody's passwords (a mathematically hard step for good passwords).

Also, please let me know what sites you manage so I know where my data is not valued.

I think everyone is completely missing the reason behind the omission of Q and Z.

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

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.

For everyone who designs password rules: Please do not require the password to contain uppercase, lowercase letter, numbers and so on. Because this actually makes passwords statistically easier guessable. The only thing you should require is a minimum length, I recommend at least 10, better 12 characters. Even 12 digits are more secure than say "Apple1".

Why didn't phone have Q and Z? Everyone is mentioning that they did not have them, but I can't find a reason for that.

it was the simplest way to map 3 letters to each number 1-9 on the keypad.[1] that way you didn't have a few numbers with 4 letters and had a consistent model.

[1] my grandfather explained it this way back in the early '80s. I couldn't find a good link to a more official source.

Except that 3 * 9 = 27, and there are only 26 letters in the English alphabet. They are actually mapped to the numbers 2-9, which leaves the question of why they didn't use 1.

The local prefixes of phone numbers don't/couldn't start with 1. If you map ABC to 1, you can't use those letters as the start of a word. (Your number could be GET-SOME but not AND-MORE.) This is because when you dial without an area code, your leading 1 would be interpreted as a long distance call. This is the same reason they didn't use 0, as that's the start of an international call (011).

ugh, typo. good catch, and good explanation below re: starting a number with an A.

Have you tried it? This person says it works just fine. https://twitter.com/__apf__/status/466327291027804160 And it doesn't make sense that it's a holdover from phones, because then it wouldn't be case-sensitive.

My bank allows only passwords which are six digits like 123456. No longer or other characters or symbols.

Find a new bank. Tell your bank why you switched.

My bank only allows email addresses less than 31 characters in length. I filed a bug report and received a, "thanks, we know..." Fortunately, their password policy isn't as ridiculous.

There might be some very good reasons why such policy may exist. For example this system may involve telling the password to someone over the phone or using a TV remote to enter a password or some other keypad other than QWERTY.

for Bank of America customers, you might notice your mobile app requires you to use a password < 21 characters . There is no such restriction for desktop browsers.

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?

That's ok, here's a better one.

etrade - yeah, THAT etrade? Yeah. They make your passwords case-insensitive.

Charles Schwab silently truncates passwords to 8 characters. Always a fun surprise to accidentally enter a password you use somewhere else and get logged in anyways.

I complained to them a while ago about the fact that they limit passwords to 8 characters. Must have been two years ago and I got a very generic "sorry, we know this could be better and our engineers are working on it. In the mean time, we'll send you an RSA security token fob for two factor authentication if you'd like". Thanks but no thanks, I'd rather not add another item to my keychain to make up for your website's lackluster password requirements.

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.

> Thanks but no thanks, I'd rather not add another item to my keychain to make up for your website's lackluster password requirements.

If you care about keeping your money it may be wise to take the fob and/or find a new bank/broker.

Might not want to add another item to your keychain (or desk drawer), but if you know it's lackluster and you keep your money there, it seems like accepting the token fob would be the smart move .

The only situation I could imagine it weakening the system is if your non-dictionary-word password can be turned into a dictionary word by adding several characters on to the end.

That's nothing. Until late 2000, eTrade stored your password, caeser-ciphered, in a cookie in your browser.

As does Citibank. I imagine it's for telling-support-over-the-phone purposes, which isn't great.

...why would you have to tell them your password in the first place?

UNIX historically truncated passwords to eight characters.

Looks like they removed this requirement recently. We have JetBlue in our presence :O

why not hash the the password and encode it in base34? (36-2)

How can people that stupid be allowed to operate airplanes?

Shouldn't this mean that the OUTPUT FROM THE HASH FUNCTION can't contain Q or Z!? Certainly no system other than the web frontend would be looking at the password itself...

Also no special characters.

http://xkcd.com/936/

My guess, some kind of harebrained master password scheme for support.

My guess is that this is just a rule to force people to read the rules.

It's not an Odesk job post where "please include <some word> in your application" ;)

Reply on news.ycombinator.com