« Johan Peeters on Dreams and Nightmares | Main | Practical SOA - Service Firewall pattern »


Bob McCormick

Fascinating story. The banks attempt to get around the issue of compromised end user hosts was quite clever, but in the end the criminals were more clever by far.

However, I fail to see what your rather unprompted broadside against REST and AJAX has to do with the story. Since the root of the problem was malware on the users PC, I should think that a WS-Security protected transaction would have been just as vulnerable.


There is no question that you can easily write insecure apps in WS-*, SAML, whatever. The point I am trying to highlight is that at least these technologies bring new security mechanisms to bear on the security arms race we are in. The REST and Ajax story is - we have SSL and network firewalls, what else do we need?

In my opinion you have to sadly assume a malicious environment. Kim Cameron has a good post today on this as well


Bob McCormick

They do bring new security mechanisms, but IMHO those mechanisms wouldn't address the issue you've chosen to highlight. :-)

Also, while WS-Security introduces new security mechanisms, it also introduces significant complexity. That complexity can't be ignored, particularly because it has security ramifications of it's own.

For example, I'm quite concerned about the rather large attack surface of a WS-Security secured message.

Interoperability is also a big concern because of the breadth and lack of specificity of the WS-Security spec.

But back to the bank attack in question... It's really a fascinating case that IMHO has close parallels to the difficulties the content industry (RIAA, etc) has had with DRM technology. Both come down to the fundamental question of controlling application behavior (and securing data) on a potentially hostile platform that you don't control.


The problem is that the 2 factor authN goes into a single communication band. The example I linked to using SMS separates communication bands. For one thing, you need to have support multiple security token types to do this. WS-Security and WS-Trust are designed to support Kerberos, SAML, X.509, Username/password hash, and other token types, as well as other namespaces. This is a major difference, and can be used to build a system that is resilient to some of the threats above. For example a transaction can have multiple token from multiple namespaces, aggregated across multiple hosts, and context (bands).

Now to the complexity issue, for sure this is a real concern, and needs to be worked, but this is a lot different than saying "let's just keep using SSL and network firewalls like it is 1995" style security architecture.

Igor Drokov

As the automatic trackback failed "Response: [Failed] As a measure to prevent automated commenting, please verify yourself via this captcha check."

Here is a manual one :)

"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."


Andrew van der Stock

Hi Igor,

The SMS is a form of transaction signing. Weak transaction signing for sure, but it's better than 2FA authC, as the MITM scenario proposes.

The attacker has to

a) conduct a DNS or other infrastructure level attack (such as install a Banking trojan) against the victim

b) take over the active session, either by navigating the user to a perfect copy of the site (hard) or just interceding with some added Ajax background music, such as a forceful CSRF to which the user is unaware

c) Convince the user that they must give up a sound credential. With a 2FA fob with no transaction signing, this is easy and many will fall victim. This is why 2FA fob only does not work and is a waste of money. If the user sees a message on their phone for no reason, saying:

"The token code to transfer $2900 to account "blah" is 437485. If you did not make this transaction, do not enter the code and call 1800 EXAMPLE immediately. This token expires in 30 seconds."

A user will hesitate to enter that unless they're already in the process of entering a transfer. If it's the wrong value, and the wrong destination, they will not enter it.

SMS 2FA is extremely cheap, and extremely effective. For customers without a mobile phone, transaction signing calculators from Vasco et al cost $20 on up to a couple of hundred for the EMV capable fancy ones. I like the intermediate EMV calculators - they force the user to put their corporate credit card into the device thus ensuring they have a mental picture as to the value of leaving the token around. All too often, I find tokens in desk drawers and such. Making the user aware of the exact value by hooking a real monetary instrument to a disconnected calculator is so close to three factor authentication: something you know, something you have, and something you are, as to not count. I doubt the attackers will work out a suitable attack path for these devices unless *we* make mistakes.

And sure enough, we will make mistakes. But the cost will be a lot less than it is today. The day of the password ended a long time ago. It's time to move on to a world where devices are *always* assumed to be trojaned, and the network is *always* assumed to be tainted (DNS pinning attacks, etc), and so on. SSL no longer cuts the mustard alone.


Jeff Zhuk

Gunnar is absolutely right in the main thing: there is no absolute security cover but each security layer adds more security.

No questions, we pay high price for security in performance and complexity, but we might pay much more for its absense.


I am very glad to see you online:-)

Jeff Zhuk

Igor Drokov


Thank you for your comment.

Whilst I am not convinced that SMS-based or CAP/EMV calculators are the best solution, I couldn't agree more with the statement that transaction signing is required to protect against Man-in-the-Middle attacks.

In fact, my last post on the subject was exactly about it:
"Transaction verification can protect agains MiTM"

The comments to this entry are closed.