I have discussed real-time keyloggers before, as a way to defeat some online banking applications, among other things, and that in general, one-time-password generator tokens offer complexity, but typically they do not add any real security.
Now, stealing one-time-passwords from RSA SecurID has made the NY Times as well. (Slashdot thread here.)
Authentication takes the back seat to malware. If you cannot guarantee a malware free end-point (and who can?), then you cannot guarantee an authenticated person on the other side of that end-point device.
3 comments:
If you cannot guarantee a malware free end-point (and who can?) ...
That's easy. Make the endpoint as small and simple as possible, and separate it from the PC. For instance one can use a cryptographic token, require the user to enter essential parameters of a transaction into this token, and use the resulting output to authorize the transaction. Or a smartcard along with a reader that displays what the card is going to sign and has a separate keypad for entering a PIN. Or use the user's mobile phone as an endpoint, which may at least run someone else's malware.
I've seen all three approaches implemented by banks over here in Germany. They may not solve the problem forever but they seem a little more to the point than stronger authentication. Proper analysis of the problem is the key: it never was about authenticating users but rather about authorizing transactions.
Hi, Sven.
It's actually harder than your suggestion. Making the system "smaller" definitely helps, because there's less functionality to worry about. But, even a cryptographic token or anything else could be used in real time keyloggers. Think about it: if it executes on your endpoint, and malware can execute its own code with system permissions, it can monitor anything that happens on that device. If a user has to key in output from a physically separate token, the keyloggers can grab them in real time to do what it wants (or worse-- it can just proxy any transactions it wants into your authenticated session). If it's something that has to execute in your endpoint's CPU, then it can also be monitored/tampered to get the results they want.
The point is ... we're seeing more sophisticated malware. If it's something you can do, a program can do it, too (or can just tag along and steal/manipulate your session).
The keylogger can grab the input but do with it only what uncompromised components of the overall system allow it to do. If the code is tied -- cryptographically or through the sequence of messages over different channels -- to the contents of the particular transaction to be authorized, this might be very little. Keyloggers are a problem because what they log can be recombined with other data in an exploitable way. This is no longer the case if we produce, outside of the endpoint PC and independent of it, an authorization code for a particular transaction, or for a set of transactions within which manipulation is of no use to the attacker.
A cryptographic token can achieve this if the user is required to enter e.g. the target account number and amount for any transaction, essentially creating kind of a MAC for these data. The key logger can still steal the code, but the code can no longer be used for an arbitrary transaction. The mobile phone solution achieves the same effect by creating an authorization code on the server side only after all details of an order -- manipulated or not -- were received. Then it uses a different channel to inform the user about the actual transaction that will be executed, and provides the user with the authorization code for this transaction. If this transaction is fraudulent, the user is supposed to just do nothing, so there will be nothing to log. If it is not, the keylogger cannot change the transaction when it receives the authorization code, it is too late.
User compliance issues and therefore phishing risks may remain; I don't claim that any of these approaches is perfect. But keyloggers are not the end of online banking.
Post a Comment