Security x.0

Have you ever gone on a shopping spree … only to find that your credit card has been blocked to prevent such “suspicious” activity? This is fraud detection software in action. Very economical and no need for a spending rehab afterwards, ha? A foolproof, guilt-free solution at no charge...

Fraud detection tools are there just in case fraud prevention methods (PINs for credit cards, passwords on online systems) have failed. Although how one would know that they failed? Hence detection must be used continuously, and as a result must be efficient and evolving all the time (otherwise, the criminals will quickly adapt).

Yet can one really stay at the leading edge of statistical research, given that the free exchange of ideas is virtually impossible? Indeed, it does not make any sense to make the details, results and the datasets for testing readily available in the public domain. However, doesn’t it mean that for academics it is as difficult to obtain the data as it is for criminals?

Plus, as far as efficiency is concerned, surely, the system that identifies 99% of genuine transactions as genuine, and 99% of fraudulent transactions as fraudulent, is highly efficient – what else one could wish for? However, what does this 1% of false “positives” translate into, given such a small percentage of real “negatives”? Tens to hundreds of genuine transactions flagged for investigation in order to identify just one that is indeed fraudulent. Is it really feasible to hope not to “cry wolf” too often?

Then also, what is it that the systems are actually detecting? Which features are they looking at? It is a big secret, of course, but surely it must still be good old behaviour profiles and extrapolations of similar systems. Thus, the task is to flag anything that’s out of the norm. Well, I understand, with food, petrol, electricity, gas, etc. there is a pattern. How about “everything else”, for which “there is a MasterCard” ... if only it wasn't blocked? Since what could possibly be normal in me flying to Australia or buying a piano? Even with jeans, I probably don’t buy one pair a month but rather end up in a shop once in a while and walk out with huge bags full of stuff, most of which I will never use.

This all means that at least once in a while, I, a perfectly legitimate user, performing a perfectly legitimate transaction in a perfectly legitimate place, will be stopped, examined and questioned… and would turn red and helplessly stand there trying to explain that I’m actually doing nothing wrong and have plenty of funds available in my own perfectly legitimate account while watching my business partner paying for lunch “just this time”. Sounds familiar?

So, finally, talking about that psychology of security and the main advantage of fraud detection tools – being back-end and thus seamless to the user... Security is indeed "both a feeling and a reality" (Bruce Schneier); and perception is often more important than reality. The user is often unaware of seamless detection, and when this is followed by an unexpected “security check” or void transaction, not only does it not provide a sense of security, but rather causes inconvenience, embarrassment, anxiety, confusion, and uncertainty. The users need to be sure that they have reliable tools to authenticate themselves anywhere anytime.

Bruce Schneier today made a surprising (at least to me) post on Keystroke Biometrics that refers to a system for online authentication based on keystroke pattern recognition:

This sounds like a good idea...

[describing keystroke pattern recognition solution]

...if they can get it working right, it's an extra layer of authentication for "free."

It is suprising because back in Nov 02, 2005, he posted "Authenticating People by their Typing Pattern" article that generated a good discussion on pros/cons of this method of authentication, and the first comment actually cited the exact company - Biopassword - referred in today's post:

There is a company flogging a product that uses this idea.
http://www.biopassword.com
I know nothing about them except what you can read on the web page. They claim they can do it accurately based on an eight character username and an eight character password. I am also curious about the claim to be able to work for web applications... I don't see how that is possible without a client side agent and I don't see how you could trust the client side agent for an internet facing application.

Posted by: stacy at November 2, 2005 09:08 AM

Indeed, the most important criticism of all biometric-based solutions applied to online authentication is that whilst they are open to Man-in-the-Middle attacks and even simple keyloggers, the real danger is in irrevocability of biometric tokens. Once your biometric token (keystroke pattern, fingerprint etc.) is compromised it would be difficult to imagine that you can easily get a new one

Biometrics is a reasonable choice for physical access authentication (e.g. your car, office, login to your computer) but using it for online authentication (i.e. over a potentially compromised channel and/or from a potentially compromised local access terminal) is both insecure and risky and definitely not "free".

Using real-world ids for securing transactions - simply useless or potentially harmful? In his recent "Identity theft without identification infrastructure" article Markus Kuhn defined "identification circus" as:

the use of weak and trivially to break ad-hoc methods of identification that businesses have come up with in countries or situations where proper purpose-designed identification mechanisms are unavailable (e.g., utility bills in the UK, SSN in the US, handwritten signatures, etc.).

Having recently been to Israel, I have observed two interesting examples of this. One was that when paying by credit card the customer is asked to provide their phone number next to the signature. Another was a request for their passport number to be typed into the payment terminal at the petrol station... in front of me, a driver was happily providing the petrol station attendant, who was helping her to enter all the relevant details in the payment terminal, with her passport number.

In both cases, there is no verification of details provided at the point of sale, and hence it is difficult to see how such measures can prevent any fraud. The only potential use of these details could be to provide evidence against the customer, should a transaction dispute arise.

Imagine a scenario where a criminal has obtained the valid phone number for a particular card and performed a fraudulent transaction. Would the card issuer then take the view that the transaction was genuine since the correct phone number was provided (e.g. similar to transactions verified by PIN in the UK)?

Not only is the use of any private details as weak security credentials designed to shift the liability to consumers and makes no difference to committed fraud, it also facilitates identity theft further: consumers learn by example - it is perfectly fine to provide any private information, no matter who asks for it.

ABN-AMRO has been using disconnected smartcard readers (similar to e.g. Xi-Sign devices) for user authentication for several years, yet recently they were hit with a real-time man-in-the-middle (MiTM) attack as reported by Finextra.

The bank says that its customers opened an email attachment that resulted in a virus being executed on their machines. This virus changed their browsers' behaviour so when they went to open the real ABN Amro online banking site, they were instead re-directed to a spoof site.

The customers then typed in their passwords, which the attacker in turn used to access the bank's real Web site. The customers' own transactions were passed along to the real site, so they didn't notice anything wrong right away, while the attacker simultaneously made their own fraudulent transactions using the bank's urgent payment feature.

Although there have been previous reports of successful MiTM attacks: (Citibank, Amazon, PayPal), no real-time fraudulent transactions have been reported, instead attackers just used the real-time authentication to convince the user that the web site was genuine and then request personal and financial details as in usual phishing. Until this incident, it was possible to speculate that perhaps this type of attack is still too expensive for the phishers to execute, therefore the risk is insignificant. Not any more.

The interesting data point is that in the attack against ABN-AMRO, only 4 customers were affected (according to another comment: "only 200 people who reacted to the email and only 10 victims (10K euro or more)". Unfortunately, this demonstrates that no matter how few customers fall victim to a particular scam, the return on investment is high enough to make MiTM a real attack vector today. It might still take some time to become as common as "normal" phishing due to required "de-specialisation" of phishing groups, as we have suggested, but it has to be addressed today.

Financial Cryptography also commented:

This was what the European banks were worried about when we reported MITB earlier in 2006. One year later there has been no epidemic, and that gave them time to respond. Hopefully they are ready. Chances are, nobody else has or is. To live in interesting times...

[Not sure why European banks are singled out, given the amount of phishing happening in the US]

The main problem with multifactor authentication is that it is what it is - a user session authentication mechanism establishing a secure connection between a trusted host and a user. Whereas what is really needed to mitigate a MiTM attack is transaction verification. If one can protect all important actions performed by the user with a reliable way of signing off on the transaction, the security risk will be minimised - in the worst case, the attacker will have an equivalent of "read-only" access to data. What does it mean practically? Once transaction verification is in place, a user can stop worrying about whether or not their host computer is compromised, even if the attacker has access to their bank account, no funds could be transferred without secure authorisation by the account holder.

There are multiple ways of implementing transaction verification. Some are simple but not reliable, e.g. text messages with transaction details sent to the user's mobile phone (problems with delivery delays/availability and recurring costs). Some are very secure but complex to deploy, e.g. PKI-based solutions. Some are hardly user-friendly, e.g. CAP readers (is having I,M or S as menu options really intuitive?). Although it is not clear which method will become most accepted, it is certain that the current push for 2-factor authentication is not a longer term solution.

As Barclays is preparing to roll out disconnected readers to their 1.6m customers, perhaps they should at least look at how exactly the same approach was compromised in the ABN-AMRO case. Chances are they will. Would it change their plans? I doubt it. For better or worse, yet another massive user trial of a 2FA solution is about to begin, so we shall see...

As many security experts point out, two-factor authentication is not going to prevent financial fraud and identity theft, e.g. see Schneier. Let me play devil's advocate for a moment. For all its failures, could implementation of 2FA disrupt currently established online criminal practices? I think so.

Most recently, Gunnar Peterson raises the question:

You can have 20 factor authentication, but if your host security is already compromised, what have you solved?

It is a valid point given that every day more sophisticated ways are devised enabling attackers to solicit user data via legitimate looking web sites. Real-time Man-in-The-Middle (MiTM) attacks are here, e.g. Citibank attack, and with all Web 2.0 technologies so are Man-in-The-Browser (MiTB), e.g. FormSpy Firefox trojan extension.

Having said that, I do believe that 2FA can disrupt fraudulent activities at least initially. For example, consider Paypal's token rollout. Whilst prone to MiTM attacks, it minimises the possibility of someone being able to capture user's static credentials and use them to commit fraud later. This has an interesting effect on online fraudsters and how they operate.

It is believed that different groups are highly specialised, i.e. a group executing the actual "phish" - collecting user's details - does not use those details to steal funds from the accounts, instead they wholesale it to other groups who have well-organised routes to extract stolen funds. This system is currently very efficient for phishers - they lose out on the real upside by just selling off the account details but make up for it by significantly reducing the risk of getting caught and by being able to harvest data in high volume. If this was no longer possible, i.e. dynamic secure credentials were used, the only way to steal from the user would be during the real-time session. This means that phishers will either have to expand their operations and actually perform the fraudulent transfers, or limit themselves to producing "phish-it-yourself" kits for others. Given their ingenuity one can even imagine a "phish-on-demand" web service at some point :)

Implementing 2FA is a step forward, providing the organisation recognises that it is not going to protect against all attacks and does not try to shift liability on to their customers just because they have given them OTP tokens. In the longer term, the best way to protect against ever-evolving online fraud is to offer simple strong security that combines multifactor mutual authentication with transaction verification. Nothing is 100% secure, but this could be a Molotov cocktail to derail the fraudsters.