Security Skins

Much has been written about the insecurity of passwords. Aside from being guessable, people are regularly tricked into providing their passwords to rogue servers because they can’t distinguish spoofed windows and webpages from legitimate ones.

Here’s a clever scheme by Rachna Dhamija and Doug Tygar at the University of California Berkeley that tries to deal with the problem. It’s called “Dynamic Security Skins,” and it’s a pair of protocols that augment passwords.

First, the authors propose creating a trusted window in the browser dedicated to username and password entry. The user chooses a photographic image (or is assigned a random image), which is overlaid across the window and text entry boxes. If the window displays the user’s personal image, it is safe for the user to enter his password.

Second, to prove its identity, the server generates a unique abstract image for each user and each transaction. This image is used to create a “skin” that automatically customizes the browser window or the user interface elements in the content of a webpage. The user’s browser can independently reach the same image that it expects to receive from the server. To verify the server, the user only has to visually verify that the images match.

Not a perfect solution by any means—much Internet fraud bypasses authentication altogether—but two clever ideas that use visual cues to ensure security. You can also verify server authenticity by inspecting the SSL certificate, but no one does that. With this scheme, the user has to recognize only one image and remember one password, no matter how many servers he interacts with. In contrast, the recently announced Site Key (Bank of America’s implementation of the Passmark scheme) requires users to save a different image with each server.

Tags: authentication, browsers, passwords, SSL, web

Posted on July 1, 2005 at 7:31 AM • 16 Comments

Comments

Clive Robinson • July 1, 2005 11:27 AM

On the face of it it sounds interesting.

However how do you go about creating a “trusted window in the browser” reliably.

I suspect that if this method gains acceptance, it will not be long before somebody works out a way of getting at the “trusted window”. Most browsers are written to prevent SandBox to OS escapes and take/have little or no protection for the oposit direction.

Dorothea Salo • July 1, 2005 12:22 PM

And a visually-impaired person does what exactly?

john konglathu • July 1, 2005 12:27 PM

You could do something similar with sound and random words for the visually impaired.

bert • July 1, 2005 12:40 PM

This in the same ballpark as the Firefox address bar that changes color on sites using https. I think one of the real values of this sort of approach — using non-intrusive GUI elements — is that it gives even the most casual, security-oblivious user a visual cue that raises questions and awareness. It seems to be The Right Way to notify the user that a secure protocol is in use and that it is worth their attention.
Looking at the paper, the cue itself is also effective while still being appropriate, i.e. its not an annoying pop-up window with a “Don’t ask me again” check-box, or an easy-to-ignore icon at the bottom of the browser.

Michael McKay • July 1, 2005 2:09 PM

SD Forum’s Security SIG recently had a demonstration from Louis Gaperini, CTO of Passmark. They use a similar method, where users can identify the host by looking for a particular set of “passmarks” (http://www.passmarksecurity.com/twoWay.jsp).

The Passmark solution looked like a grab bag of different techniques, but I suspect it will work fairly well in the real world. They make a lot of effort to avoid inconveniencing the end user, but still look to have some effective verification methods (I like their approach towards escalating verification).

directorblue • July 2, 2005 5:34 AM

I (and others) have critiqued the SiteKey approach here ( http://directorblue.blogspot.com/2005/05/bank-of-america-takes-on-cyberscams.html ) as potentially susceptible to MITM attacks.

A couple of the problems I see in the Dhamija/Tygar paper include “boil the ocean” extensions to web browsers and web servers in support of their (albeit creative) ideas. Unfortunately, the likelihood of users and server owners upgrading their technologies to support this approach seems (to me) unlikely.

An alternative method for fighting phishing (including MITM attacks) — compatible with legacy browsers and web servers — is described (
http://directorblue.blogspot.com/2005/06/making-phishers-solve-captcha-problem.html ) here.

David Cowan • July 2, 2005 9:25 AM

Director Blue:
The “captcha” solution described by Doug Ross is easily cirumvented by MITM attackers. True, it’s hard to muck with the image, but MITM attackers can simply not show the image/checklist altogether to their victims, possibly replacing it with their own. Who would know?

David • July 2, 2005 2:40 PM

For many casual users, they won’t remember the picture either when this solution is deployed on a per-application/host basis rather than integrated within the browser itself. The problem of remembering lots of passwords is not much better than remembering lots of images, many of which will be similar in overall look even if the details may be quite distinct. If the image is part of the browser authentication, presumably I’d only need to worry about one image, and that would be trivial. Of course, it means that any browser I’m on much first identify me well enough to determine if there’s an image or not associated with me. Only then can it prompt for a password.

People are good are remembering faces over names. Pictures are good cues. Sound is a good cue. The key is to personalize these without ending up having too many personalized pictures/sounds that I can’t really remember them.

Naturally, some solutions like this will work well with high activity, frequently visited sites. They tend to suffer when using a site that’s rarely visited.

Mike Owens • July 2, 2005 4:02 PM

A simplified, naturally-occurring version of this effect can be seen just by browsing the web with on an “alternate” (ie: non-Windows) OS.

Many subversive advertisements mimic the appearance of the default Windows interface in order look like urgent messages from the OS. These obviously look totally out of place if browsing on Unix, for example. The broadcast nature of the trick is exposed because the user expects a different, specific style from real widgets.

This only works because the other party must send its image without any way to query the user’s system for appearance information.

Replace this mere ignorance with a generated shared secret (on account creation) between a user and a website, and I think you’d have an effective defense against broadcast-style phishing.

OzJuggler • July 3, 2005 12:04 AM

We should expect to see new algorithms for representing a 16 byte hash code as an abstract image being created soon. This will allow the entire gamut of things whose substance is fragile with respect to bit representation to be easily verified visually – in much the same way as PGP already displays public key fingerprints in form of a table of English words.

The usual arguments about secure usage of hashcodes still apply, but it’s rather pointless to explain them to the end users when there is not much the end user can do about it.

Nick Brooke • July 4, 2005 10:10 AM

@Mike:
Or if you have to use a Windows box for browsing, skin the GUI (cf. Stardock’s WindowBlinds and the Wincustomize site for options). Fake popup message dialogues have never looked lamer…

x • July 7, 2005 4:07 AM

Give me a break. Yeah, use an entirely different OS environment, or for-pay crashware that slows down your system so as not to be fooled by fake dialog boxes. That makes sense.

Patrick Coyle • July 12, 2005 3:52 AM

“You can also verify server authenticity by inspecting the SSL certificate, but no one does that.”

I do… Does that make me odd? I check the authentication to the root level. Really thinking about this it’s only as good as the issuing authority but so far it hasn’t sent me wrong (that I know of).

Curt Sampson • July 14, 2005 3:48 PM

It almost seems to me that we’re trying to introduce new security mechanisms not to compensate for flaws in existing security mechanisms, but to compensate for flaws in their UIs. If browsers displayed the protocol, host and URI in separate fields (with further fields appearing for name, password, etc.) instead of combining them together in the location bar, a lot of the tricks people use to disguise what site you’re connecting to wouldn’t work. And one shouldn’t indicate that a particular page is SSL, but display what host the browser connected to, and indicate that that host was secure. If it makes connections to more than one host to secure the page, it should display a list of all of the hosts, and the security status of each.

If the primary problem is that the users don’t really know what site they’re connected to, that’s no big surprise, since the UI doesn’t make that easy to find out.

brent • February 9, 2006 3:44 AM

One of the problems I see; as someone who has worked for years in network and user security space, with flooding the browser with text as directorblue suggests that users do not read, period. No amount of text will make a user read and all text can be overridden by a phishing site.

Lets take for example the points you made

telling the user to look at the URL of the page, this is so easy to change it is not worth discussing. in a addition you are doing a disservice to users by training them to trust DNS names. As many of you know DNS records can be poisoned or even proxy tagged.
your display of geo location information can also be easily spoofed by anyone who can download and implement Maxminds rather bug ridden system. it also does not take into account that many Ip addresses today do not have even basic location information known about it, like the vast bulk of AOL IP blocks. So again you are training a user on something presented to the user that is dynamic and unreliable. This makes it prime hunting ground for fraud.
Check numbers? Does anyone reading this remember what check you have used in the past month or year? I sure can not and this is also information that can be captured and redisplayed to the user if they bother to even read any of this in the first place.

Finally on a subject I can not stand, Captcha. Why do so many “experts” fall in love with what was always intended to be a stop gap measure. Captcha was never designed to stop fraud it was just a system to make it expensive and cost prohibitive for spammers to flood sites.

First off it can be redisplayed to the user and then MIM’ed to the target site. second given how error prone the use of these are you can not penalize users for making mistakes.

Secondly I have trouble using them late at night or after some drinking, can you only imagine what your mother would suffer through? She would never want to user the system again and that is the biggest problem with some of these solutions. They are not user friendly, they may offer security but at a high cost of usability and adoption.

Now a large camp of folks are always pushing to have users look for the little lock icon at the bottom of the browser. I experimented with this and placed a very believable looking icon at the bottom of the page with a little script to hide the bottom bar I even fooled my coworkers into thinking it was a secured site.

Face it people user education is only going to get us so far. I don’t know what the solution is or even where to start but things like Passmark and sitekey are a step in the right direction.

Jay • November 1, 2006 3:27 PM

I know this is an old thread, but I’ve just now been introduced to SiteKey on a site I use. I think it has a more heinous flaw than the MITM attacks everyone seems to be concerned about. Namely, while it may or may not reduce the risk of phishing attacks, all the implementations I’ve found seem to DECREASE the difficulty of brute-force hacking attacks.

Let me explain. The usual method of username/password input would simply generate one failure method if EITHER your username or password didn’t jive with the authentication database. This left a brute-force attacker without any way of knowing if he/she was even attacking a valid account name.

Now move on to SiteKey: In order to show your “personal image” the website will have you enter ONLY your username at first. Then they show you your personal image to tell you it’s ok to enter your passcode. However, if you enter an invalid username, they TELL YOU that it’s invalid.

So… armed with a printout of myspace uernames, it should be relatively easy to find out which of those same usernames exist at BankX’s site.

What these sites SHOULD do is simply display a RANDOM SiteKey image if an invalid username is entered and still prompt for a password. Then they’d move back to the “have to be guessed in pairs” method of old.

Security Skins

Comments

Leave a comment Cancel reply