> They require you to enter your password by clicking on a virtual keyboard. This pseudo-security measure actually only slows down humans, not bots, because you can still edit the value of the text field using Javascript.
I don't think this is generally worth it as a security measure, but the goal is not to protect against automation. Instead, custom on-screen keyboards are attempts to thwart keyloggers.
> Instead, custom on-screen keyboards are attempts to thwart keyloggers.
Commercial malware doesn't work this way. The term "keylogger" is a misnomer.
"Keylogging" without context provides an unintelligible stream of garbage that might have well be from a random number generator. Most malware that I've seen either directly target the browser or the operating system, but in both cases they're looking for an unencrypted HTTPS stream, that they can re-package, upload, and store. With the goal to sell batches of credentials for specific websites.
Many people have this unusual belief that a user's stream of keys would look like e.g. www.example.com(13)username(9)password(13). But that isn't how users typically interact with their browsers, MOST websites are accessed via a search engine or favorites/bookmarks, and users often won't use the keystrokes to navigate between input elements.
Again, CONTEXT is everything with "keylogging," since most of the value is generated from WHERE not just WHAT. "Targeted credential theft" is a better way to describe it since they're stealing structured HTTP form data, not raw keyboard input (and even if they were steaming keycode inputs, they'd likely still be using the browser's context to do so).
So, in my opinion, most malware wouldn't even be aware or need specific support to bypass this virtual keyboard "security" because by the very nature of them they aren't operating at this layer anyway.
> Commercial malware doesn't work this way. The term "keylogger" is a misnomer.
I don't know about commercial malware, but at least in the 90s (which is when these kinds of on-screen keyboards started to appear), it was not unusual to find on a computer "infected" with malware a text file containing every key that was pressed since the malware was installed.
Yes, nowadays malware tends to be much smarter: also capturing an image of the area around the mouse pointer on every click (which is the reason some on-screen keyboards blank the keys when you click), only logging when the window has an specific title (which is the reason some online banking sites add lots of random spaces and punctuation to the window title), or even using lower-level code to hook into the browser and directly capture the form contents on submission (which is the reason several online banking sites require you to use invasive "anti-malware" plugins which attempt to prevent these kinds of hooks).
There's a surprising amount of malware out there that still actually captures keyboard input and nothing else. It's easier and more reliable to implement, especially in a malware context, and is usually plenty enough to extract what the operator wants (usually usernames and passwords for online banking). When additional context is collected it's often in the form of window titles. A lot of tools now gather screenshots and even better on-click screenshots, which defeat this type of on-screen keyboard device and is the main reason it's fallen out of use.
And yes, there is malware that collects unencrypted traffic, but that is _appreciably_ more complex to design and implement than simple keylogging. There's also malware which pulls credentials directly out of the web browser memory, although improved protections on cross-process memory access are making this much harder to do on real operating systems. Both of these are better methods, but they are harder and operating systems are intentionally implementing measure to defeat them. For mostly historic reasons straightforward keylogging remains easy and reliable on modern computers.
The top-level comment you replied to doesn’t mention malware.
In any case, both hardware and software keyloggers exist which would be thwarted by an onscreen keyboard. If I recall correctly, mouse keyboards became popular when keyloggers started being more known, and the following generation of malware took screenshots every time you clicked.
It’s a very obsolete security measure but did make sense briefly.
I think they replied to the right one, making the point that the long comment about malware is missing the point about the type of keylogger this is trying to protect against (because many people also, quite reasonably, use the term "keylogger" as a vague description for password-stealing malware).
Thank you for the general explanation of the state of the art, which makes a lot of sense if one thinks about it.
But it doesn't really refute the kind of snapshot-in-time voodoo that government websites tend to build out and then never change because if doing so were to cause a problem, then someone could get blamed. I've never seen such a UI contraption in the "private" sector of banking. Not that they don't have their own obtuse slow moving corporate bullshit like snake oil "2FA" with varying requirements, it's just less bad.
FWIW related to this topic does anyone know the details of how the IRS website just decides to spit out "Permission Denied" when trying to obtain an EIN? I think it's an Akamai? message, probably due to some user surveillance garbage, but haven't investigated further. Even coming from my own naive residential IP with surveillance-friendly Chromium I still got it. I figured I'd wait a few days and try again, but same thing. It worked fine from a vanilla iPhone on the cell connection, but unfortunately I ended up doing that too late and missed the window to lock in April's rate.
So the malware is running in the user's context, and has the browser's window handle and instead of using that to hook the child input elements directly, they're going to store an unintelligible stream of keystrokes then use the window handle to bundle that with the window's title? Is that a reasonable way to implement malware? Will it result in high quality data for resale?
One of those "Things programmers believe about malware" articles needs to be written. There's a lot of "Schrödinger's cat"-level thinking going on, wherein malware is both running with full rights of the user while ALSO somehow needs to rely on raw keystrokes to record anything.
I think a simple keylogger that also reads window titles is much easier to build, than to read and control content inside a browser.
This kind of technique would work really well if they are targeting a small group of users.
One can argue that reading browser content through a browser extension would be equally easy to implement, but that's harder to hide and limits your scope to only browser activity.
Even if a naive keylogger is only capturing keystrokes and sending that file somewhere. It's a simple script to search for email addresses and then assume the next 8-64 characters are the password. How many of us type in a web address, then go type something else. Then return to the web site and type the user name, go back to work on an email, then come back and type the password?
I would guess approximately no one does this as standard behavior.
Which is ridiculously annoying. I have to edit the HTML every single time to remove "readonly" on that field and paste in my randomly generated password.
That's why I use tampermonkey/userscripts. Make a script that removes disabled property from all form elements in the page, and set it to run when the document finishes loading on every website, then disable it so you can turn it on when necessary. I've got a number of similar scripts (the most used one is generally enabled; it prevents squarespace sites from navigating to a site login even I hit esc to stop the page from loading).
Why are some fields like that? I have never understood why. It happens a lot when entering in bank account numbers. I am almost always copying and pasting the bank account number directly from my bank's website, but yet, these fields require me to type it in, increasing the possibility of a mistake.
I wish I could remember where I saw this UX, but the best is when they not only don't let you paste, but also treat the bank account number like a password field and don't let you see what you're typing in... and you have to do it 2x.
Most likely because the amount of furor and kerfuffle that would be created when "the security system broke" would basically be equal quantities of facepalm and hustle that would phase between canceling each other out and producing undirected chaos.
Like, this brand of "security" is being persisted with, in 2022, when virtually nothing else uses this sort of approach, and the writing's been on the wall for so long you almost can't see the wall for the writing anymore. And yet.
At the end of the day from an actual-security standpoint there's a lot to be said for generally rooting this kind of thing out and doing away with it, but given the direct association to vaults and banks and government (and probably military) systems and whatnot it's one situation where the blowback might genuinely cause enough bad press to require a summary firing or two as a token of reassurance to the type of old-world mindset in charge of this sort of thing. Maybe.
*shrug* that's a worst-case-scenario imagining what might happen, at least. I honestly have no idea. I just get strong "swim away!!" vibes from it, heh
It will enrage you to find out that some sites actually track the value, and if more than one character changes per keystroke, it'll reset the value. It's rare, but I have seen it.
In fact, if you notice when you log in the next time, (for many people) your browser may offer to autocomplete your password and bypass the mouse-driven keyboard, so it's definitely not even hard to thwart.
Android keyboard always runs in its own process. No distinction between first-party and third-party either as they're both just regular apps like the launcher or browser. One simply is the default.
Screenshots wouldn't be of much help. The frequency would need to be almost like a low-fps video recording in order to capture the buttons' pressed state. At that is assuming the state is visually distinct in the first place.
The usual way a keylogger like this would work is taking a screenshot on every mouse click (and maybe every few keystrokes), with the mouse pointer location recorded alongside (if not visible in the screenshot). It is a lot more difficult than just recording keystrokes though.
My intuition tells me that nowadays, if you can embed an arbitrary program "keylogger" onto a computer, it should also log most user events, not just "keyboard events", including screenshots of areas around mouse clicks, maybe a small OCR module etc.
Of course, a physical keylogger is a different beast, but really, if you got physical access enough to install an actual piece of hardware...
I don't think this is generally worth it as a security measure, but the goal is not to protect against automation. Instead, custom on-screen keyboards are attempts to thwart keyloggers.