Who’s who of bad password practices – banks, airlines and more

Ah, passwords. Love ‘em or hate ‘em, they’re a necessary evil of the digital age. The reality is we all end up with an alphabet soup of passwords spread over dozens of various sites and services across the internet. Whilst we might not always practice it, we all know the theory of creating a good password; uniqueness, randomness and length. The more of each, the better.

Of course we frequently don’t do this because of all sorts of human factors such as convenience, memory or simple unawareness of the risks. Still, when it’s a case of individuals electing not to create secure passwords, they really only have themselves to blame.

But what happens when the website won’t allow you to create a secure password? Or at least when they severely constrain your ability to create long, random, unique passwords? And what about when they don’t allow you to send it between your computer and their server securely?

Even worse, what happens when our most “secure” institutions implement lazy password policies? Unfortunately, all of this is pretty rampant practice.

Why bother?

Recently I went on a bit of a binge. The whole Gawker situation got me a bit worried and whilst I didn’t exactly reuse the same weak password in every location, I was taking some risks I really shouldn’t have been. Call it old habits.

So I coughed up a few dollars and got my hands on 1Password. The theory is simple; create one secure password you can remember then protect all your other long, random unique ones that you can’t remember with it. The beauty of this approach is that once you let go of the “I must be able to remember and easily type my password” mentality, you can start creating really, really secure passwords. 1Password will even help you generate them:

All that was left was to go through each and every site where I had a password and replace the old one with a seriously secure version. Couldn’t be easier than that right? Wrong, oh so very wrong…

No SSL

In my password reset travels, the most frequent bad practice was SSL. Well actually, it was not having SSL and this practice is everywhere.

Last week I got a bit righteous about the whole thing when I wrote about Why your app’s security design could affect sales of Acai berries, effectively saying that we, as developers, have a responsibility to secure all credentials, even the ones securing content we may not deem as sensitive.

If you weren’t living under a rock last October you would have heard about Firesheep. This little tool showed just how easy it to capture unencrypted network traffic. Actually, Firesheep was sophisticated enough to steal sessions even if the logon occurred over SSL. It’s a very stark reminder of just how vulnerable unencrypted HTTP traffic is and by all accounts, it’s rather popular (and most likely prevalent):

The worst culprits are clearly forums. I can only assume it’s that old “security not that important concept” raising its ugly head again but almost without exception, SSL is nowhere to be seen. Now keep in mind also that SSL is cheap; you’re talking in the tens of dollars per year to get a foot in the transport layer security door.

So who are the culprits? They literally wouldn’t all fit in one post so perhaps some of the various industries. Automotive, for example, in the form of 6 Speed Online:

How about investment? You know, the industry that deals with heaps of money and probably should have a bit of an idea about how to protect customers. Not something PropertyInvesting.com is aware of, obviously:

But Simple Talk? From the very fantastic guys at Red Gate? This one is pretty surprising:

I mean it’s not like they write about security or anything, right?!

Update: No, none of these post to HTTPS either. More info in “Update 1” below.

Length matters (and so does complexity)

Firstly, a little bit of combinations and permutations 101; the more characters with the greater range of values, the more possible combinations you can have. As these increase, so does the uncertainty – or entropy – of the password. This is a good thing.

A four digit password has 10^4 or 10,000 combinations.

Make it a four character password allowing letters and numbers and you’re up to 36^4 (10 numbers plus 26 letters) or 1,679,616 combinations.

Make it four case sensitive characters and you’re up to 62^4 (10 numbers plus 26 lowercase letters plus 26 uppercase letters) and we’re at 14,776,336 combinations.

Make it 10 case sensitive characters including numbers and suddenly we’re up to a huge 839,299,365,868,340,000 combinations. And so on and so forth.

From a brute force attack perspective, this is a very good thing indeed. And just in case this is starting to sound a bit excessive, how about being able to test 400,000 passwords a second for only 28 cents a minute? Things are starting to get very, very interesting.

Sidenote: yes, yes, there should always maximum failed attempts before lockout and all of that sort of thing but that assumption only works when you’re talking about authenticating through the intended channels. It’s a whole different ballgame when your database is disclosed and someone starts working their way through encrypted passwords…

Moving on, LinkedIn starts out ok; min length, recommendation for different character types even SSL, but then goes and chops you off at 16 chars:

What’s going on here? I mean, how many bytes are they honestly saving here? What drove them to say “I think 16 is just fine”? And how long should a password be allowed to be? Sure, you’re got to cut it somewhere but passwords of this length (and less), are clearly the exception. At least based on my experiences recently.

But it gets worse. How about TomTom:

I know GPSs can make you do pretty stupid things, but does it have to extend to their password policy?!

Still, I think we can do better. Or is that “worse”?

Ok, the twelve character limit isn’t good but it’s also no worse than TomTom (although shouldn’t a bank be significantly better than a mere GPS manufacturer?). But no spaces! Really?! And what the hell is a “special character”? No, really, I have no idea. Is it a punctuation character? Or something else? They didn’t tell me I couldn’t use one before I entered it then they didn’t tell me which one it was after I entered it!

Surely this is an exceptional example within the financial industry? Uh, unfortunately not:

Ok, Amex gets some marks for at least being upfront about what you can and can’t do but not case sensitive! Mixing upper and lower case characters is something everyone knows they should do and Amex throws that right out the window. Regardless of how secure you want to make your password, they’re not going to let you implement some of the most basic strong password naming practices.

But the good news is that Amex is aware of it and as it turns out, this is a security feature:

I would like to inform you that our website has a 128 bit encryption. With this base, passwords that comprise only of letters and alphabets create an algorithm that is difficult to crack. We discourage the use of special characters because hacking softwares can recognize them very easily.

The length of the password is limited to 8 characters to reduce keyboard contact. Some softwares can decipher a password based on the information of "most common keys pressed".

Therefore, lesser keys punched in a given frame of time lessen the possibility of the password being cracked.

I think I actually feel dumber for having read that.

So why is this happening? Why keep passwords short and rule out a whole bunch of characters? Inevitably there are various touch-points where length needs to be declared (input field max length, data type size, etc.) but why only 12 or 16 chars? Is the difference between that and, say, 50 chars really an issue?

As for the character types, I suspect it’s more of an escaping and possibly an XSS concern or maybe even worries about injection, but are these really an issue in this day and age? Most frameworks either implement the required escaping natively or have easy access to libraries which can take care of this, is it really a problem that someone wants to use a quote or an angle bracket?

After all that, you reckon those short, simple passwords were bad? Wait until you see who’s using PINs…

PINs

Let’s move on to a frankly ridiculous practice that totally goes against the grain of the good password entropy concepts of length and randomness concepts; PINs.

Right off the bat, a personal identification number is going to be a, uh, number i.e. each character has 10 possible values. That’s pretty bad on its own but what about really short PINs? Who would do such a thing?!

Singapore Airlines for starters:

No amount of smiling Singapore girls is going to make me feel better about the fact that it only takes six little numbers (and no SSL) to jump in and look at my travel history and book flights with my points. And the KrisFlyer number? The one readily shared with travel agents and even printed on luggage tags? Don’t bank on that one being secure!

Thank that’s bad? Those guys were generous allowing a whole six digit PIN! Qantas reckons four is just fine:

Saving valuable database storage bytes so they can channel the funds back into engine maintenance perhaps?

Update: SIA and Qantas do actually post to HTTPS but of course, that’s only part of the SSL value proposition. More info below in “Update 1”.

Airlines screwing up basic security measures is one thing, but banks?! Surely not, I mean these guys are the pinnacle of security right? The driving force behind such initiatives as PCI; they should be beyond reproach. But are they?

But probably the worst offender is ING Direct:

This is a freakin’ four digit PIN! On a bank account! It’s exactly the same length and randomness that I use to protect my undies when I fly:

But wait! They’re aware of the issue and are upping the ante on security:

I asked why my bank needed to have a less secure password than my Twitter but then everything went a bit quiet.

Look, I get the history with PINs; in days gone by they were the password de jour. They secured your bike lock, you could enter them into a touch-tone telephone, heck, you could even pull money out of the hole in the wall with a four digit PIN. But of course all of these interfaces needed nothing more complex than a PIN. There’s a reason you don’t see bike locks with QWERTY keyboards!

But of course these devices weren’t all connected to the world like the websites of today are. Sure, having a PIN means you can easily enter into the phone as well as the internet but seriously, when you’ve got a selection of characters like this right in front of your customers:

Why the hell do you give them this?!

Just plain weird and stupid security

And now the worst of the worst; the ones that just failed catastrophically at some real fundamentals. These are the sites which have done simply unexplainable things well beyond my comprehension. And I don’t think that’s just a problem with my understanding of app security!

Let’s start with realestate.com.au, Australia’s premier property website, and try to change the password on an existing account:

Ok, no SSL, that’s not real good but so far it’s simply a “dumb” security practice. Let’s change the password to something secure:

Uh, what just happened? And why does this happen every single time I change my password to something secure? What is plainly not obvious is that my password contained a “>”. Nowhere am I told I can’t use one before creating my password and nowhere am I told what went wrong what I did use one. It took trial and error before I could figure out what password I was even allowed to use! Ah well, everything went ok after that, right? Uh, no:

C’mon, seriously?! I create a beautiful, strong password and then you turn around and automatically email the damn thing to me in plain text? Clearly they’re not aware of this and it was the work of some rogue developer somewhere, right?

Oh cool, they’re working on it. When was that tweet again? The really ridiculous thing is that there’s a legitimate password reset function which will email a newly generated one so there appears to be some cognisance of how password management should occur (although a single use reset URL would be preferable), but that also kind of makes the experience above all that much stranger.

As bad as realestate.com.au is, they don’t have a monopoly on the bad / weird stuff. How about DotNetKicks:

So let me get this straight; I use my stubby fingers to enter many characters of different case and type which appear only as obfuscated dots and I only have to do this once? There’s zero verification that I actually got it right and that’s just plain unusual.

Here’s another one from the “weird file” courtesy of GoDaddy:

What, exactly, is a “typeable” character? It sounds like an obvious question but I suspect it means “typeable on a western keyboard”. But what if I’m in Istanbul? Can I use a “ç”? Or if I’m in Kyoto, can I use Kanji and type “??”? I honestly have no idea!

Update (2 Apr 11): It turns out GoDaddy does have a bit of info on allowable password characters, they just don’t make it accessible when you really need it i.e. on the password change screen (GoFigure?) This page also goes on to espouse the virtues of phrase generated passwords which as I’ve said before, is totally infeasible if you actually want to make them unique across all your accounts.

And while we’re talking about weird practices, what’s going on at TPG?!

It all started out looking so good; SSL, a minimum requirement of 2 letters and 2 numbers and even a max reset per day setting. But eight characters – I mean exactly eight characters – what’s that about?! Why so short? And why not 7, or 9? And why is my current password not exactly eight characters? It’s all very strange.

Mind you, at least I could actually change my password to something on these sites. Now maybe I’m missing something obvious and I’m just in a password induced stupor lately, but I have absolutely no idea how to change my DZone password:

Yes, I’ve drilled into “Edit your settings” and it’s not there. No, it’s not under “Your Account” – this is that page already so there’s nothing there. I just simply can’t find it! I’ll actually be surprised if there’s not a password change facility but the fact I can’t easily find one is a usability problem in itself.

Speaking of usability, what the hell is going on at Medicare?!

I think I know what they’re getting at but it’s like they’re missing some brackets somewhere. Is it card and ref number or IHI number and DOB and password? Or is it card and ref number or IHI number and DOB and password? Who knows, all I know for sure is that authentication is not the place to be having usability problems.

What does password management done right look like?

Of course we all have very little idea about how passwords and security in general is handled behind the facade of the web UI. Maybe realestate.com.au does a fantastic job of the important bits we don’t see and some of the sites I really trust do a terrible job. All we have to go by is what we can directly observe.

So just looking at the obvious things which are readily disclosed through the user experience, take a look at myOpenID:

SSL? Check.

Long password? Check.

No character restrictions? Check.

It’s really that simple. In fact the elegance of the approach myOpenID has taken is more about what they don’t ask you to do rather than what they do ask you to do.

The myOpenID example is actually pretty apt because it kind of holds what could be the key to the whole password dilemma; federated identities. Jeff Atwood is virtually the self-appointed messiah of the “don’t create your own authentication service” movement and he makes a very good case, particularly well-illustrated in his latest post about The Dirty Truth About Web Passwords. Of course he also has the success story to back it up.

Open ID or OAuth or Facebook Connect or Live ID or whatever aren’t perfect, indeed there are some good arguments against them (Rob Connery sums up the privacy issues pretty well in DotNetRocks #626). But compared to some of the examples above? I know who I’d trust.

Summary

I’m not setting out to say each of the sites above is “insecure”. Observing one small part of an application as complex as a banking system doesn’t give anyone enough information to say that with any fairness.

But security is one of those things to be approached in layers. There’s no silver bullet that suddenly makes everything alright, rather it’s an orchestration of many different practices. Those practices should include transport layer security and they should allow customers to create long, random passwords. Even Vodaphone, who let’s face it, have a pretty laissez-faire approach to security, can still get these basics right:

Anyway, the point I wanted to make with all this is that too many sites are doing passwords stupidly. The lack of consistency and downright odd requirements then not securing them when they’re floating around the wires is not doing customers any favours and the ridiculous thing about it is that the solution should be easy – it’s mostly about just taking stuff away.

Take way the short limits, take away the restrictions on typeable characters, on spaces, on angle brackets – just get rid of them! In fact the only thing they really need to add is SSL – and that’s a no-brainer in this day and age. Or alternatively, just acknowledge they can’t get authentication right and leave it to Open ID. I’d be happy with that.

Update 1

A couple of commenters have left some feedback below which I think deserves an update. You can see the comment for yourself, but the bit I want to address is that websites loaded over HTTP can still legitimately post to HTTPS and criticising a site for doing elsewise is fear mongering. I want to illustrate the response visually hence the update to the post:

The big problem you’ve got with the HTTP to HTTPS post situation is that the purpose of SSL is not purely to encrypt data over transport. It’s also there to create confidence and certainty of the identity of the site you’re posting to which is not apparent without visibly loading the certificate into the browser before posting. Wikipedia summarises it nicely:

A web browser validates that an SSL (Transport Layer Security) web server is authentic, so that the user can feel secure that their interaction with the web site has no eavesdroppers and that the web site is who it claims to be.

The ramifications of practices like DNS poisoning on this should be clear. Keep this in mind when looking at logging on to a page loaded over HTTPS on the left versus HTTP on the right:

When I logon to ANZ, I have certainty that my credentials are being sent to www.anz.com. When I logon to Qantas, I have nothing more to go by than the address in the URL bar. If I’m sitting in an airport on the other side of the world using the free wifi, what confidence do I have that the real www.qanatss.com.au has been loaded?

Of course the certificate is also there to assure the customer their data is encrypted. Without the ubiquitous browser padlock, the customer has no certainty of this and must trust – without assurance – that their credentials are safe. Definitely not ideal.