Slashdot Mirror
Defeating Virtual Keyboards and Phishing Banks
An anonymous reader writes "Noam Rathaus writes on the SecuriTeam Blogs how most Image Click-Me virtual keyboards schemes used by banks to fight phishing trojan horses can be easily broken, even (and especially) when encryption is used. He then discusses how screenshots of the pointer location are over-kill, and describes how to kick these security measures out of the way." From the article: "Instead of sending the remote image and waiting for the key-stroke information to be sent back to the server (the technique which the screenshots for pointer location on-click described above was used) some banks send the PIN number in cleartext, while others encrypt them, one such example is cajamurcia. Even when the encryption is used, banks tend to implement it badly making it easy to recover the PIN number from the encrypted form. I investigated a bit more on how cajamurcia handles such PIN strokes (with virtual keyboards) and I noticed something strange, they take the timestamp of their server (cajamurcia) and send it to you - this already posses a security problem - and this timestamp is then used to encrypt the PIN number you entered"
This is no surprise at all. Keyloggers will be a thing of the past soon enough for the major hackers.
More scary is the fact that adding a simple network device will allow a virus to log all Internet traffic. Look at HTTPLook (a small app used to sniff HTTP traffic). It comes with a small HTTPS module that intercepts HTTP traffic transmitted via HTTPS.
Using such a device will also help cut down on the amount of data hackers can get -- HTTP traffic is useless to them. Why do they care you went to Google and searched for "hot gay wrestlers"? They don't. HTTPS, on the other hand, will set off alarm bells -- if a server is worried enough about security that it pays for certificates, the data must be worth something, right?
The solution is that logging into secure systems needs to require a physical presence. An older system I maintained a few years ago for the Mortgage industry used a username, password, and a key from a small business card in their wallet. Each month users received a new card, and each card had about 50 numbers on it. The system knew which numbers each user had and only allowed each number to be used once. Logging in with a wrong number would flag your account, repeated attempts would lock it. Yes, it increased support load when someone lost their card (the cards were unmarked so if someone found it, the numbers are useless), but it was fairly secure and generally a lower cost alternative to biometrics (and much more portable).
This combines the "something you know" authentication scheme (username, password) and the "something you have" scheme (password card). The third type is "something you are" -- biometrics.
(Failure point: person gets kidnapped. If a user gets kidnapped, security is the least of the worries until they are recovered. Failure point: if the database with the numbers is compromised, the system is no longer secure. If the database is compromised, they no longer need to log in, and no secret numbers will stop them.)
Actually, that's not added security, but essential security. If the PIN was entered on the computer, and then sent to the smartcard for encryption, then a Trojan could still get it on that first leg of communication, before it was encrypted.
The way these things usually work, the PIN entered at the keyboard is not the PIN for the bank, but the PIN to decrypt the certificate on the smartcard. So knowing the PIN is only useful to the identity theives if it can get physical access to your smartcard.
The way these things usually work, the PIN entered at the keyboard is not the PIN for the bank, but the PIN to decrypt the certificate on the smartcard. So knowing the PIN is only useful to the identity theives if it can get physical access to your smartcard.
Correct. However, once the Trojan Program has the Pin, it will be able to reuse that to submit fake transactions if the user is careless enough to leave the card in the reader...
I've had such a device, when I had an account in the Swedish bank Swedbank. Works pretty well, but much less convenient than the certificate-based solution I use now in Skandiabanken.
erm, how would this protect against realtime phishing?
e.g.
user enters username/pass/magic number to log in at fake bank website
fake bank website then uses that info to log in at real bank site and transfer $largesum to $evilguy
if your token only changes its code every 30 seconds that shouldnt be hard at all
btw, the same scam made a bit more elaborate would also work against one-time-use number pads (present user with fake 'enter transfer details and one-time-use number, use that number to do a different transfer, respond with error/success/whatever message)
the only way I see to make a secure system is to have a secure endpoint = hardware device that treats the client computer as just another hop in the unsafe internet cloud
If you use a smartcard, the crypto happens on the card itself. The private key never leaves the card. Simply speaking, a request is made to the card to sign something, and it gives back the signature. This means that no one listening on the computer can duplicate the authentication (assuming there is nothing else wrong with the protocol, such as replay attacks, any sort of man in the middle, etc).
In essence, the smartcard idea is assuming that your machine could be compromised, and is moving the authentication to another machine (the smartcard) which is much harder to compromise.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
Doesn't matter. You wouldn't rely on the cell networks for any of the security, you'd just use the network as a transport. The Internet is also completely insecure, but we easily create secure communications channels over it. The security of the network is irrelevant. It's the security of the endpoints that matter.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Yes it does, provided that the system is correctly designed and implemented. In fact it is nearly bulletproof against a MIM.
The MIM will need to have both a valid server certificate to authenticate to the client a valid client certificate to authenticate to the server. If the server correlates certificates with another credentials like a username and password (2+ factor authentication) it can immediately detect that a stolen identity is being used with the wrong smartcard.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/