Guessing smart phone PINs by monitoring the accelerometer
schneier.com
schneier.com
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.
Couldn't this also be solved using a piece of plastic that shields view of the keypad to people not standing directly over it?
https://www.identiv.com/products/physical-access/readers/hir...
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'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.)
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.
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.
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...
[0] https://developer.apple.com/documentation/coremotion/getting...
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.