21

I'm trying to improve security in a web application. The application has an admin site and keyloggers are a concern that I'm trying to solve. Can the application do something that can prevent keyloggers from working correctly? I've read about Keystroke interference software (for each user keystroke they randomly add more keystrokes not interfering with user input), can something like that be done in javascript?

Schockey
  • 221
  • 2
  • 5
  • 1
    What do you want to protect against keylogging? – Noir Mar 30 '16 at 11:59
  • I have a web site that administrates the server and all users and devices that are connected. I want to protect the login page. – Schockey Mar 30 '16 at 12:02
  • You can't do anything about this except by introducing some kind of OTP. The answer of @Stephane contains everything you need to know. – Noir Mar 30 '16 at 12:05
  • KeePass and similar password managers often have an option to perform exactly what you are mentioning. Beside: if you are using password managers you could simply change your password every day. – Bakuriu Mar 30 '16 at 13:59
  • 7
    two-factor authentication (2FA) might be the solution which can solve your issue. The people which use your websites service sound like they should be aware of the benefits of 2FA and shouldn't retaliate. – MonkeyZeus Mar 30 '16 at 14:40
  • Is the admin back end meant to accessible by only a handful of people at an organization? Or is it meant to be accessed globally by end users not under your control? Because if it is under your control, an ideal alternative strategy would be exercising practices to prevent software/hardware keyloggers from being introduced in the first place. – Bacon Brad Mar 31 '16 at 14:38
  • I'd consider using [U2F](https://en.wikipedia.org/wiki/Universal_2nd_Factor) over traditional one-time passwords. – CodesInChaos Mar 31 '16 at 16:48

4 Answers4

56

Many applications make futile attempt to foil keyloggers and spyware by using convoluted (and cumbersome) password entry methods. None work against keyloggers and many actually cause users to be LESS secure because they make it hard to use password managers.

The best way to handle that kind of things is to use one-time passwords. There are several ways to go about it so let me suggest two: TOTP (RFC 6238) works with many software authenticators (Google authenticator, for instance) so it's both convenient, cheap to implement and free to use. It does require the user to set things up and have a smartphone, though.

Another approach it to send a one time password through SMS. This is a bit more expensive (because you have to send the message) but it's also easier for the user (who only needs a mobile phone and no setup).

Community
  • 1
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • It's also worth noting that the two methods above aren't mutually exclusive. Some sites allow a user to obtain a code by either method. – Lily Finley Mar 30 '16 at 20:15
  • 2
    Also, note that some users have phone numbers that allow access *without* the phone; for instance, everyone with a Google Voice number can access their SMS messages through Google Hangouts. This means that for them, SMS isn't really a second factor at all - it's just another account an attacker could gain access to remotely. – Xiong Chiamiov Mar 30 '16 at 20:36
  • I have authentication on my PC with Authy and 1Password. It might be better to say that it requires the user to download yet another application, as some people get quickly annoyed by that. – Spotlight Mar 30 '16 at 23:05
  • 6
    "None work against keyloggers" remark is incorrect. "None work against (key+mouse+screen)-loggers" would be correct. This might make **some** difference because screen-loggers have to handle more data. – Eugene Ryabtsev Mar 31 '16 at 04:27
  • Regarding the point about the expense of SMS, many (maybe even most) cell phone carriers have Email-to-SMS gateways that let you send free SMS messages to their customers from an email address. For example, in the US, Verizon Wireless customers can receive texts sent to PHONENUMBER@vtext.com, and AT&T customers can get messages using PHONENUMBER@txt.att.net. All you would need to do is ask your users to choose their service provider when they put in their phone number. – Moshe Katz Apr 06 '16 at 02:14
16

If you were dealing with keyloggers in isolation, then it might be possible to mitigate the risk (e.g. using on-screen keyboards, 2FA or similar), however if an attacker has the ability to install a keystroke logger on the system it is very likely (apart from physical keystroke loggers) that they have privileged access to the system in question and as such would be likely able to circumvent any other protections you put in place (assuming that they're motivated to do so)

For example, as this is a web application, say you implement 2FA, once the user has authenticated, a session token is issed and then in general remains valid until an idle timeout occurs or the user explicitly logs out. If an attacker has privileged access to the system it would be possible for them to issue "keep-alive" requests to prevent idle lockout and use browser injection to defeat the logout.

If you're concerned about users accessing a privileged system from compromised clients, the a better solution is to make use of dedicated/locked down devices and restrict access to only those devices.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 1
    +1 for the good point that for situations that really require strong security for a resource using dedicated/hardened clients to access that resource is often necessary. However,I think it's necessary to remember that even if 2FA isn't the magic auth bullet that some think it is when implemented well it (at least) makes the bad guy's job considerably harder & more complicated vs. static auth only. – mostlyinformed Mar 31 '16 at 03:58
  • 1
    @halfinformed I'd agree 2FA can be a very useful control, it all depends on the threat model that's of concern, in this case it's just important to note that it has limitations given the likely way that keyloggers get onto machines (i.e. as part of malware which is likely to have elevated privs to the system and other capabilities) – Rory McCune Mar 31 '16 at 08:30
6

JavaScript cannot control low system calls and change them to get that keystroke interference. Even user-mode software protections are defeated by kernel-mode keylogging.

You can protect against hardware keyloggers by having an onscreen keyboard, which can be easily implemented.

Software keyloggers are more powerful. Smart banking trojans also capture HTTP requests and screenshots when the mouse is clicked in the banking website. Some also steal one-time-passwords or bypass them.

Cristian Dobre
  • 9,797
  • 1
  • 30
  • 50
  • 7
    Onscreen keyboards are inefficient to protect users against spyware and very easy to work against. It's snake oil security. – Stephane Mar 30 '16 at 13:46
  • 11
    @Stephane My unscientific research has shown that implementing an onscreen keyboard to be 100x more secure for sites primarily accessed via desktop browsers because your userbase will shrink to a hundredth of its previous size due to rage quitting. – Dan Is Fiddling By Firelight Mar 30 '16 at 21:23
  • The exact way onscreen keyboards are defeated are described e.g. [here](http://ask-leo.com/will_using_an_on_screen_keyboard_stop_keyboard_loggers_and_hackers.html). This requires a more sophisticated (and software) loggers, but by now these might have gotten some traction. – Eugene Ryabtsev Mar 31 '16 at 04:45
  • Also onscreen keyboards have massive accessibility issues, e.g. for users who can't use a mouse (they *can* be implemented to support tabbing, they generally *aren't*). – Chris H Mar 31 '16 at 09:23
0

If you are concerned about keyloggers that log key strokes (manual password entry) or copy/paste (password manager) then you have to use the mouse:

  1. Show the user a virtual keyboard to enter the password. This is really not very user-friendly and hard to set up for global usage (regional differences in the keyboard layout). I would still let the "not-so-paranoid" users enter their password how they are used to.

or another (peripheral) device:

  1. Two-factor authentication through an app or SMS.
ST2OD
  • 227
  • 1
  • 2
  • 4