Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Parent Full thread

> 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).

It hurts when you’re so old the kids don’t even know the countermeasure, let alone the threat it defeated.

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.

Are you saying you wouldn't be concerned if you found one of these on your computer? https://www.keelog.com/

You may have replied to the wrong comment. The comment above is about malware, which those are not.

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).

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.

Wait -- so that website sells keyloggers and, uh, Commodore 64 power supplies? Talk about diversification!

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.

That's why keyloggers also log the title of an active window.

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.

It makes far more sense to assume threat actors are commercial malware authors rather than toy projects, since that's the reality in the world.

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.

Reply on news.ycombinator.com