Cleveland, Curveballs and Common Sense Putting 2 and 2 together since 1987.

Ignorance like a gun in hand

Sometimes you’re not even looking for a blog topic and one just smacks you in the face.

I got a call from a cousin this evening who reported that both her e-mail and Facebook account had been hacked. I personally set up the e-mail account (circa 1999) with a very basic password. To this day it had not been changed, and a simple derivative of that password was used for her Facebook account. Thus, while I don’t know for sure how the accounts were hacked, I can infer that when one fell, the other did as well. This hacker had changed the passwords to both of her accounts, leaving her locked out.

I told my cousin how to go about regaining access to her accounts, and hung up the phone. But my mind dwelled a bit – for years, I’ve used the same password on most of my accounts. This password isn’t particularly complex (normally scores a medium when it goes through a password meter), but I’ve rested easy knowing that most account hacking comes through phishing these days, and I’m pretty smart about what I click.

It occurred to me though, that my publicly accessible username to many sites is the same I use to log in, making a potential password cracker’s job half as hard (if you’re trying to get into a lock, it’s hard if you don’t have the key, but it’s even harder when you don’t know where the lock is).

Thus, there were a lot of things working against me: searching my name in Google yields at least 4 pages of search results related to my “web presence” (sorry about the word choice, Mike), I used the same password across most of those services, and that password wasn’t incredibly strong to begin with. That doesn’t even account for the possibility of another RockYou (and let’s face it: the odds for are much greater than the odds against).

So I decided it was time, and set about changing my passwords to all my major accounts (the ones I really care about, anyway). I started with Facebook, moved to my e-mail and Twitter and then my banks.

(Seriously, how messed up is my thought process? And make fun of me if you must, but you know your priorities are exactly the same.)

So I got to my online credit card account. I have a Starbucks Duetto Visa, which is administered by Chase, so I went to chase.com, logged in, and after noticing one of my phone numbers was no longer correct and fixing it, set about changing my password. I chose my password, entered my old one, and entered the new one twice.

Here was the response:

I thought I must have done something wrong at first, but sure enough, after closer inspection of the password change form, I found:

What. The. Crap. I understand the fourth one. The last one doesn’t really make a lot of sense since Chase doesn’t enforce a regular password change anyway. I can understand the second one, but while good practice, the fact that you’re limited like that hurts your password’s security statistically. My confusion in this post, however, is mostly directed at bullet points 1 and 3 here.

Firstly, let’s cover what those two points imply. This means (in all likelihood, anyway) that either my Chase password is stored in plaintext in whatever database they use, or it’s two-way encrypted: that is, given an unencrypted password it can create a ciphertext, and given that same ciphertext it can reproduce your original password.

Non-developers may wonder what the alternative here is: the alternative is a hash, which is a one-way encryption algorithm that, given a plaintext password, can easily make a ciphertext, but given a ciphertext, cannot or cannot easily reproduce the original password. So when you log in to site using a a one-way encrypted password, the site knows how to generate that encrypted text from your password, and simply compares the encrypted text.

So here’s the downside: what if you forget your password? It’s really hard to get back to the plaintext password just given the ciphertext password, so really the only option is to reset the password to some random new password, somehow communicate what that password to you, and let you log in and change it to something you know.

But the upside: storing a one-way encrypted password is easier. For the most part, one-way encryption produces a ciphertext that is the same length each time, making the design of the database easier and more predictable. Also, most one-way functions produce a ciphertext that is simply a number.

Here’s what that means: type in a password of any length, with any symbols you want, and the encryption function and your database can handle it. You don’t need to worry about capping your users’ password length or limiting the symbols they use. Facebook, Twitter, and other sites that don’t limit your password (within reason) use one-way encryption. Based on the errors shown here, it’s clear that Chase uses two-way.

Chase isn’t the only site to do it. In fact, most enterprise sites limit your password length (although, not letting you use symbols is a low blow). But why? By letting in a wider variety of passwords, your Facebook password is potentially safer than your bank password. Is this really what we want?

I understand that banks need to use stronger encryption (and the strongest algorithms are two-way, but take a long time to implement and execute, so are only used when necessary), but why not one-way encrypt the ciphertext of the two-way encrypted password? To me, this seems like the best of both worlds: the speed and flexibility of the one-way encryption; the increased security of two-way encryption.

The only thing this loses, I think, is the ability to simply tell the user their old password if they forget it. Is that what banks are afraid of?

As a postscript, I managed to find a password that is secure for my credit card account. But statistically, my coins in FarmVille (if I played that game) and the status of my pokes on Facebook are safer than my credit card details and transactions. Something is definitely wrong here.