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?
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.
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.
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.
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 www.bank.com 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.
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:
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.autocomplete OFF for every form, which is used to process user credentials.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.
