I came across an interesting solution to this while paying at a restaurant in Ecuador: they used an Android device which randomized the position of the numbers of the on-screen keypad before each transaction.
The original intent is to make it much harder for onlookers to guess your pin based on finger movements. This could however apply equally well to the usecase of the article.
It is a bit of a usability trade-off though as you can't enter a pin using muscle memory alone anymore, as you must first understand the current keypad layout.
Interesting! I'd love to see what happens when somebody studies that. That surely creates a much larger inter-digit delay as people hunt for the right numbers. So I'd bet it's harder if the attacker can't also see the screen, but easier if they can.
Y. S. Ryu, D. H. Koh, B. L. Aday, X. A. Gutierrez, and J. D. Platt. Usability evaluation of randomized keypad. Journal of Usability Studies,
5(2), 2010.
What I was hoping somebody would study is the ability of practiced thieves to get the PIN under both circumstances. But this does indeed show that it's slower, which would certainly make shoulder-surfing easier.
One quibble I have with the study is that they used novel PINs. I know I'm much faster when typing my real PIN than an arbitrary one. So I suspect the time penalty for random digit layout is larger than they show here.
> But this does indeed show that it's slower, which would certainly make shoulder-surfing easier.
I wouldn't say certainly.
There's more time to observe each keystroke but you have to know what the keystroke is. I've deduced people's 4 digit pin, by accident, from an angle where I can barely see their screen. Randomizing the keypad prevents this.
I think it would only make shoulder-surfing easier if the shoulder-surfer was willing to make what they were doing more apparent.
Also if this was widespread, which I suppose it never will be, people would become used to the randomized keyboard and probably be able to do it a lot quicker.
This is also standard in certain secure facilities and I've visited companies that use them. They're called scramble pads. I think you get better at entering the numbers, and you wait until you see the sequence before going for the pad.
I believe scrambling should work the best if you scramble the keypad for every digit entered, rather than for the whole of them at once. Otherwise at least the same key presses should be immediately recognisable?
I heard about a device that had fewer keys say 5 only, one for each finger, but to use it you had to insert your hand into a slot in the machine so it’s completely invisible from the outside what keys you’re pressing. Presumably in theory they could use one slot for each hand to get to the full 10 digit range.
Trezor did it for Crypto (so you could use the wallet in a keylogged environment). The screen (on the device) changes the numbers and you type using the location on an on-screen numpad (on your computer screen).
Trezor has a separate screen... that screen has your numbers, your computer screen has a blank grid of 3x3. You look at the Trezor and press the correct number in the blank grid.
I remember when Runescape added that to opening your bank account. Perhaps it was to deter bots, but also to stop any key/mouse loggers from giving away your secrets.
randomizing the position is also great to prevent people from reading the fingerprints on the screen. after the oleophobic coating has worn off, it's really easy to hand somebody a freshly-cleaned screen and see where their four finger presses were when they hand it back.
When I was in Barcelona an ATM had its keypad numbers flipped (7 8 9; 4 5 6; 1 2 3), which I only realized after the first attempt. Second attempt I got my PIN wrong, and I did not dare to try it a third (and final) attempt. Apparently it's really muscle memory.
You could shrink the keypad and randomly place it on the screen. Or independently change the width and height of the columns and rows of buttons. Or combine the two. This would make it harder to guess the PIN from the accelerometer and you could still use your muscle memory. Designers would have a fit though.
Edit: though on reflection, this might make no difference. Knowing the relative locations of the key presses is probably enough.
Perhaps randomly changing the layout? Sometimes the keys are presented in a circular format, another in a figure-8, zigzag, odd numbers at the top of the screen, even at the bottom, etc.
Another tactic might be to have randomized extra keys that show up in a different color or position that aren't a part of the actual PIN but that must all be pressed, in any order, to intermix in the sequence as the the real PIN is entered in proper order. The extra numbers obfuscate the real PIN.
Say, the real PIN is 18145 but 4 extra keys in a distinct color or motif are presented so that the key presses might be 1-8 (real) 8-4 (false) 1-4 (real) 3-6 (false) 5 (real) but the false keys are different each time. It wouldn't matter what order the false keys are pressed or when in the sequence they are pressed as they are ignored by the real PIN mechanism.
... or, some numbers in the PIN require being pressed some random number of times until the key graphically indicates it is accepted. 1-8-1-4-5 might need to be entered as 1-1-8-1-4-4-4-5-5 with the repeat number differing each time.
Or the PIN pad can be presented with a random requirement to slide between 2 or 3 sequential digits rather than lift and tap. Tap-1-Slide-8-1-4-Tap-5.
A few years ago, ANZ Bank offered such a device that they called FastPay. It connected to their mobile phone POS app and helped randomized the PIN entry on the app. Here's their marketing demonstration on it https://youtu.be/I27-B36SaAg?t=80
I'm not sure if it was so much to defend against this type of attack as it was to ensure that no software could intercept taps on the screen and derive your PIN. I believe that the part of PCI rules that cover PIN entry led to this implementation, since this is a mobile POS app running on a potentially hostile device. Typically, POS vendors build dedicated hardware for PIN entry because it's much easier to lock down a system that they have full control over, and thus comply with PCI rules.
(For what it's worth, PCI now has rules on software-based PIN entry on mobile phones.)
Both LineageOS and GrapheneOS have this feature, it was extremely useful in the past, until FBE (File Based Encryption) took over from FDE (Full Disk Encryption).
You can't separate the lockscreen password and the startup password anymore, so we lost the usability of unlocking using a shorter scrambled PIN but still retaining a longer passphrase for FDE when the device was powered off.
None of this was ever a supported thing, it had to be manually done using `vdc` frontend to `vold` but it was a nice feature.
There's a potential secondary usability trade-off. I only know my PIN by the pattern it makes on the keys. I don't actually have the numbers memorized, just the positional order on a standard keypad layout. So if the numbers are randomized, I would have a really hard time.
It's also a hell of annoying. Since in 99% of the cases noone is looking over your shoulder it's OK to not give me a puzzle every time.
Also, with consistent numpad I'm able to enter all digits super-quick which is very hard to track. While with randomized numpad I need 5 seconds to find my numbers.
I’ve also seen it with another bank (BNP Paribas), which is pretty good on phones but annoying on website, since it breaks my password manager. They load images with numbers but I can’t spot any obvious pattern in the requests (which is probably a good design).
I had this feature enabled on my old phone, on which I had flashed LineageOS. Unfortunately the new phone's stock ROM doesn't have that, but it also features a fingerprint sensor, so I don't really type my passcode that frequently anymore.
I have found that when I try to enter a password on my phone that I have previously only used on a computer, I sometimes have retained nothing but muscle memory which doesn't translate from keyboard to touchscreen.
My French bank uses this as well (on desktop), and the numbers can’t be typed they have to be clicked on. I think it’s not common enough but a good security feature against attack vectors we don’t reall think about
I had not realised it was in Android proper, I have only seen it in Cyanogenmod. I wonder if it wasn't used more because people didn't know about it, and didn't realise how much safer it was. Sad that they removed it.
"Figure out" means, in this case, classify. So it can tell which of 50 is 'the one'if its in that set. That's a hell of a long way away from decoding your PIN from the tens of thousands possible.
This was a paper from 2013 though, 7 years ago. I'm sure they've more than made it a proper technology now, with all the compute power and deep learning and what not.
Maybe unrelated, but WhatsApp does monitor your phone accelerometer data 100% of the time, even when it's in the background. An app doesn't even need to ask for permission to get access to the accelerometer data, so there's not even a pop up of any sort.
I suspect issues like this are one of the reasons why iOS locked down accelerometer access in Safari. Motion sensors have a lot more potential for malicious use than most users think.
The accelerometer calibration can be detected by websites and is a way to identify users. On the other side the use case for websites is pretty limited.
I was going to say Apple must have became aware of such flaw a year ago (iOS 12.2). However checking back on the article I see it is from 2013! So for all this time nothing has been done, Apple reacted last year, and Google has done nothing.
Worrying.
By locked down, do you mean requiring justification to get through the app store or accessing the data at all? The latter is no problem for iOS-only [0] or Flutter [1]. I've been spending much time with cross-platform sensor access in Flutter. It works.
This stuff is so fascinating... and so frustrating. Now browsers have accelerometer data behind a permission prompt. It makes total sense given stuff like this but it used to be a nice little way to create immediately playable games, apply visual parallax-y effects... and now we have permission prompts sat in front of that.
I guess I’m not blaming anyone here, just amazed that there isn’t any data source that doesn’t leak something sensitive!
I don't see the issue there: it is good if my browser tells me what is going on and leaves the decision to me.
Of course in an ideal world we would be able to trust the sites we visit enough to not jave our browsera protect us, but that is not how a ad financed web worka sadly
It's probably not that simple and clear cut. There are probably some reasonable use cases for apps that need the accelerometer on continuously. Which makes it a trade-off.
One example could be a pedometer / activity tracker app that totals up your number of steps per day. Suppose the user decides to get on a treadmill and walk for 30 minutes but finds it boring so they text their friends while doing it. Maybe they have the keyboard open the entire time, so at the end of their 30 minutes of exercise, the pedometer registers zero activity.
Or maybe you have an app that uses certain accelerometer-based gestures to trigger certain actions. If Android gets an update that turns off the accelerometer when the keyboard is open, many users won't understand why the gesture only works sometimes, and the app developer will get a ton of bug reports.
And you'd be creating these potential problems to solve a privacy leak which doesn't seem that severe given that it can only give you weak information about a person's pin.
I'm not saying that shutting off the accelerometer isn't ultimately the right decision, but I am saying it's not a no-brainer.
Doesn't Android know when the user is authenticating? How many seconds a day are you inputting to the lock screen? Doesn't need to be for any time the keyboard is open. (Of course, doing it semi randomly is also now necessary, to obscure user unlock times.)
As to weak info, you do it again and again, I'd say it's pretty good info.
If you're only trying to solve the very narrow problem of entering a PIN to authenticate to the system, then sure. When you said "during keyboard input", I thought you were being more general, but I suppose you must have meant during keyboard input of the system PIN.
I don't think that PIN is the only sensitive information that matters, though. Android supports a numeric keypad input mode for apps. If I'm entering my credit card number into some app (Lyft, Amazon Shopping, etc.), that seems pretty sensitive. Maybe more sensitive than the system PIN even, because if I know your system PIN, I can't necessarily do anything with it unless I have physical access to your device or you've re-used the same PIN elsewhere.
I imagine it could be a useful signal - most "touch" on a particular key at the instant the accelerometer gives largest jerk ... might help to avoid false keying?
I use it all the time to correct password mistakes: I would be really irritated if that went away: in fact, I frequently use devtools on my laptop to change password inputs to text inputs
After five guesses it could spot Pins about 43% of the time [...] these results were produced when Pins and patterns were picked from a 50-strong set of numbers and shapes.
By requesting access to it. To a user that just installed a e.g. step counting app that wouldn't be suspicious.
Otherwise on Android apps would need to request accessibility feature access to be able to monitor keyboard input into other apps (and there is an explicit warning), or, which is most common, request an overlay permission and start a "phishing overlay" if a targeted app is started by the user.
The original intent is to make it much harder for onlookers to guess your pin based on finger movements. This could however apply equally well to the usecase of the article.
It is a bit of a usability trade-off though as you can't enter a pin using muscle memory alone anymore, as you must first understand the current keypad layout.
https://uxpajournal.org/usability-evaluation-of-randomized-k...
What I was hoping somebody would study is the ability of practiced thieves to get the PIN under both circumstances. But this does indeed show that it's slower, which would certainly make shoulder-surfing easier.
One quibble I have with the study is that they used novel PINs. I know I'm much faster when typing my real PIN than an arbitrary one. So I suspect the time penalty for random digit layout is larger than they show here.
I wouldn't say certainly.
There's more time to observe each keystroke but you have to know what the keystroke is. I've deduced people's 4 digit pin, by accident, from an angle where I can barely see their screen. Randomizing the keypad prevents this.
Also if this was widespread, which I suppose it never will be, people would become used to the randomized keyboard and probably be able to do it a lot quicker.
Edit: Added more context.
Edit: though on reflection, this might make no difference. Knowing the relative locations of the key presses is probably enough.
Another tactic might be to have randomized extra keys that show up in a different color or position that aren't a part of the actual PIN but that must all be pressed, in any order, to intermix in the sequence as the the real PIN is entered in proper order. The extra numbers obfuscate the real PIN.
Say, the real PIN is 18145 but 4 extra keys in a distinct color or motif are presented so that the key presses might be 1-8 (real) 8-4 (false) 1-4 (real) 3-6 (false) 5 (real) but the false keys are different each time. It wouldn't matter what order the false keys are pressed or when in the sequence they are pressed as they are ignored by the real PIN mechanism.
Or the PIN pad can be presented with a random requirement to slide between 2 or 3 sequential digits rather than lift and tap. Tap-1-Slide-8-1-4-Tap-5.
I'm not sure if it was so much to defend against this type of attack as it was to ensure that no software could intercept taps on the screen and derive your PIN. I believe that the part of PCI rules that cover PIN entry led to this implementation, since this is a mobile POS app running on a potentially hostile device. Typically, POS vendors build dedicated hardware for PIN entry because it's much easier to lock down a system that they have full control over, and thus comply with PCI rules.
(For what it's worth, PCI now has rules on software-based PIN entry on mobile phones.)
You can't separate the lockscreen password and the startup password anymore, so we lost the usability of unlocking using a shorter scrambled PIN but still retaining a longer passphrase for FDE when the device was powered off.
None of this was ever a supported thing, it had to be manually done using `vdc` frontend to `vold` but it was a nice feature.
Also, with consistent numpad I'm able to enter all digits super-quick which is very hard to track. While with randomized numpad I need 5 seconds to find my numbers.
https://www.identiv.com/products/physical-access/readers/hir...
Couldn't this also be solved using a piece of plastic that shields view of the keypad to people not standing directly over it?
This is a not very uncommon type of keypad used for high security facilities, where you may need to scan a proximity card and then enter a PIN.
Source for this? Did anyone call them out on it? What plausible reason is there to have it on 24/7?
https://www.reddit.com/r/lgg6/comments/7yxk0a/whatsapp_insan...
https://sensorid.cl.cam.ac.uk/
[0] https://developer.apple.com/documentation/coremotion/getting...
[1] https://pub.dev/packages/sensors
I guess I’m not blaming anyone here, just amazed that there isn’t any data source that doesn’t leak something sensitive!
Of course in an ideal world we would be able to trust the sites we visit enough to not jave our browsera protect us, but that is not how a ad financed web worka sadly
One example could be a pedometer / activity tracker app that totals up your number of steps per day. Suppose the user decides to get on a treadmill and walk for 30 minutes but finds it boring so they text their friends while doing it. Maybe they have the keyboard open the entire time, so at the end of their 30 minutes of exercise, the pedometer registers zero activity.
Or maybe you have an app that uses certain accelerometer-based gestures to trigger certain actions. If Android gets an update that turns off the accelerometer when the keyboard is open, many users won't understand why the gesture only works sometimes, and the app developer will get a ton of bug reports.
And you'd be creating these potential problems to solve a privacy leak which doesn't seem that severe given that it can only give you weak information about a person's pin.
I'm not saying that shutting off the accelerometer isn't ultimately the right decision, but I am saying it's not a no-brainer.
As to weak info, you do it again and again, I'd say it's pretty good info.
I don't think that PIN is the only sensitive information that matters, though. Android supports a numeric keypad input mode for apps. If I'm entering my credit card number into some app (Lyft, Amazon Shopping, etc.), that seems pretty sensitive. Maybe more sensitive than the system PIN even, because if I know your system PIN, I can't necessarily do anything with it unless I have physical access to your device or you've re-used the same PIN elsewhere.
After five guesses it could spot Pins about 43% of the time [...] these results were produced when Pins and patterns were picked from a 50-strong set of numbers and shapes.
(2015)
Surely if you have enough privilege to get that, you could just get input data directly?
Otherwise on Android apps would need to request accessibility feature access to be able to monitor keyboard input into other apps (and there is an explicit warning), or, which is most common, request an overlay permission and start a "phishing overlay" if a targeted app is started by the user.