Slashdot Log In
Defeating Virtual Keyboards and Phishing Banks
Posted by
Zonk
on Mon Nov 27, 2006 01:46 AM
from the sounds-like-a-full-night dept.
from the sounds-like-a-full-night dept.
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 discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
dumb (Score:5, Insightful)
Re:dumb (Score:4, Insightful)
Client side x509 certificates (if possible on smartcards or tokens) will solve 99% of phising problems once and for all. For most "secure" sites, the clients authenticate the server (which can often be circumvented by using DNS tricks). At the same time there is no SSL level client authentication. As a result stolen credentials can be reused on another system. A smartcard holding the x509 cert prevents this outright.
Unfortunately instead of using what is right there in front of them in the actual protocol spec the banks go into all kinds of technological roccocco. Not surprising actually. I tried to explain the concept of client side certificate to one of my collegues who had in the past implemented the internet banking system (and its security) for one well known UK bank and is now to implement another one. No matter how hard I tried, he could not grasp the concept.
Parent
Re:dumb (Score:5, Insightful)
I've been in the business of designing, implementing and selling smart card-based security solutions for nearly a decade now, and I've talked to lots of banks about these issues. Most of them understand perfectly well that smart cards with client-side digital certificates are an excellent (though not perfect, see below) solution from a security standpoint. The reasons they aren't gung ho about deploying such a solution are (1) cost and (2) consumer acceptance.
Smart cards themselves aren't expensive, and neither are smart card readers. The cost of retooling the card issuance process to support smart cards, however, is non-trivial, and the cost of deploying card readers to consumers and supporting them through the installation and usage process is very large. The biggest problem, though, is cardholder training. How do you teach millions of people how to use the thing, even if it's already set up on their machine? Simple problems like how to insert the card into the reader are surprisingly hard to address on a large scale.
The UK, and a few other countries, are much more prepared for this than the US thanks to the Chip & PIN initiative that their banks have spent tens of millions on. At least UK citizens know to put the card in chip-end first, with the chip up.
In any case, though, it's the cost and difficulty of getting consumers to deploy additional hardware on their computers that holds banks back from doing it, not lack of understanding. All of their weird security solutions are attempts to perform semi-secure transactions on the PC hardware that the cardholders already have, with no new software or hardware to install or maintain. Note that the costs and difficulties I'm talking about aren't theoretical. Various banks in different parts of the world have run pilots using these technologies, and they've invariably fallen flat. IMO that's because the pilots were poorly run, but having seen the failures, banks are very leery of trying anything else.
The new buzzword that's sweeping the financial industry these days is Near-Field Communications (NFC). NFC is basically a contactless smart card chip embedded in your cellphone. The chip can securely store and use keys, and the interface with the phone provides it with a display, keypad and Internet connection so the chip can phone home to the issuing bank as needed (for velocity checking, balance checking, etc.). Assuming the phone can be protected from viruses, trojans, etc., and can be considered a relatively secure device, this has all sorts of advantages. It can be used in a retail environment with a contactless smart card reader, using the phone's display and keypad to give the user a chance to verify the transaction details (the amount, mainly) on a device the user trusts. For on-line usage, you can connect the phone to the PC via USB, or via a contactless smart card reader for secure and easy transaction, but it's more likely that you'd use the phone's data link for the financial transaction. Imagine going to amazon, picking out your goods, hitting the "buy now" button and then waiting a few seconds for a message to arrive to your phone, requesting payment authorization. You'd review the transaction details on your phone screen, authorize payment with the keypad, and the smart card chip would then create a cryptographically-secure payment authorization message and deliver it to either the bank or the merchant (depending on how the system was structured).
What's actually going to happen? After failing repeatedly over the years in my prognostications, I won't even guess. I will say, though, that banks are big fans of "good enough", and that their definition of "good enough" doesn't require that fraud be impossible, only that it be sufficiently limited that it's affordable.
Parent
Re:dumb (Score:5, Informative)
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.
Parent
Re: (Score:3, Interesting)
for added security have a pin pad on the smart card itself.
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.
For real security, not only would the PIN need to be entered on the card itself, but essential transaction data (amount, target account) would need to be displayed by the card as well (using a pocket-calculator like LCD display, for instance). Indeed, without such displa
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Doesn't mean they always will be.
Re: (Score:3, Informative)
But basically you are correct, if the cell is encoding everything correctly the connection could be trusted, the only problem is that cell networks are known for hiding behind obscurity for security, witch is not very safe after all.
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.
Secure banking? Yeah right. (Score:3, Interesting)
Although, on the plus side it has made me extra paranoid about all online transactions. So now any site where I am involved in a finacial transaction has different passwords and anything that gets cached is cleared out of my system as soon as I am done.
Meanwhile, back in the old west... (Score:3, Funny)
Yeah, and? (Score:3, Insightful)
No Surprise (Score:4, Informative)
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.)
Cut them off at the pass (Score:3, Funny)
Is it just me? Am I missing something? (Score:5, Insightful)
The ONLY way to outsmart software that wants your data is to not load that software on your machine. I find that I feel much safer booting a life CD (DSL or Puppy or pick your flavor) and running to the banking website with a freshly installed OS... no chances for virii or malware etc.
That is certainly easier than actually going to the bank... and I know that its safe.
It at least makes me feel a bit safer.
Re: (Score:3, Interesting)
My Phone is a Weapon (Score:4, Interesting)
With that protocol, I'd feel safe even using those random ATMs at delis and various "impulse purchases", where today they get my PIN and can launch a replay attack any time they want.
Never develop your own crypto protocols (Score:4, Interesting)
That business with the timestamp? Offhand I'd say the bank was trying to do the right thing by preventing replay attacks. But using a timestamp? I'm having trouble keeping up with just the obvious attacks against that, let alone the attacks that a seasoned crypto developer would find.
If you ever need to do what the bank tried to do, find something already written and battle tested, make sure its assumptions and security properties line up with what you need(*), and use that instead of repeating the last fifty years of protocol design mistakes.
(*) Then you'll find that they assume trusted endpoints, which is something worth reflecting on.
Keyring Dongle (Score:5, Interesting)
When you log in or do any transaction, you are required to enter this number (along with any other credentials which are appropriate). The bank records the serial number of the dongle they gave you, and I would assume that there is some secret mathematical algorithm that allows them, knowing the serial number and the time, to calculate what number your device will display.
If you make 3 mistakes in a row with the 6 digit code, your internet banking account is automatically locked down, and you have to contact them to unlock it.
Now, that's a very simple trick and I can't see how a hacker / phisher would get around it. Sure they can sniff the code when I log in, but 30 seconds later it will be useless. Short of mugging me for the device on my keys (after having phished my regular login/password), they can't get in to my account. Even if I leave a session logged in and walk away, and someone else sits down at the terminal, they can look at my balance and transaction history, but can't make any transactions.
Having used the device for a year I have to say it is remarkably convenient, and it seems immune to most of the attacks described here, and doesn't have the convenience drawbacks of one-time PIN cards. Why is HSBC still the only bank doing this?
More info on the device: http://om.hsbc.com.au/osd/ [hsbc.com.au]
Have a split PIN system (Score:5, Insightful)
Solutions to stop phishing & trojans etc (Score:3, Interesting)
Basicly, each customer is given a device that looks a bit like a small calculator, make it "solar" powered (in reality those panels will work just fine powered by any sufficiantly bright light source) so it never looses juce.
It would have a 0-9 keypad and other buttons. Each device would contain a unique number that is also securely stored on the banks computers.
When you want to log in, the bank generates a random number and displays it along with a form field for username/user ID/whatever, a form field for password and one for a hash. The user types in the random number into their calculator thing which is then hashed with the number stored inside it and the result displayed. The hash algorithim has to be chosen such that there is no one number that when hashed with any unknown stored number can produce either the stored number or something that you can get back the stored number from. (this prevents the hacker from feeding a chosen "random" number to the user and getting the stored number that way).
Once you do that, the displayed hash along with username and password are typed into the form. The hash is compared with the same calculation done by the banks computer and if the username, password and hash match up, you are logged in.
When you want to do a transfer to someone not on your "approved payees" list or add someone to the "approved payees" list, you have to enter the account number and/or dollar amount and/or another random number into the calculator thing which spits out another hash that has to be typed in. This prevents the phisher
Unlike some other proposals (USB smart cards, mobile phones), it is 100% OS and browser independant and requires no drivers.
Banks and third-party Javascript (Score:3, Interesting)
I only noticed this because my "NoScript" Firefox extension started showing the "Script partially allowed" message.
Now, I'm no expert, but I do know that Javascript has a bit of a spotty history when it comes to security. Having looked into liverperson.net it appears to be legit ; but in any case, I did not allow it access.
But my question is this : why on earth do BofA think it makes sense to link off-site during the login process ? Surely this is completely nuts ?
Re: (Score:3, Interesting)
Re:What if you obscure the pattern? (Score:4, Interesting)
http://griddatasecurity.com/Approach.htm [griddatasecurity.com]
(Of course, this isn't much use against the hypothetical of a carefully-engineered realtime man-in-the-middle attack, but I suspect very little would be.)
Parent
Re:Virtual Keyboards are pointless (Score:5, Insightful)
Parent