Every so often I set an exam question to which I actually want to know the answer. A few years back, when the National Lottery franchise was up for tender, I asked students how to cheat at the lottery; the answers were both entertaining and instructive. Having a lot of bright youngsters think about a problem under stress for half an hour gives you rapid, massively-parallel requirements engineering.
This year I asked about phishing: here’s the question. When I set it in February, an important question for the banks was whether to combat phishing with two-factor authentication (give customers a handheld password calculator, as Coutts does) or two-channel authentication (send them an SMS when they make a sensitive transaction, saying for example “if you really meant to send $4000 to Latvia, please enter the code 4715 in your browser now”).
At least two large UK banks are planning to go two-factor – despite eight-figure costs, the ease of real-time man-in-the-middle attacks, and other problems described here and here. Some banks have thought of two-channel but took fright at the prospect that customers might find it hard to use and deluge their call centres. So I set phishing as an exam question, inviting candidates to select two protection mechanisms from a list of four.
The overwhelming majority of the 34 students who answered the question chose two-channel as one of their mechanisms. I’ve recently become convinced this is the right answer, because of feedback from early adopter banks overseas who have experienced no significant usability problems. It was interesting to have this insight confirmed by the “wisdom of crowds”; I’d only got the feedback in the last month or so, and had not told the students.
Ross
PS: there’s always some obiter dictum that gives an insight into youth psychology. Here it was the candidate who said the bank should use SSL client certificates plus SMS notification, as that gives you three-factor authentication: something you know (your password), something you have (your SSL cert) and something you are (your phone). So now we know 🙂
Not processing a transfer for a day and sending a SMS with details of the transfer and a request to ring the bank (using phone number of back of debit card) may catch most phishing. It will not lock me out of banking if my mobile phone is broken.
If you can detect phishing quickly enough most of the time, it may be a lot cheaper then trying to stop phishing and just as effective. E.g. you have a list of the account numbers that the attack is trying to move the money to and can then match on that list.
It’s a pity that ALL ATMs can not ask the user a question that bank has set, and then forward the answer to the bank. Then the ATM network (+ chip and pin card) could be used as the two-factor AND two-channel authentication.
(Of course only first time transfers to accounts the bank does not trust need to be included)
Don’t forget that faking the sender of an SMS message is easy, so if enough banks start using this the bad guys may simply send enough fake messages to discredit the system or overload the bank’s call centre at a crucial moment.
With so many companies switching to IP-based telephony, the independence of telephony as a 2nd channel is also under threat.
Number of problems in the real world with this.
-people change phone number (they do, really). Which means the bank has to be notified.
-Ian’s idea of tracking the target accounts doesn’t work – phishers use middlemen who think they’re working for international traders. (Commonly recruited via spam.)
-phishers could and already do send spam saying “Thanks for authorising your bank transfer to Latvia. If you do not wish to proceed, click here..” And people, panicked, do – straight to a phishing site.
Really it needs two-factor authentication for everything. Which you get to a large extent on the phone (you call the bank, have to enter parts of a PIN code) or when you *go* to a bank. Not perfect, but not bad. Of course those rely on humans, who are pricier than machines.
I expect you also wanted the students to mention
– Train your customers to never access the bank’s web site by clicking a link in an email, always from a bookmark.
– Don’t bamboozle your customers by using more than one top level domain name for your web sites.
And if the bank is serious about security it could also
– Send all emails to customers as plain text. This would set a good security example for the customers. It would also train them to view as suspicious the fancy formats which can obscure the top level domain name of a link in the email. (Not that any clever bank would send customers clickable links, but phishers might.)
There is a very real problem with “two channel” systems when the second channel is SMS or it’s equivalent which are designed to be unreliable in delivery.
SMS is as far as the TelCos are concerned a secondary service, they do not in any way give asurances as to delivery or it’s timleness (only that they will charge you 😉
So by this alone you will see that a solution using SMS is at best going to be unreliable (but should fail “safe”)…
Worse a user or attacker can make SMS fail by alowing the phone memory to fill up (or an attacker DoS it by sending lots of messages) etc, and this might well open up abuse of the system due to implementation weaknesses…
I have thought about this problem off and on since 2000 when I gave a presentation on using two channel systems for financial and other high value transactions across the Internet.
The crux of the matter for the user boils down to,
Time / complexity / trust.
Additionaly for the owning organisation is,
cost / risk
For the user any solution has to be timely in nature or otherwise users will not use it (problem with SMS) or worse abuse it. This time dimension also includes reliability as they do not want to go back a couple of hours later to check the transaction has occured. Or if unaware of the fail safe issue get a 100GBP fine because the bank did not send the money of to the local council etc (downside of fail safe).
The system has to be moderatly simple to use (still a problem with some bank web sites even without dongles etc).
And unfortunatly for the user they have to (blindly) trust it, untill they find out otherwise (sometimes to their cost).
From the organisations point of view it usually comes down to the cost of the system v the cost of their reputation, an equation that you will note very very rarely deals with the customer and their risk (which banks just externalise any way either by contract or by other less reputable manner).
A second channel like SMS is an open system with no method of authentication which means that with a little thought you will realise that you will be able to extend a Man In The Middle attack to the second channel under some circumstances (so it is unreliable at best for this asspect as well).
Also the computer the user uses cannot be trusted by either the user or the organisation to display what either of them think is being displayed. So transaction detail authentuication is a must and has to be done independently of the PC (so yes you need a dongle that can be trusted not a mobile phone).
My thoughts have now turned to other methods of achiving an increased level of security without using SMS or it’s equivalent.
First off the banks could do a lot to stop MITM attacks simply by using “human only” readable feed back to the user which goes a long way to limit or stop automated atacks (ie the attacking person has to be present in the authentication chain for an MITM attack). If done correctly this will make the chance of success to expensive for the attacker.
Secondly if the user actually entered the transaction details into the dongle and then typed the dongle output into the browser this extends the transaction loop into a (possibly) trusted device which the attacker cannot access.
A simple way to achive this for most people and still have a cheap device for the banks etc is that the user has to set up parts of the transaction in advance (ie the destination account details etc).
The bank displays a selection menu of destination accounts to the user which has a menu entry number and (say) a three digit checksum on each entry. The user types the number and checksum into the dongle and getts presented with a (for arguments sake) four digit number that they then type back into the browser.
Providing the hashing method the dongle uses is (near) unique to the dongle and time, and providing the checksum the bank used is in “human only” readable format an automated attack will stop at this point.
The user gets sent back a new transaction number and a checksum. They type in the number into the dongle, which then shows up a second checksum that must match the one on the screen.
From this “brief” discription you can work out the rest of the details towards a full system.
Ross marks out of 10 ?
As previsously discussed, transaction verification is required to protect against real-time man-in-the-middle attacks.
http://blog.cronto.com/index.php?title=transaction_verification_can_protect_aga
As only 1 of suggested 4 methods in the exam question provided transaction verification it is not surprising it attracted most votes of confidence.
This, however, should not be treated as the best option overall. Out-of-band is attractive, but has its limitations, otherwise, the simplest way to mitigate against phishing would’ve been to e.g. send payment instructions by fax or use telephone banking for transfers (leaving online access effectively read-only).
SMS is not the right, in my opinion, channel to use for secure transactions. It has not been designed for that! There is no guaranteed Quality of Service, hence the message can be lost/delivered late, the network coverage is also an issue (e.g. there is no reception for half of the UK mobile networks in the Gates building!).
SMS also doesn’t deliver mutual authentication. The customer will still have no clue if the message is from the genuine bank. It is very easy to send an sms to appear with a custom Sender’s ID, e.g. “Barclays Bank”, so how many times the user will call their bank up after a fake alert before giving up and ignoring the messages? This could also be exploited for “vishing” – send a false alarm, get the user to call the number, specified in it, which is then setup as an automated system to collect user’s secure credentials.
So, comparing CAP readers deployment and the SMS option, at least CAP readers could potentially be used for transaction signing (though no UK banks seems to be planning on using it so far), hence in theory they could mitigate against man-in-the-middle and therefore a better long-term option. The problem with CAP readers is that the user experience of trying to verify a transaction will leave a lot to be desired: the user will have to type at least 24 digits to confirm a transaction:
– 4 digits – customer’s PIN
– 8 digits – recipient’s account number
– e.g. 4 digits – the amount
– 8 digits authorisation code
Now, how many users find it easy to type e.g. a Windows License key (and it’s only 16 characters)? What if you had to do it every time you start your computer? 🙂
Clive,
What about this as an alternative:
– take a picture of the computer screen => sign the transaction?
More details: http://www.cronto.com/technology.htm
Any feedback is welcome.
Igor,
The basic idea is the same which is good for both them and me (ie a bit of a sanity check 8)
From a very quick look at the website the hardware looks like it might be a bit expensive for banks to issue to all account holders.
That asside it still does not remove the possibility of an automated attack that hopefully “human only” readable numbers on the checksums etc would prevent.
I need to look more at their system and give it some thinking time.
Clive,
Thanks for your feedback. Sorry, didn’t make it clear but I am one of “them” 🙂
Email me at FirstName @ CompanyName.com if you’ve got any questions/comments.
Some companies could benefit from better Anti-automation measures. MiTM Phishing sites are using the ability to verify accounts remotely to create advanced phishing sites that reject invalid login information.
Also, it is important to remember that OTP measures do not stop phishing all together, they help reduce repeated account access. With MiTM Phishing sites, the OTP can be captured, passed and the account accessed by the bad guy.
The “two channel” method is a reactive measure to the account already being accessed….how do we stop them from accessing the first time?
@Technocrat
“how do we stop them from accessing the first time?”
Your question is both simple and awkward to answer (like all the good ones).
First an asumption which appears to be valid these days,
“the communications channel to the user is always untrusted”
That is what you see on your PC screen may or may not be true, and may lie to you at any point of an attackers chosing.
That is a MiTM atttack would acts transparently during setup phases and then subverts the channel for the financial transaction presenting you with false information on the screen etc.
A SSL Tunnel cannot prevent this attack if the MiTM agent is on the PC between the user and the point of encryption (or it has leaked the sesion keys down stream, etc etc).
You might ask “What about using a trusted operating system”?
Well no if the MiTM agent is on the video card and in the keyboard communicating via subliminal channels then most secure OSs (Including MS’s Ideas) just won’t be of any use (see later for reason). Is this possible well yes, any IO device that has a microcontroler on it and Flash memory can be subverted by an attacker, and a lot of hardware these days is designed to be “field upgradable” from your PC motherboard outwards (even some mobile phones can be upgraded through a PC this way).
So you have to include the user into the authentication process somehow, not just on communications setup but on all parts of the transaction that are relevant. And importantly the authentication has to be in both directions and both timely and dynamic in nature to prevent the MiTM agent being able to predict what it is going to be. So using the unaided human is out on this score.
This gives rise to the notion of a secondary communications channel for authentication, but as I pointed out earlier that also is an untrusted communications channel as well (for cost reasons). And as the complexity of phones increases it is more likley than not these days that the user will at somepoint connect the phone to the PC, at which point it is not unwise to asume that it is now potentialy infected with an MiTM agent as well (from an attackers point of view working for the phone operator would be good as you could force the MiTM agent down the air interface and the user could not stop it).
You could keep adding channels but unless you can trust one then the situation is not going to change….
So in reality a second communications channel that a user would have normall access to is not a solution to the problem at all.
This is where you realise that you have to start looking at things like dongles that the bank issues to the user. At present they are all but usless as they do not provide the required level of authentication, and in most cases are unidirectional as well.
The dongle has to be a real piece of hardware, a piece of software to go on a users phone or pda is just not going to work for the above reasons with the PC etc (Sorry Igor).
So the bank spends a little time and money designs or gets designed a neat little dongle and as it is cost sensitive and not a core business gets it made out of house.
As Apple found out not so long ago when a PC virus was put on iPods in a subcontractor factory, there is always going to be somebody in your supply chain who is going to be bad (even without financial inducment) if the chain is large enough.
So it is very possible that all hardware that you use will have an MiTM agent on it so Graphics cards etc might well have them put on during the design proccess and then be (unwitingly) crypto signed by the manufacturer so a trusted OS will accept it….
The cost of preventing this attack is way beyond anything a non government organisation is going to want or be able to spend. And the resulting product would just not sell as it would have priced it’s self out of the mass market.
So esentialy the answer is you cannot keep the bad guys out and online finacial transactions across untrusted communications cannot be made totaly secure.
But somebody will say “nothing is totaly secure” which is true and then asks “how secure does it have to be to make a workable system?”.
Unfortunatly it depends on how you go about it. If you initialy raise the security bar to a point where it is not economicaly viable to attack the system then the system will not be attacked in a given time frame (as the cost of attacks halves about every 6 months due to the usual improvments in storage and computer technology).
However what happens if you only raise the bar a little (as has happened), then it is economicaly viable to attack the system and people will, and you get into an arms race with them (for the same reason children pester parents for sweets).
Therefore at each point the increase in security unless sufficient will alow the attackers back in (which is what we have seen with Sky Set Top Box cards in the past).
Worse the small increments actually drive the attackers into more and more sophisticated attacks much more quickly than would otherwise have happened, as they have the sorce of finance to drive it forwards and the motivation. Each small step only cuts of their money supply for a short period of time, and not long enough to put them out of business. However due to their past activities they have a sufficiently large financial buffer to be able to make very much more sophisticated attacks than would have been possible for them initialy.
So as you see I am not exactly optomistic that online finacial transactions across untrusted networks will ever be viable (except for brief pirods of time) via technological solutions…
Which makes me wonder how long before we either see High Street Bank Branches poping up again or worse draconian legislation to protect the banks (ie DMCA etc for entertainment IP agents)…
Perhaps the simple solution is to move the liability for any losses from the customer to the bank, then they might just do things properly to start off with…
I would be interested in any and all comments as hopefully the banks etc might just look and think.
Personally I will opt out of these schemes as long as possible. More security for the bank generally implies I get less security. I have to prove that I really did not pay xyz £1,000 and my bank will claim: you did a and you did b, therefore it must have been you. If my bank force me to adopt such technologies I will probably change banks.
Going slightly OT – Today’s email from Zopa:
“…A new feature at Zopa. If you’re happy to receive personal information by email, we’ll send you your overall balance and other info about your account….”
Nice, Zopa want to put my financial information on a postcard and send it around the globe!
How do you get a ‘phishing’ question past your second marker and external examiner when creating your exam paper. Usually I am expected to provide a guide to the answer in one form or another so that the others can see how I assigned marks.
This is in order to protect us all and provide a bit of rigour to the process.
Regards,
Peter M.
Banks go out their way to make things easy for those who wish to help themselves to our money. I have sold a house and have a large amount cash I wish to keep in a savings account at my bank. I am travelling for about a year and need to bank on-line, but I do not need to have access to my savings account and do not want this amount to appear on-line (the level of security is very low). I have asked my bank, the Royal Bank of Scotland, to remove my savings account from my on-line banking. Impossible – every penny I have must appear on-line (credit card information can be excluded from the on-line information). I am closing my account with RBS.
Nothing to do with phishing – but it’s all the same mess.
We just released a commercial product called PhoneFactor that does basically this – two-channel, two-factor auth using actual phone calls to users’ phones during login. The user answers the call and presses # to confirm the auth.
We’ve had the system running in beta or release for eight months now, and our customers love it – user training is almost automatic (everyone knows how to use an IVR), and deployment is a breeze, with no tokens, etc.
It also has the advantage of not requiring users to have working SMS service (lots of people don’t know how to work SMS), and unlike other phone-based two-factor authentication, it doesn’t require any software to be installed on the phone.
Check it out if you’re curious – it’s a free service (and enterprise add-ons are coming soon) – http://www.phonefactor.net.