7 ms·
> 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
by jefftk 5y ago
> 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.
- supernova87a 5y agoIn 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.
- tashbarg 5y agoSo, in the described scenario, the password never shows up in the keyloggers log. Works as intended.
- jrimbault 5y agoBut if there's a keylogger installed, why would the same keylogger not take regular screenshots ?
- jtc331 5y agoNot if it’s a physical keylogger, which I think was the primary concern.
- oli-g 5y agoScreenshots 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.
- rcxdude 5y agoThe 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.
- Jochim 5y agoWouldn't you just need to screenshot on any mouse click/return key event?
- tpxl 5y agoSome keyloggers do printscreens on mouse presses, bypassing this issue.
- stjohnswarts 5y agoscreenshots take up a LOT more data than text. seems unlikely unless you have an advanced script kiddie specifically targetting you.
- jcrawfordor 5y agothere are indeed keyloggers that do this, but it wasn't common in the early 2000s when most of these on-screen keyboard setups were implemented.
- jrimbault 5y ago
- newsclues 5y agoIf the goal is to prevent automation, they failed because it can be done with JavaScript.
- adar 5y agoAre you sure you correctly read the post you're replying to?
- ntkachov 5y agoWhich 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.
- yesenadam 5y ago> I have to edit the HTML every single time to remove "readonly" on that field Couldn't you do that with a bookmarklet, so it would just take one click?
- folmar 5y agoGiven websites with CSP bookmarklets generally are a dead thing now as they are usually blocked by the policies.
- efreak 5y agoThat'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).
- bmitc 5y agoWhy 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.
- loeg 5y agoFaux security measure. You could blame the PMs or the customers. Why browsers enable it, I'm not sure.
- jhanschoo 5y agoEspecially, I suppose, third-party keyboards on Android. My bank's Android app uses an in-app PIN pad for this purpose.
- scarface74 5y agoThat’s because of design flaws in how Android handles third party keyboards that iOS has mitigations against for third party keyboards 1. They don’t have network access by default. It’s not a simple confirmation screen to enable network access. You have to go into settings 2. Apps can explicitly disallow third party keyboards for password entry. 3. Keyboards run out of process from the app. And yes, iOS has extensibility support for third party password managers.
- Jake_Wharton 5y agoAndroid 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.
- Someone1234 5y ago> 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.
- codedokode 5y agoThat's why keyloggers also log the title of an active window.
- Someone1234 5y agoSo 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.