SiteKey

Ryan over at 27b/6 has an article up today about SiteKey, and the fact that it doesn’t really do anything. Actually, it’s a link to an NYT piece where one of the researchers concludes that “Sometimes the appearance of security is more important than security itself,” and the the reason Bank of America was willing to pay so much for SiteKey is RSA’s data showing that it overwhelmingly makes customers feel more secure…despite the fact that 58 out of 60 of them ignore it entirely. If you don’t know what SiteKey is, here’s the quick version: when you set up your account, you choose from a bewildering selection of pre-chosen icons that have nothing to do with you and nop significance for you personally. Then when you log into the site, the picture gets shown next to the password box. If you see your picture, you go ahead and enter your password. If you see a different picture, something is wrong. The picture storage and retrieval is supposedly implemented in a way that makes it difficult to fake.

I have a BoA account (unfortunately my credit card company was purchased by them last year), and I can tell you that SiteKey is completely useless. It’s not surprising to me that 58 out of 60 people got it wrong. It’s surprising that 2 out of 60 didn’t. The problem is that it’s difficult to know whether the picture shown is my picture or not. I log on once a month to pay my bill, and that’s it. I don’t spend the other 29 (or 30 or 27 or 28) days of the month constantly reminding myself which 50×50 icon I chose for my account. So when, a month later, I sign in again, the best I can do is say “well, it looks like something I would have chosen.” But then again, 99% of the pictures look like something I might have chosen. None of the pictures are disturbing, nauseating, or even macabre. They’re uniformly pretty and unexceptional. Sailboats? Sure. Venice? why not. A sunset? Who wouldn’t? I’m pretty sure it’s not the teddy bear, but beyond that I couldn’t tell you if the picture next to my name is the one I picked, just another one of the seemingly hundreds I had to flip though, or one that isn’t even a BoA picture at all.

This, as Ryan says, is why phishing attacks work.

More disturbing is the information from the study that 100% of the study participants logged in even when sent to a non-SSL page. Again, that doesn’t suprise me. Users are faced with a bewildering array of visual cues about a site’s security, and an even more bewildering preponderance of sites that don’t properly support major browsers. If everyone refused to continue unless there was a little yellow padlock on the screen, no one would ever get anything done. And that’s assuming that they know what the little yellow lock means, and can find it without their bifocals.

What this really points up the is the major shortcoming of nearly all current security models: they’re optional, and they rely on the end user–almost certainly the least knowledgeable party to the transaction–to ensure the security of the entire transaction. And it’s going to get a lot worse before it gets better. Ajax and our other “Web 2.0″ technologies are directed at one goal: transferring information seamlessly. One of the key features of AJAX/DHTML is the ability to update pages without refreshes and transfer information to servers without requiring a “submit” click. The hidden cost there is that xhttp requests don’t just circumvent cgi form actions, they circumvent the “insecure submission” warnings of browsers.

The suolution here is pretty clear to me: abandon clear HTTP as a protocol. Modern server and client hardware could encrypt all, or at least most, traffic via SSL. Security would be the norm, not an anomaly, and more people might pay attention to the security warnings if they were out of the ordinary.

New Again

Updated to 2.1.

Maybe a sign of more to come?