A pressing concern for many of my financial clients at the moment relates to how they should be responding to phishing attacks.
Phishing attacks exploit weaknesses in the standard email protocols. These allow attackers to impersonate a financial organization, using the same techniques as spammers and, in many cases, even using the same shared lists of email addresses. The aim is to persuade the recipient to supply confidential information to the attacker through a corrupted or fake instance of the website.
As with any electronic threat, there are multiple vectors for possible attack. While phishing attacks rely heavily upon the social engineering aspects of forged emails to be statistically successful, there are still a number of things that I can advise my clients to do to protect themselves.
This advice extends beyond relying on third-parties to correct the standards, educate their technology-challenged clientele, or even police against each new phishing scam. Instead, they should spend some time focusing on the things which they themselves can do to their applications and systems.
In the first instance, they need to ensure they have deployed the standard assortment of security mechanisms that are designed to protect their customers from attacks based around information leakage and threats associated with the use of non-secure or shared computers (such as those found in cybercafés) – and actually have them verified as implemented correctly. This includes multi-tier login processes that are capable of thwarting automated attacks and common key-logging attack methods, as well as investing in robust input validation processes.
These standard protection mechanisms represent the front-line in application security. Unfortunately, many organizations fail to implement these standard security features successfully.
Consider the benefits of a well thought-out and implemented two-tier login process. In the first instance, the client is prompted for at least two personal pieces of information (such as their surname and their account number). In order to combat automated brute-force agents, after successfully supplying this data, the client is then asked to supply at least two further pieces of information (a supplied password and a shared secret word, for example) on another page.
For combating key-logging devices, at least one of these personal identifiers should be supplied via the mouse – such as using drop-down boxes to select the letters that comprise their shared secret. To combat network sniffing attacks, only parts of the shared secret should be required (such as the second, fourth and ninth letters of the secret word) – and these sequences should be randomly selected each time.
However, to help defend against common phishing attacks that fake the organization's web front-end and mimic functionality to capture this personal information, you need another security mechanism.
The simplest procedure is to get the client to upload a picture that is unique (or choose one that means something to them) when they first create their internet login account. The client is then informed that the picture has become a shared secret, and that this graphic will always be presented to them when they reach the second level of their login process (as a watermark, for example). Therefore, the absence of their picture means that the web application is being impersonated. I recommend the use of a graphic as opposed to a pass phrase, because this prevents confusion with passwords and "personalises" the experience for the client.
Failures with web application URLs that allow scriptable components, or third-party web address information to be incorporated in them, often confuse the organization's clientele and represent an easily exploitable attack vector for the phisher. For example, consider a web application that has a component that redirects its clients to an affiliate site which can be abused in this way: www.trustedbank.com/affiliate.html?url=https://fake.attacker.com. Of course, the "fake.attacker.com" could be hidden using all kinds of methods. Proper – that is, robust and intelligent – input validation processes are required.
There is no shortcut to this process. Many companies know that certain fields in their web application do not validate content at the server properly, and fail to see how this could be turned into an attack. Normally, all that is required is a quick demonstration that injects a little client-side code into the returned page, which logs all the key depressions and redraws the insecure padlock of the browser to look as if it is now "secure".
