Touchscreens Open To Smudge Attacks 185
nk497 writes "The smudges left behind on touchscreen devices could be used to decipher passwords to gain access, according to researchers at the University of Pennsylvania. The report tested the idea out (PDF) on Android phones, which use a graphical pattern that the user traces to unlock the handset. The researchers took photos of the smudge trails left on the screen and bumped up the contrast, finding they could unlock the phone 92% of the time. While they noted Android 2.2 also offers an alphanumeric password option, the researchers claimed such a smudge attack could be used against other touchscreen interfaces, including bank machines and voting machines. 'In future work, we intend to investigate other devices that may be susceptible, and varied smudge attack styles, such as heat trails caused by the heat transfer of a finger touching a screen,' they said."
Re:Just randomize the keyboard every time (Score:4, Interesting)
A couple of issues with this.
1) the Android set-up doesn't actually use a keyboard: just dots, which you're supposed to join in the same order.
2) I believe that there are patents around the randomising idea.
I'm certainly aware of this issue on my Android phone. The fact that you're supposed to keep your finger on the screen as you join the dots means that there's often a pretty clear track, even if you have clean hands. And you can tell the order in which tracks were made if you have one which crosses over another.
I quite like the technology, but it's good to be reminded of the possible dangers. I'll keep wiping mine once I've logged in.
Graphical Pattern Lock Usage (Score:5, Interesting)
This comes at no surprise. Most people draw simple shapes on the graphical pattern lock. Would you be surprised if your computer was hacked if you set the password to "1234"?
For example, how many of you have drawn a triangle as your pattern? I know I did the first time I used my android phone. Then a few weeks later, when I was on an airplane, I watched a senior gentleman pull out his smart phone and draw the exact same pattern lock as me.
I then sat down and pondered the complexity of passwords using a graphical pattern lock. There's only 9 buttons to use and for most people they tend to only use adjacent buttons when drawing. If one were confined to this set of rules, the passwords would all be linear and simple geometric shapes. However, I figured out through trial and error, that you can actually double back on buttons you've activated and activate buttons that are non-adjacent to active ones by drawing in the blank space in between buttons. This should be a criteria for a strong graphical pattern lock, just like how there's requirements for strong alpha-numerical password locks. You should always have at least one double back button and one non-adjacent button as part of the pattern lock. This way the smudges left on your phone are non-linear.
Re:Rather simple fix (Score:5, Interesting)
Back when I was at MIT, we had utility vehicles on campus and several keypadded gates. The men in trucks drove up to the gates and entered codes. Since I didn't want to build any hardware, I colored the keypad over with a permanent marker in similar color to the keys. I counted the audible beeps emitted by the controller. After a day or so, I went up and saw that only three keys had been depressed for the five beeps. After four tries, I had the code and could pointlessly open the gate for no reason at all at will!
Re:Non touch-screens, too (Score:1, Interesting)
I once read about a similar tactic involving an almost invisible film of oil on the keypad. If the film is thin enough people won't feel it (or see it unless they look closely) but if you know it's there you can see fingerprints.
Re:Non touch-screens, too (Score:3, Interesting)
Yes, I've made use of this myself and have also seen it done similarly in films where the keypad is sprayed with a UV luminescent spray; when illuminated you can easily see which keys are pressed and which aren't.
The obvious "solution" is to require all buttons be pressed (ie, 6 button keypad means 6 digit combinations). One of my gun safes uses an Ilco mechanical lock and you have to push all the buttons; it does allow you to cut the "length" of the combination by using two-button presses as a single combination "digit" but you still have to press all the buttons. The added bonus to combinations is they increase the number of button presses possible when trying to brute force the combination.
Re:Graphical Pattern Lock Usage (Score:3, Interesting)
However, I figured out through trial and error, that you can actually double back on buttons you've activated and activate buttons that are non-adjacent to active ones by drawing in the blank space in between buttons. This should be a criteria for a strong graphical pattern lock
I also noticed this, shortly after I got the idea to use an unlock pattern. Once you noticed those two aspects (ability to draw between buttons, and harmlessly slide over already-activated buttons), the permutations multiply.
With those in mind, here is how unique a randomized unlock pattern can be:
4 dots = 1624 permutations (as weak as a 3 number password!)
5 dots = 7152 permutations (much better, but not by far)
6 dots = 26016 permutations (at least as strong as a 4-digit bank card PIN)
7 dots = 140704 permutations (about as strong as a 5-digit bank card PIN)
As a bonus, choosing more dots reduces the ability for a smudge attack to succeed. But only if you choose a pseudo-random one. Don't kid yourself, one that you come up on your own is biased in favor of a like-minded (i.e. homo sapien) attacker.
To help, here's a quick bit of shell code to easily generate a strong unlock code for an Android phone. It numbers the dots like a telephone: top-left button is 1, top-middle is 2, top-right is 3, ...etc. Just draw the dots in the pattern indicated.
rand -N 9 -M 9 -u | perl -ane '%seen=();%bad=qw(13 2 17 4 19 5 28 5 31 2 37 5 39 6 46 5 64 5 71 4 73 5 79 8 82 5 91 5 93 6 97 8);$last=0;print map {$next=$_+1;$combo=$last.$next;if ($bad{$combo} and not $seen{$bad{$combo}}) {()} else {$seen{$next}=1;$last=$next;$next,"\n"}} @F'
Why not use the orientation sensor instead? (Score:2, Interesting)