My favorite domestic American airline, JetBlue, just signed me up for a program called Travel Bank, which allows its customers to receive and manage redeemable credit from the company. I know this because they sent me three emails about it, just now: one to introduce me to the program, one to inform me that they added $50 credit to it because of a cancellation I had to deal with yesterday, and one with my new account’s password.

This is what part of the third email looked like, with a slight edit by me:

Screenshot of JetBlue email with my password blotted out

Instead of that orange blob, the third email contained my JetBlue.com account’s password, in plainly readable text. As a service to me, they had clearly applied my normal JetBlue website password to this new credit account, and then told me what it was, just to make everything clear and confusion-free.

These emails taught me two things. First, JetBlue continues to deserve my respect as the least terrible of the larger U.S. airlines. I didn’t expect a credit at all; honestly, I felt lucky to have received, at the gate, a $20 airport-food voucher to spend during my unplanned five-hour wait to fly to a more distant city. While it added lots of hassle to both my day and that of my wife, who now needed to drive an additional hundred miles to pick me up, I know that bad luck happens, and I appreciate and accept the token of apology that 50 bucks represents. (And, yes, I would rather suffer a cancellation than fly on a mechanically questionable plane.)

Secondly — well, I started writing this blog post with a chip on my shoulder about the unpleasant surprise I felt to discover, incontrovertibly, that JetBlue stores its customers’ passwords as plain-text strings. (Or, at best, using some sort of two-way cipher, ultimately no more secure than plain text.) It serves as world-visible proof, outside of my personal software-engineering experience, of my earlier post regarding the lack of care that many web-present businesses have when it comes to encrypting customers’ secret data.

But, honestly, JetBlue’s behavior in this regard isn’t exceptionally bad — it’s merely no better than typical, and very likely driven by a genuine desire to provide friendly, low-friction customer service as much as possible. That’s really a core point of my earlier article: the companies who store passwords in plaintext — who I consider so numerous that one should assume all websites do it — do not do so out of malice. They do it because nobody at the company has ever seen a reason to completely understand the importance or purpose of encrypting secret information.

I find it easy to sympathize with this lack of understanding. At first glance, one-way password encryption seems more like an expensive impediment to swift customer service than an easy way to protect customers’ private information. (To say nothing of a potential savior to the company’s reputation in the case of data theft.) And if one’s core business is, say, operating a low-cost airline on famously razor-thin profit margins, maybe thinking any harder about one’s authentication procedures past Can customers log in? Yes? Good has an uncertain return on investment, at best.

So, given everything, I can feel mildly disappointed with JetBlue for not exceeding my expectations in this regard, but I can hardly feel upset with them.

And anyway, it reflects at least as poorly on me that I recognized my password at all! Were I perfectly practicing the user-side password hygiene that I preach, the email would have contained a string of gobbledegook no more memorable than any other long, site-specific, automatically generated password. Instead, I saw one of the short phrases from a years-old “keychain” of memorized passwords that I, probably like the vast majority of users, have applied over and over again across the web. I have been gradually phasing these out, but clearly I’ve got a lot more cleaning up to do.

How to respond to this post.


Next post: Reptiloid spambots from outer space

Previous post: Listen to me chat about Perl for an hour

Loading responses...

Share a response

To share a response that links to this page from somewhere else on the web, paste its URL here.