Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Client side malware (keyloggers, screenscrapers etc.) is a great risk. It can't be effectively stopped from side of ordinary application. Only users themselves can do some measures to prevent risk from them. But people don't care.

Can web application do anything to reduce risk from client-side malware? If not, can ordinary application (i.e. standalone application that is installed by user to his computer) do it?

share|improve this question
I recall a bank system (probably they used ActiveX) was (at least they claimed they were) able to detect a virus on a computer that was connecting to their login. I recall the user said that IE was required for the login to work, but I did not actually check the computer for viruses myself. This would indicate that web applications, only sort of can - meaning they require access to the computer, for example using ActiveX. Ordinary applications could too,, but I think this is not their job. If they take this on they would only be scanning for knowns like an antivirus would/should. – George Bailey Jul 11 '12 at 14:16

I do not think there is a practical way of dealing with this issue in a technical fashion. Never underestimate how stupid untrained users can be when it comes to handling their own systems.

Like @George Bailey mentioned, from a web app point of view, the users system is out of your control, and the user can download basically anything onto it. This problem is multiplied by the fact that most Windows user run Administrator accounts for day-to-day work.

Besides user education, I doubt there are any effective means to reduce the threat of client-side malware.

If you would really want to mitigate the threat of client-side malware somewhat, how about requiring the user to utilise an antivirus before allowing access into your web app, just like how some VPN implementation fuctions.

share|improve this answer

You can't do anything significant, but don't fear -- its not your responsibility.

At best, you can require that users access your web app only from machines that are heavily restricted (e.g., ordinary users do not have administrator privileges), have strong IT policies in place (e.g., no downloading browser extensions), and have built in security (running anti-virus that's up to date, etc.) that's less likely to have malware on it.

This is what is done for most companies' intranet deployed by competent IT staff to protect their internal systems; though is not possible for a web application open to the public.

Note stuff like 2-factor authentication is not that difficult to circumvent in practice by someone who fully controls an insecure system. They can read from disk the cookie used to indicate successfully passing the first factor (even if its HTTP only and secure), combine it with the password (recorded by the keylogger), and then set up a socks proxy server from the attacked system that they direct their traffic through (allowing the attacker to appear to your web app as the same as it was when they originally logged in).

Also note ideas like only typing in part of your password actually dramatically lowers security. It either (a) forces the server to store the password in plaintext (or reversible encryption, decrypted on each login, which is functionally equivalent, as any possibly malicious administrator on that system can decrypt your password) or (b) requires them to hash a finite number of k-combination of selected letters of your password. But if you are required to type 3 letters from your password on each login selected from 62 alphanumeric characters, there's only 623 ~ 238328 hashes in the sample space. Even with a very slow bcrypt hash (that takes say .1s per hash; at a strengthening factor of about 108 over a standard hash), you can brute force a combination in at most a few hours. (And again, due to repeats they may already know 1 or 2 characters from observing a login making the problem even simpler). Or if the application uses persistent login credentials through cookies, they could just use that to save themselves the hassle.

EDIT: Using only restricted machines to access security critical applications is quite standard; by client-side security we mean the client computer versus the server computer (not necessarily a customer). Also, if you have ever used an ATM to deposit/withdraw money, its a locked-down restricted well-managed machine that proactively is monitored to keep malware off. (Sure people can put modify the system; e.g., put hardware to read the cards; record pin numbers; etc. but banks do their best to keep the hardware safe & malware free).

Yes, 2-factor authentication is harder to break as you a login requires two separate pieces of information. As a concrete example, say attacker A is attacking google's 2-factor implementation and has complete control over user U's machine due to malware installed. U logins in with a remembered password, and typing a one-time password received via text message every time they login from a new machine (but afterwards remembered for ~2 weeks). Now A has three different attack mechanisms all resulting in full control of U's account:

  • A let's U login as normal, but just modifies U's actions. U installed a browser script that loads a hidden frame/tab to simulate actions on the bank's website to transfer money to an off-shore account the attacker controls, while indicating to U that the bank website is going down for routine maintenance for the next 6 hours.

  • A lets U login as normal, and steals the cookie that indicates they have successfully authenticated against the mobile phone question (and users a keylogger to get the pw) or steals the cookie that indicates the combination of the mobile phone + password question. If A can't login because the IP address/browser user-agent changed, they can set up a proxy on U's machine to access the internet from U's computer and copy all the user-agent/browser fingerprinting settings from U.

  • A simply redirect U to an attacker controlled page for your standard MITM attack. U then goes to an A controlled mirror of U's website. (On U's computer the hosts file or the DNS server is changed to one that A controls and has altered to replace the banks website to point to an attacker controlled IP address). When U logs in, A connects to the real bank and says send the mobile phone one-time code to U's phone. U thinking everything is kosher then types in the code to the fake website. There's no https issues, as you control their machine and added new certificates to their browser and altered their hosts file or DNS servers to point to your system. You then login impersonating them with all the information that they graciously gave you. If there's a security image you have no problem getting it from the real website, as your script automatically pulls it and sends it to them.

Bottom Line: Its a bad idea to pretend that you can safely let people login to your systems with client-side malware. In general, you can't and its a losing game to try. And as for worrying about customers complaining, because malware they installed lost their savings -- its not your fault.

What a bank would need to do is be able to alert customers of notable activity (send an email for money transfers) and allow a suitable grace period before transactions are finalized when they can be reversed. And you have no fear of worrying about losing customers to rival banks over this issue; your rival banks are just as unprotected against this sort of threat as you are.

That's not to say banks should not offer two-factor authentication, security questions, etc. as those methods do increase security. They do not prevent someone who fully controls the computer you login to your bank at from attacking you, but they do prevent other risks. People are notorious for choosing weak passwords, reusing the same password in multiple places, typing one password at a different site, etc. Thus you can compromise your reused bank password by some method (say it matched your weak unsalted linkedin password that was leaked), but an attacker cannot do anything with it at your bank since they can't pass the first stage.

share|improve this answer
1. It depends, if you are responsible for bank-website and malware steal cash from your clients, then that clients will blame you. So you're gonna lose your reputation and potential customers. 2. The question wasn't about employee policy, but the policy which should be used on customers. You can't force them to use restricted machines to access your web-service. How can you imagine that? They have to visit your company to use "protected" computers? Then what's the sense of your online app? – p____h Jul 11 '12 at 21:53
3. No, 2-factor auth. is hard to compromise, if it's implemented correctly. As its name says, it should use TWO, separate factors, like PC+mobile. I could give you an access to my notebook. Could you easily gain access to my cell-phone then? Easily - 'cos time-consuming will encourage attackers to find another target, less secured, which means less expensive to attack. 4. As i said in my comments above: typing part of the password has some disadvantages, but if you want to use it additionaly (e.g. as one of 2-factor auth), then it's pretty nice first-line-defense against keyloggers. – p____h Jul 11 '12 at 21:54
@p____h The question was about web apps, so 'client-side' refers to [client]( in the client-server sense, not necessarily a customer's computer. There are plenty of internal web-apps in use in many organizations, where client PCs are kept malware-free by good policy. If you authenticate to a service on a compromised machine, attackers can intercept and steal your full credentials or alter your actions to do something malicious. Its that simple. You can have two-factor authentication or only partial passwords, but an attacker can still MITM. – dr jimbob Jul 12 '12 at 6:59
@p____h And the MITM can do it successfully as they modified your browser/installed new certificates/altered /etc/hosts so it is a secure connection to the bank's site. Liability is important. A bank should make every effort to assist victims, but clearly recognize that they have no way of solving it as the problem arose from a virus obtained elsewhere and loss of credentials. It is the banks responsibility to notify of money transfers, bill payments, address changes, suspicious activity, and to have a sufficient delay to attempt to cancel them. Not to prevent malware accessing a webapp. – dr jimbob Jul 12 '12 at 7:01

To my knowledge, you are severely limited unless you take the role of an antivirus, which requires privileges on the computer, which can be granted to a webapp through Java or ActiveX, etc. However, even that is spotty.

  • Providing and requiring a hardware token such as YubiKey will mitigate the keylogger problem by providing automated disposable passwords.
  • Preventing (where possible) any data from making it to the disk: (make sure your cookies are session only, make sure your pages are no-cache, and, as suggested by p____h, disable autocomplete) (this item may be worth a separate question)

However, beyond that (screen scrapers), the problem remains, you are using hardware that is beyond your control. The user is able to download anything into the computer, malicious or otherwise.

You could advise (or require) the use of non-Windows systems. (ChromeBooks claim to be effective) Depending on the OS you choose, you would either be reducing or restricting the user's ability to inject their own computer, at the same time you would reduce their flexibility to about the same degree; because the most restrictive OSes are probably not the most popular ones, nor would they be the most targeted.

share|improve this answer
A non-Windows system does not prevent viruses. – Alex Chamberlain Jul 12 '12 at 8:29
That is correct, but in theory, it should be harder to accidentally find a virus, just as it is harder to find a legit program for the less wide-spread OS. For ChromeBooks, in theory, viruses are prevented, with the trade-off of rather strict limitations. – George Bailey Jul 12 '12 at 12:26
@Alex, Do you think this edit is clear enough? Would you like to suggest further improvement? – George Bailey Jul 30 '12 at 14:22

As you probably know, there is no way to be fully protected. However you can reduce the risk. Just look at almost-every bank solutions:

  • don't ask your user to type the whole password. Let's say that the password policy requires passwords longer than N. Then you can ask user to type letters from M<N random positions. If keylogger intercepted typed keystrokes, the attacker still wouldn't have the whole password.
  • every important operation (like removing account, changing password, etc.) should require confirmation. This one could be send via e-mail or via SMS. Even the knowledge of your password wouldn't allow the attacker to have the full access on users' compromised accounts.
  • on-screen keyboard. Mouseloggers could easily log typed clicked actions, however keyloggers cannot manage with that kind of protection.
  • everything stored on your HD could be stolen. Don't forget about it and turn autocomplete OFF for every form, which is used to process user credentials.
  • 2-factor authentication. Give your users opportunity to protect themself in higher than standard level.
  • you could try to detect some kind of malware. For example: DNS Changer.
  • the most important!. You have to decide how users with infected PCs could influence on your bussiness. Banks have to minimalize the risk of any attempt of stealing your cash. You should educate your users how to securely surfing the Internet and use your website.
share|improve this answer
-1 for your first bullet point. While certain banks do this (its common in certain countries) its a bad idea. It requires storing the password in plaintext (or use a encryption that is decrypted at every login; more or less equivalent to plaintext) or storing hashes of all possible permutations (trivial to brute force as sample space is small for each hash) allowing an attacker who compromised the servers hashes to quickly get your full password. Furthermore, its very un-user friendly -- much harder to remember the the first, 4th, 6th, 7th character of my password of the top of my head. – dr jimbob Jul 11 '12 at 18:52
@p___h - Sorry, should have said k-combination vs permutation. Obviously, you would store the hash of the three characters being asked not a random ordering of all the characters in the password. My point stands that this is an idiotic policy that drastically lowers security. – dr jimbob Jul 11 '12 at 21:22
@drjimbob "Furthermore, its very un-user friendly" Indeed, it's awfully user unfriendly. If I was asked to do that, I would: 1) immediately: write the password down 2) as soon as possible: close my account and choose a bank with a standard authentication interface 3) when I have time: write on every forum how bank xxx sucks with security and ease of use at the same time – curiousguy Jul 16 '12 at 4:09
"Honestly, I've no idea why did you treat my answer as "my recommended stuff"." "However you can reduce the risk." You are clearly saying that this method "reduces the risk". – curiousguy Jul 16 '12 at 4:17
@curiousguy - Oh I agree. Its the same flaw that the old LM hash has -- its much much easier to brute force a 4 char password twice then it is to brute force an 8 char pw once. (Say 80 char alphabet; 4-char twice takes 2*80^4 ~ 81 million; 8-character once takes 1.6 billion million which is ~20 million times harder). And then this is even worse with partial information, which you keep getting more of with every observed login (unless you already have enough info to login yourself). – dr jimbob Jul 16 '12 at 5:34

Yes. The most effective thing you can do to protect your users is to use out-of-band confirmation: e.g., over SMS or over phone.

For instance, you could send a SMS to the user with the details of the transaction and ask them to text back "OK". Or you could send a SMS to the user with the details of the transction and a 4-digit one-time code, which they are instructed to enter into your web page if they approve. For users who do not want to provide their cellphone number or do not want to receive texts, you could also provide an opportunity for them to phone in and use an automated voice-response system (you might authenticate them by using ANI, by a callback, or by a 4-digit PIN).

Other methods that involve the user's computer alone probably won't be as effective, since client-side malware (if present) can completely control everything that happens on the user's computer.

Whether this is worth the bother is something you'll have to decide, based upon your own risk analysis.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.