Entering Passwords Through Eye Movement

Interesting:

Reducing Shoulder-surfing by Using Gaze-based Password Entry

Manu Kumar , Tal Garfinkel, Dan Boneh, Terri Winograd

Abstract:

Shoulder-surfing—using direct observation techniques, such as looking over someone’s shoulder, to get passwords, PINs and other sensitive personal information is a problem that has been difficult to overcome. When a user enters information using a keyboard, mouse, touch screen or any traditional input device, a malicious observer may be able to acquire the user’s password credentials. We present EyePassword, a system that mitigates the issues of shoulder surfing via a novel approach to user input. With EyePassword, a user enters sensitive input (password, PIN, etc.) by selecting from an on-screen keyboard using only the orientation of their pupils (i.e. the position of their gaze on screen), making eavesdropping by a malicious observer largely impractical. We present a number of design choices and discuss their effect on usability and security. We conducted user studies to evaluate the speed, accuracy and user acceptance of our approach. Our results demonstrate that gaze-based password entry requires marginal additional time over using a keyboard, error rates are similar to those of using a keyboard and subjects preferred the gaze-based password entry approach over traditional approaches.

Tags: , ,

Posted on August 30, 2007 at 6:12 AM • 25 Comments

Comments

bob • August 30, 2007 6:50 AM

Our PIN-pads at work frustrate shoulder surfing by having electronic display keys with a narrow field of view (like older LED calculators did) with numbers that “randomize” each time you use it. Very simple yet effective.

Nick Lancaster • August 30, 2007 7:06 AM

I’m wondering if there are associated body movements or tells that might reduce the efficiency of the system, in the sense of people tipping their head or engaging in other behaviors, or if accuracy drops with a distracted user, anyone with a touch of lazy eye, etc.

I like the scrambled keypad idea above. It not only foils shoulder surfing, but requires the user to pay more attention to the action.

Nick Lancaster • August 30, 2007 7:06 AM

I’m wondering if there are associated body movements or tells that might reduce the efficiency of the system, in the sense of people tipping their head or engaging in other behaviors, or if accuracy drops with a distracted user, anyone with a touch of lazy eye, etc.

I like the scrambled keypad idea above. It not only foils shoulder surfing, but requires the user to pay more attention to the action.

Alex • August 30, 2007 7:24 AM

The scrambled keypad has been in use with some departments in the Dutch police for years. Nice example of ‘old’ technology that still is functional and effective

Tim • August 30, 2007 7:54 AM

Uh-oh. If scrambled pinpads start appearing I’ll have to remember my PIN with something better than just the ‘muscle memory’ for my hand…

Omar Herrera • August 30, 2007 8:00 AM

I don’t see much difference with biometrics but recognize that the idea is interesting.

However, I think we keep focusing on the details of just a part of the authentication process. We can have state-of-the-art authentication devices but they won’t be any better than any current technology unless terminals (computers) are secure as well.

Be it a token, this thing or any other technology, as long as we rely on the computer to pass authentication information to the system or application we will be vulnerable to MITM attacks or sniffing via malicious software installed on that computer.

The paper argues that this is better than many other technologies, including tokens, but this approach requires software being installed in the computer to interact with the eye tracking device. Tokens do not require this. Anyway, both approaches pass the authentication credentials through the computer (typed or via software) and therefore rely on its security.

While we focus on solving problems of the past for which we already have several solutions (shoulder surfing in this case, which can be solved in a number of different ways), some criminals are focusing on the present and future (there are several pieces of malware around to steal authentication credentials from tokens, for example).

If we are willing to pay the price of this technology, we just might get a more effective solution with 2-way-authentication devices with on-board cryptographic capabilities (e.g. smartcards with readers with keypads or certain types of tokens) and we could not only authenticate each session but also each transaction.

With shoulder surfing they might be able to get the pin for the device, but they still have to get the device. However, we don’t need to rely on the security of the terminal anymore because all authentication and encryption is done in the device.

Just my opinion

szigi • August 30, 2007 8:04 AM

I think this is an example of an overly complicated system. Equip computers with eye tracking cameras, complex software, and so on. How many bugs wil this generate?
If you do not accept the risk of shoulder-surfing, then probably passwords are insufficient for your applications.
Use a token, a smart card, biometrics, whatever.

In the case of for example ATMs, it is quite easy to cover the pinpad. Numerical pins can even be entered blind (= totally covered keyboard) by nealy anyone. (And passwords of course, if you know touch-typing.)

Wicked Lad • August 30, 2007 8:17 AM

I’m with Omar. Susceptibility to replay (“sniffing via malicious software installed on that computer”) is a significant weakness with this approach. Tokens typically mitigate this risk effectively, and as szigi points out, tokens are much simpler.

Milan • August 30, 2007 9:21 AM

There are also secondary risks created by the introduction of this technology: namely, the introduction of many new video cameras into sensitive workplaces.

A compromised system would then offer an attacker a view into whatever is happening near the ATM, computer, etc.

md • August 30, 2007 9:42 AM

Are there any statistics related to passwords being stolen by observation? Gazed-based input is interesting from a technical point of view, but is the problem it’s solving so great that we really need it?

Also (and I admit I don’t have time to read the full paper) they have to have a way to know where your eyes are looking. Is it more or less invasive than any other retina/iris scan? Can I break the system by just rolling my eyes a lot?

There seem to be a lot of analog solutions to this problem (shielding the key pad, making windows reflective so people can’t look in from the outside, looking over your shoulder before keying in your pin, etc.) that work just as well if not better.

-ac- • August 30, 2007 9:47 AM

It’s great to see new ideas and very thoughtful counters (like Milan) in this area. How many biometric measures will we discover and exhaust? It would seem to be a finite number where each new technique is more complicated that the last.
I think this method could be combined with other methods to foil key-loggers. (see IronKey’s efforts toward the same)

Fred P • August 30, 2007 10:15 AM

Interesting, but it would seem that a small mirror, camera, or trained confederate with a peephole could defeat this.

FP • August 30, 2007 10:53 AM

If someone can install a key logger, they can intercept the camera’s video stream.

Also, this requires the user to actually remember her or his passwords. I don’t. Password Safe remembers them for me. It’s cut and paste approach is robust to shoulder surfing also (albeit only once you’ve entered your master password).

Pat Cahalan • August 30, 2007 11:02 AM

Be it a token, this thing or any other technology, as long as we rely on the
computer to pass authentication information to the system or application we will be
vulnerable to MITM attacks or sniffing via malicious software installed on that computer.

Given that currently I think this is a much bigger attack surface than hardware keystroke loggers that only grab keyboard input or shoulder surfing, I agree with Omar and md.

It is an interesting method, though, with additional benefits (if you’ve ever broken your arm and tried to use a traditional keyboard, something like this would be a welcome alternative, I think).

tk. • August 30, 2007 11:07 AM

I just try to follow Wild Bill’s example and sit with my back to the wall. (I’m not overly fond of people lurking behind me anyway.)

Jared • August 30, 2007 2:26 PM

I highly doubt that this is as fast or as unlikely to produce errors as typing for most regular computer users. I wonder if they had the people type / ‘eye’ in an assigned password, or one they actually use on a regular basis? I can type the passwords I commonly use at a WAY faster pace than my overall typing speed, and I very, very, very rarely make an error. However, I know that when I have to actually look at a keyboard or a layout of characters (QWERTY or otherwise), it takes me much longer to find them. Even with practice, I doubt I could train my eyes to focus on a series of specific characters, in a certain order, without focusing on any others, and be nearly as fast or accurate as I am with my fingers.

As for the security aspect…unless you’ve got a video camera with slow-mo aimed over my shoulder, or you watch me type the same password many many times, I doubt you’re going to figure it out anyways. Interesting idea, but I think I’ll stick to old school.

aikimark • August 30, 2007 2:43 PM

The Abstract.html document has an unbalanced and, therefore, didn’t render in my browser.</p> <p>The full paper is at <a href="http://www.stanford.edu/~talg/papers/SOUPS07/Eyepassword-soups07.pdf" rel="nofollow ugc">http://www.stanford.edu/~talg/papers/SOUPS07/Eyepassword-soups07.pdf</a>

fmcgowan • August 30, 2007 4:11 PM

I don’t know what to call it, but a coworker has demonstrated the ability to read a password as it is typed when he can only see the keyboard and is facing the typist. He has demonstrated this for several others and we are all convinced he is doing what he says.

He says that touch-typists are the most vulnerable to this attack. He cannot be the only one that can do this.

Christoph Zurnieden • September 2, 2007 10:27 AM

If you use a password manager like Clipperz you also get the benefit of one-click login. Therefore
no more shoulder-surfing risks for you!

Your software still needs a password, it only reduces the number of entries. The basic function of a password manager is increasing convenience not security.
The use of Javascript is problematic. You cannot know how the actual implementation works. For example: overwriting the clear text password after hashing might not work because the implementation makes a copy of that memory chunk before you had the chance to act. The reasons for such curious behavior are manifold; you might take a look at http://thedailywtf.com for an admittedly rather incomplete list.

I took a short glimpse at your code and the descriptions on your website. The general construction of the application seems sound but the whole thing is unnecessarily gigantic and needlessly complex, it might content some surprising sideeffects.
I did something like your’s a couple of years ago and had a PoC with a size of about 50 kibibytes (formated and commented. The influence of ShrinkSafe is neglectable if a real compression algorithm like GZip (e.g.: mod_gzip for Apache)), probably 200 kibibytes with some nice and shiny frontend. And mine run on a P1-200, not very fast but usable.

Some more points:
Please delete line 83 of http://www.clipperz.com/users/marco/blog/2007/05/01/when_128_bits_are_not_enough_to_protect_your_passwords or you might get a reservation for the doghouse here (a branch of the Hilbert-chain, so it’s completely unknown why a reservation is needed at all) which you don’t deserve.

Your SHA-256d makes not much sense, please (re)read the original papers of Merkle and Dåmgard. They say that this group of algorithms is secure only if they are “keyed”:
H = hash function with a Merkle Dåmgard algorithm
m = arbitrary message, can be empty
k = secret key of length > 0, better length > |H(m)|
, (a comma) = concatenation operator
h = the resulting hash

h = H(m,k)

Your simple doubling of the hash could also fail completly, there might be a function f such that
f(H(H(m))) = H(m)
even if there is no function g such that
g(H(m)) = m if |m| != |H(m)|
because these hashing algorithms are lossy.

You are padding with null bytes at one place (forgot where, sorry), this may or may not be secure, please check.

The password strength testing does not fully work. I tried it once to build one and ended with a nearly one gibibyte large Bloomfilter with an error rate of 0.01—you may calculate the number of entries yourself. (A Bloomfilter because you want to know which passwords are bad, not which passwords are good). There exists no algorithm to check password strengths, only a check if it is a good mixture out of {isprint(list_latin1())} with a sufficient length where “good enough” is almost always a cause of heated discussions. Oh, and please don’t use the colors red and green or any mixture out of them as an indicator because there are too many colorblind people.

CZ

PS: your Terms of Services might break euopean law, please consult a lawyer before you start to use it commercial.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.