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?
-
1What do you want to protect against keylogging?– NoirMar 30, 2016 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.– SchockeyMar 30, 2016 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.– NoirMar 30, 2016 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.– BakuriuMar 30, 2016 at 13:59
-
7two-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.– MonkeyZeusMar 30, 2016 at 14:40
4 Answers
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).
-
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. Mar 30, 2016 at 20:15
-
2Also, 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. Mar 30, 2016 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. Mar 30, 2016 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. Mar 31, 2016 at 4: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. Apr 6, 2016 at 2:14
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.
-
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. Mar 31, 2016 at 3: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) Mar 31, 2016 at 8:30
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.
-
7Onscreen keyboards are inefficient to protect users against spyware and very easy to work against. It's snake oil security.– StephaneMar 30, 2016 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. Mar 30, 2016 at 21:23
-
The exact way onscreen keyboards are defeated are described e.g. here. This requires a more sophisticated (and software) loggers, but by now these might have gotten some traction. Mar 31, 2016 at 4: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 HMar 31, 2016 at 9:23
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:
- 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:
- Two-factor authentication through an app or SMS.