The Failure of Two-Factor Authentication

In 2005, I wrote an essay called “The Failure of Two-Factor Authentication,” where I predicted that attackers would get around multi-factor authentication systems with tools that attack the transactions in real time: man-in-the-middle attacks and Trojan attacks against the client endpoint.

This BBC article describes exactly that:

After logging in to the bank’s real site, account holders are being tricked by the offer of training in a new “upgraded security system”.

Money is then moved out of the account but this is hidden from the user.

[…]

Called a Man in the Browser (MitB) attack, the malware lives in the web browser and can get between the user and the website, altering what is seen and changing details of what is being entered.

The solution is to authenticate the transaction, not the person.

EDITED TO ADD (2/6): Another link.

Tags: , , ,

Posted on February 6, 2012 at 1:23 PM • 48 Comments

Comments

NobodySpecial • February 6, 2012 1:51 PM

After 20 years as an IT pro – I have totally given up on online banking.

I call the call center. I speak to someone with a Yorkshire accent – I reply in Yarksha to check.

PaulR • February 6, 2012 1:59 PM

Bruce, you talk about risk profile, regarding “authenticating the transaction” not the user; you give an example where a user ‘logs on from Romania’.

Surely the simple use of VPN/Web proxys mean relying on this to detect fraud is also a useless approach?

Jason Yip • February 6, 2012 2:02 PM

From what I understand, the idea is that attackers will find it easier to re-target to banks that don’t have 2 factor auth, at least until everyone has it, at which point the evolution continues

Juergen • February 6, 2012 2:06 PM

Here in Germany I use the ChipTAN system, which transmits some payment details (account number and amount) to a small calculator-like device which accepts the bank’s EC card. The device displays the account and amount and then lets the chip on the card compute the TAN for authorizing the transaction.

As long as the device can’t be tricked into displaying wrong data (no indications so far) that’s very safe.

Description in German: http://de.wikipedia.org/wiki/ChipTAN#chipTAN_comfort.2FSmartTAN_optic_.28Flickering.29

Pete • February 6, 2012 2:43 PM

Barclays do authenticate the transaction, not the person. In order to carry out a transaction you need to enter both the amount involved and reference number of the person receiving the money into a separate card reader that accepts your debit card. You then key the authorisation code back into the on-line banking system.

The problem is not that intended transactions are being modified, it’s that fake transactions are being passed off as “training”. The user is duped into playing through a training transaction, that results in a real transaction taking place.

AlanS • February 6, 2012 2:53 PM

The BBC is a little slow on news gathering. Two years ago Brian Krebs was writing “… thieves are routinely defeating security tokens through the use of malicious software like the ZeuS Trojan, which can re-write the bank’s actual Web site as displayed in the victim’s browser, so as to inject code asking the victim’s user name, password and security token number.” Even the FFIEC got round to updated their 2005 guidance to banks last year and they were widely criticized for being slower than a snail.

Natanael L • February 6, 2012 2:58 PM

@Pete: As a bank, I’d tell the user that we NEVER EVER would do that over the internet, such training would only happen the first time they recieve the device and then only, just to show them how it works. Also, this would only happen with a fake card with number series owned by the bank that will remain unassigned forever. And these numbers would be on big fat posters and all the staff would know them netger than their own phone numbers.

and so on…

Alice Bevan-McGregor • February 6, 2012 3:19 PM

MitM and MitB attacks are something no bank I have ever had understands. “Pick an image and a phrase” confirmation systems are worse than useless: they inspire enhanced trust with zero actual security gain.

Were I to pish, I’d use a transparent proxy to capture all data bi-directionally, including a session cookie I can then use during the user’s visit to perform additional evil transactions.

Chris • February 6, 2012 3:20 PM

@Juergen

We’ve got a similar system in your west neighbors. But they send the TAN code via SMS (together with transaction amount). No extra device need.
Pretty convenient twofactor system until people started using their smartphone to login to the website, specifically the phone with malware on it.
Even more self-defeating is the banks new ‘easier’ mechanism of retrieving lost username/passwords. You guessed it, they sms it, as long as you provide your accountnumber. ** bashes head against wall **

Fortunately I’ve been able to keep my desktop clean for a decade with common sense and my login details tentatively safe with KeePass.

Adam • February 6, 2012 3:47 PM

Two of my accounts use a little keypad. One religiously requires me to enter codes even when I log into the device or perform any kind of transaction. It even prompts me at login to enter part of the serial nr on the back of the device, perhaps suggesting someone may be capable of cloning them.

The other bank has a keypad with a smart card reader. I don’t need it to log in but I do need it to additional payees to my account, e.g. to transfer money out.

Curious • February 6, 2012 4:02 PM

RSA in Scandinavia have voiced opinions about the lack of security with merely encryption for authentication in bank transactions (Sept 23. – 2011):

What they suggest seem harmless enough. They want to build a database of users habits to flag suspect payments, and in such event contact the user for an added layer of security, in addition to encryption and authentication.

http://translate.google.com/translate?sl=no&tl=en&js=n&prev=_t&hl=no&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.tu.no%2Fit%2Farticle294296.ece&act=url

With Norway set to start implementing its forced data retention directive already decided on last year, for computing and mobile phones, I can envision how stored data can be abused by others not being the police. I guess it is fair to assume that the secret services tap and store data on a daily or weekly basis, or so I would like to imagine, with a retention directive or not.

Clive Robinson • February 6, 2012 4:04 PM

As some of you know I spent some time thinking about online banking for something like 20years.

However the one thing I’ve learned in all that time is that the banks are not realy interested in security unless forced to…

In fact I said that in a coment to Bruce’s post about the essay,

http://www.schneier.com/blog/archives/2005/03/the_failure_of.html#c453824

You will also find another comment of mine there making the point that the authentication of the transaction MUST be in both directions, and likewise needs to be done in such a way that the authentication goes out beyond the PC either via a side channel or some other devices.

If you have a hunt around you will find quite indepth conversations between Nick P, myself and others on how to go about doing it “through the human” and “through a token” and what a token would need to do and how.

Vles • February 6, 2012 4:52 PM

MiTB sounds to me like someone took the greasemonkey / greasekit etc + custom .js combo to another level…

Nick P • February 7, 2012 2:21 AM

@ Mark Currie

At first, I was rolling my eyes at “client-side with little or no implications.” I was thinking “Here comes another guy who doesn’t get system implications or is pushing a framework.” Then, I saw your name & breathed a sigh of relief. Yeah, the four of us who were actively discussing this exhausted most practical possibilities and issues. It’s a solved problem, imho.

Yet, Clive and I agree on the true issue: courts and banks so far don’t care about risk mitigation in online banking. They’re not being forced to use better methods & the sheep continue to swan dive off cliffs in the name of confusion or the peace of ignorance. Hence, most solutions will fail. Tommy’s restrictive LiveCD, your device or my protocol modifications might work. (in that order)

It’s a hard sell, though, if the courts rule that doing online banking on an easily infected PC w/out alternatives constitutes “reasonable security.” They have, so I ain’t holdin’ my breath. 🙁

Ping-Che Chen • February 7, 2012 3:10 AM

This reminds me a popular attack here in Taiwan.

Some telecom companies implement a simple e-commerce system. Basically, you buy something on the internet, then it sends you a SMS with an “authentication code,” you type the code into the web site to “prove” that’s you (i.e. authenticate the user). Then the cost of the goods is added to your telephone bill. In theory, as long as you still hold your mobile phone, this should be “safe.”

However, people are tricked into pay for things they didn’t buy (mostly “virtual goods” such as time cards for online games). Attackers may tell them that “you won a free something!” or something like that, and tell them to input the authentication code in the next SMS to a certain web site to “win the free prize.” If they did, then the cost will be added into their bill, and the fraudulent transaction complete.

This is actually not very hard to fix. The authentication code SMS shouldn’t just say “authentication code: ABCDE.” It should also include details of the transaction, like “You are buying something (shipped to a certain address). Please input authentication code: ABCDE to confirm.” If the user is careful, s/he will be able to authenticate the transaction and refuse to input the authentication code for something s/he didn’t buy.

Of course, it’s still possible that the mobile phone may be lost (but it’s easy to inform the telecom company that the phone is lost and prevent any further transaction), or the phone has some virus which can intercept the SMS. However, even so the user should be able to get the SMS fairly quickly and know that someone is buying something with his mobile phone account and, in theory, can inform the telecom company to stop the transaction.

FOK • February 7, 2012 4:12 AM

It is sad that where I live are banks ditching authentication calculators. These devices where you have to input transaction data to get authentication code are superior to any other kind of authentication. They are just starting to give users less secure options.
I am wondering, when someone will overcome authentication with smartcards. When the computer is hacked, then is shouldn’t be problem to obtain user’s PIN and then supply it to the card for whatever transaction done by hacker.

M.V. • February 7, 2012 4:25 AM

“The solution is to authenticate the transaction, not the person.”

This does not protect against the described attack. The attack tricks the customer into authenticating a transaction using a fake training session.

The BBC article is a bit murky and suggest that the mentioned bank are using OTP token for authentication. This would be just another flavour of TAN/iTAN/SMS-TAN. This allows a MitB just piggy back on a transaction from the user and manipulating the displayed account statement. Has been done already, no need to fake a training session.

I couldn’t verify from here (Germany) the mentioned bank is really using only OTPs, but the choosen attack suggest sto me that banks are at least offering something like the german SmartTAN+ or MobileTAN (SMS Message which includes transaction details)

Blaming the banks is easy and i don’t trust them either, but i ask the experts here, how can the bank protect against stupidity on the customer side? There will always a way for the attacker.
(Dedicated online banking devices may help, but even those can be lost).

Jonathan Wilson • February 7, 2012 4:56 AM

The most secure solution would be a device that connected to your computer/smartphone/tablet somehow.
It would have a number pad (with decimal point for entering money amounts) plus a smart card reader.

When you want to make a transaction, the online banking site directs you to insert your bank card (with smart card chip in it), then input the account number of the account you want to transfer to, the amount you are transferring then your pin number (the same one you use at an ATM).
The device then passes this information to the smart card (account number, amount, PIN) which encrypts it using a private key stored on the smart card. The resulting encrypted data is sent by the device back to the host and from there on to the bank where it is processed.

Downside to this would be limited OS/browser/device compatibility plus inability to use it for internet cafes/kiosks/etc where you cant plug it in. And probably the cost too.
But if implemented the way I described it, its completly impossible to attack via man-in-the-middle, via a fake site or via a compromised host. Only way to break it would be if you could somehow physically modify the PIN pad to present information to the smart card that is different to the information input by the user (or if you can steal someones smart card and PIN but if you can steal their card and PIN you could just use them at a regular ATM). Or of course the cryptography could be cracked somehow (i.e. recovery of the private key used for a given users smart card) but if its properly chosen, the only way to do that would be brute force (which would take too long to be economically viable for the bad guys)

M.V. • February 7, 2012 5:05 AM

@Jonathan Wilson
“The most secure solution would be a device that connected to your computer/smartphone/tablet somehow.
It would have a number pad (with decimal point for entering money amounts) plus a smart card reader.”

There are such devices, they are based on the HCBI standard.

But how will this protect against a fake training session as described? As it is more complicated to use, more people will fall for the attack.

Mark Currie • February 7, 2012 6:20 AM

OK I was fooled by Bruce’s words. It seems as though he also did not realise that the system was in fact using transaction authentication i.e. this was not a MiTB in the usual sense since it did not change any of the transaction details.

I suppose that the banks could warn people about this one and it might go away.

However, here’s a nasty one that I just thought of that also gets around transaction authentication:

Imagine if malware searched through your e-mails as they arrive looking for attachments that contain banking details, and then changed them 🙁

I probably shouldn’t have mentioned this but I bet someone else has already thought of it anyway.

Henning Mak • February 7, 2012 6:23 AM

The “authenticate the transaction” links looks beguilingly like it ought to lead to an explanation of what you mean by that.

However, it seems just to lead to a post that doesn’t explain it either, but has another “authenticate the transaction” link.

This second-level link leads to a wall-of-text that, as far as I can see, doesn’t explain it either but just asserts that if we make the transaction processors liable for misuse, something magical will happen that solves the problem. (Just like you assert it happens for credit card companies, again without explaining what the magical thing credit card companies do IS).

Could you please post a self-contained explanation in small words of what you mean by this slogan?

Ultimately, what makes the transaction valid is that the flesh-and-blood person the card is issued to agrees to be liable for it. How does it make sense at all not to authenticate the user, when the identity of the user is the very thing we need to be sure of?

Henning Makholm • February 7, 2012 6:29 AM

(Continued) There seems to be a hint that “authenticate the transaction” means to reject transactions from Romania if the card has not previously been used in Romania.

However, if I go on a vacation or business trip to Romania, I certainly except my Visa card to work there. That’s why I have an international credit card in the first place.

Are you advocating a system where I need to notify my bank in advance of places I’m going where I might need to spend money? If so, how are you proposing that the bank should verify the truth of that notification — if authentication of my identity is never supposed to happen?

And what about domestic card fraud?

bob • February 7, 2012 7:34 AM

A lot of people, starting with AlanS at February 6, 2012 2:53 PM seem to be misunderstanding this attack.

It’s an attack against two factor authentication. Krebs’ article is about a different attack and posting details of your little calculator thingy are just noise.

This attack involves accessing your account using whatever security is provided and then being prompted to execute a “training exercise”. The “exercise” takes you through making a payment to Mr.V.Honest with all the security. At the end of the “exercise”, your browser says, “well done”, and it’s not until you get your paper statement you realise that you actually have made a payment to Mr.V.Honest.

AF • February 7, 2012 7:54 AM

Securing the endpoints can be a further layer to consider as protection against such attacks. Products are available out there which until now withstand MITB attacks. Banks could enforce that such product is installed or else lower transaction limits or disable 3rd party transfers.

paul • February 7, 2012 8:51 AM

Taking the SMS authentication-code fraud example a little further, eventually we’re going to have to not only verify that it’s the user knowingly deciding to make a particular transaction but also that they’re compos mentis enough to do so. (There have been a few pieces on vendors who reputedly target drunk or otherwise impaired buyers.) Along those lines there’s probably a minimum safe level of difficulty for authorizing a transaction: e.g. OK to retype a code, not OK to just push a button that triggers a code snippet to cut-and-paste for you.

Mark Currie • February 7, 2012 9:32 AM

This kind of attack is not limited to defeating two-factor authentication. As a general class of attack it is fooling the user to enter the attacker’s account details as though they were legitimate.

I don’t know if anyone got what I hinted at in my last post, but here is another form of this class of attack e.g. The interception and modification of beneficiary account details in emails and email attachments (e.g. bills). It may be possible for malware to do this automatically by scanning your incoming emails but this attack is not limited to Trojans, nor is it limited to online banking payments. Anyone having access to an email server’s database could search for un-read emails that include payment details and manually modify the payment instructions.

AlanS • February 7, 2012 9:50 AM

@Bob

Krebs article is about an attack on two-factor authentication. The title’s “Comerica Phish Foiled 2-Factor Protection” and he’s even got a picture of an RSA SecureID. The more sophisticated malware has been bypassing two-factor for years.

Two factor is more effective when it’s out-of-band two-factor i.e. second factor is communicated over a second, independent channel and the customer is educated to never, ever to mix the two factors/channels.

FFIEC 2011 guidance: “Since virtually every authentication technique can be compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security, as described herein.”

They go on to provide a long list of controls, including out-of-band verification, and, for commercial customers, controls such as ACH Debit Block, ACH Debit Filter, Positive Pay, etc.

FOK • February 7, 2012 11:06 AM

@bob
With proper two factor authorization will be even such attack impossible with just minimal sense of reality. Most two factor systems authenticate only user but not transaction. For banking transactions it is very easy to verify offline key data like target account and amount of money transferred.
Here are few examples how two factor authorization for banking transactions is done right.
http://www.rb.cz/attachements/klientskySystem/CZ/OFF_PrihlaseniKUctuHelp_OEk.htm
http://www.barclays.co.uk/Helpsupport/TourPINsentry/P1242559977752
Both of them are authentication calculators that require you to enter account number and amount of money transferred for generating security code.
And if someone will implement it in this format http://www.dailymail.co.uk/sciencetech/article-1085642/The-new-credit-card-keypad-promises-fight-online-fraud.html , then it will be easy for us to carry strong security everywhere.

FOK • February 7, 2012 11:20 AM

@Henning Makholm
I know about a bank that allows you to block your card. So when someone takes your wallet, he gets blocked card. When you go shopping, you just send unlocking SMS, that is protected by SIM Toolkit application and your card is unlocked. After you buy what you wanted, then you can lock your card or it can be locked automatically after some time period. This works for 10 year old mobile phone my wife used until recently. And with card with keypad (see my post above) it can be much more simpler. We should just insist that our banks improve our security.
BTW: @PaulR talked about online transactions made from Romania.

Clive Robinson • February 7, 2012 12:11 PM

@ AF,

Securing the endpoints can be a further layer to consider as protection against such attacks

It’s quite a bit more problematic than that and it may not be possible to achive sufficient security.

As I said, I, Nick P, Mark Currie, RobertT and others have had numerous chats about this and the details get quite involved, but tend tto favour the attacker due to human failings.

Firstly to even get close to succeeding you need two independant channels in one form or another and the human actually needs to be activly inside the authentication loop that connects the two channels.

Otherwise low level attacks can do an “end run” around the authentication system (such as a screen driver incorectly displaying 10USD as opposed to 1000USD etc).

Further the authentication needs to be in both directions that is each transaction has to be authentticated by the user, the bank needs to check it authenticate, and then send it back to the user so they can check the bank actualy has the correct transaction and that it has not been modified in transit.

But importantly the authentication is not just on the financial transactions but on all transactions which includes the login and key exchange protocols as well. Further the authentication needs to include all the relevant details of the transaction.

For this to work you are looking at a minimum of 100bits plus an authentication code (signiture) of equivalent or greater length going from the user to the bank, the equivalent coming back and then going back to the bank again.

Although for good and proper security reasons this should “go through the human” to get from one channel (transaction) to the other (authentication) in most respects it’s not practical.

Nor is another good and propper security requirment for the authentication channel to consist of a device that is not mutable, be practical for manufacturing reasons (so it cannot be infected with malware etc).

These two failings show that the solution is going to end up as some kind of box that connects into the insecure PC sitting on the highly insecure Internet channel. Thus without the authentication loop going through the human the whole setup is always going to be unavoidably insecure.

Thus the real problem is making the “human channel” work, use very few key strokes but in some manner giving the required level of security.

This is usually done by making a trade off of some form, such as using a very small number of bits but in such a way that a suitably security margin is preserved by for example a time window that is to short for brut forcing etc.

However, in reality such a trade off appears to be a “Holy Grail” chase, (although I thought I’d cracked it at one point by using capatchers). Because either humans or the technology will break down with all the keypresses involved.

But plugging in a USB plug is also prone to difficulties, the first being that USB connectors are made on the cheap. And as some “smart phone” users have already found out with their USB chargers the connectors won’t stand up reliably to being plugged in and out once a day for even as much as a year of usage…

Secondly and perhaps more importantly the user cannot “see the data in the channel” between the very insecure Internet connected PC and the authentication loop hardware. Thus malware can be put onto a mutable device and the user will not be aware of it…

As Apple, Microsoft and most games console and cable / satellite settop box designers / manufactures have found they arn’t as smart as those that aim to break their systems. And as Stuxnet showed even signed code is not secure simply because a malware writer can get work upstream of the signing process or a “black bag job” can be done to steal the signing key.

And as a conversation between Nick P and RobertT on this blog concluded, even the microcontrolers can be “got at” during design prior to manufacture one way or another.

And as has history has shown us over and over again “what man can make man can rent asunder” and that “where there is a will there is a way” especially when the prospect of near unlimited riches is seen as the outcome.

mik • February 7, 2012 3:53 PM

My bank (NAB) does authenticate the transaction – they send an SMS “Authorisation code from NAB for transferring $2000 to 123456-123456 is 432109”.

Also, they don’t allow you to do anything from the mobile app that requires an SMS code – although you enter the same username/password into the mobile app as the web browser, so a compromised mobile is still enough to steal my daily transfer limit worth of money.

Can’t say the same for the security of their online-only subsidiary “uBank” – they embed a YouTube video into the secure site, so everyone using their site is clicking through a warning and ignoring a red cross in the browser bar.

RAR • February 8, 2012 3:21 AM

Banks implement the level of security needed to maximise profits. Think about this carefully. It is not in Bank A’s interest to implement a security solution that is much more secure (but much more difficult to use) than Bank B’s solution. Customers would move to Bank B. (And here I am talking about average customers rather than the security aware or paranoid like myself)

Content signing using an external device is a good way to secure transactions, but it is more difficult than just pressing a button in a browser and therefore less attractive to the average customer. The customer has to manually key in transaction details into a fiddly little device.(Keying anything other than customer recognisable transaction details into the signing device is not very useful in defeating MITB or MITLLOTM – Man In The Lower Layers Of The Machine -attacks as @CliveRobinson says above.) A less secure but in some ways more usable option is using an external channel such as mobile phone for transaction verification. However, mobile phones are vulnerable to malware and their users are vulnerable to social engineering.

Of course the level of security needed to maximise profits changes over time. Therefore a clever bank develops extra security measures long in advance of actually deploying them. As the fraud levels make operating at a certain security level unprofitable, new measures are brought online. For banks to implement more security than is needed to maximise profits you either need some kind of cooperation between the banks to roll out an industry-wide solution or regulation to force them to do so. Variations of this have happened in the Nordics – e.g in Denmark banks use NEMID which is a partnership between banks and the state.

Curious • February 8, 2012 2:11 PM

@RAR
NEMID seem to has a website with a domain associated with the island state ‘Niue’, how odd imo, since the island is outside Australia on the other side of the earth.

Wikipedia has an article about the .nu domain, which claims that the domain is popular for alot of scandinavian and european countries.

I just thought that danish websites would naturally be using the domain for Denmark, with .dk.

John David Galt • February 8, 2012 10:03 PM

@HenningMak: “authenticate the transaction” seems to mean the manual procedure the banks have used for a long time: that is, if the card issuer sees a charge that is unusual for your account (say, both large and a long way from your home) they phone you and ask if you really made the purchase. I’ve gotten such calls several times, and appreciated the fact that the bank was watching.

Of course, the real solution is the same as for other risky situations: give the person or institution that can most easily protect against a threat the incentive to do it by making them liable. So long as (for instance) British banks were able to shrug off all such losses onto the customer, there was no reason for them ever to improve their security.

Mark Currie • February 9, 2012 1:50 AM

In this class of attack, the person paying is entering (in full confidence) payment details which are already incorrect. Therefore no amount of traditional authentication mechanisms will stop the fraudulent payment. It’s a higher layer of attack and the reason it works is because there is no human-recognisable connection between an account number and the beneficiary.

What if banks changed from account numbers to human recognisable beneficiary names? OK, so you might have the problem of Joe.Soap543 and Joe.Soap544 etc. but it would force the attacker to know who you are paying and to create a fake account in a name very close to the intended beneficiary name (a lot more difficult).

The problem with this solution is that it’s such a major change for banks to make, that they just won’t do it.

Clive Robinson • February 9, 2012 4:32 AM

@ Mark Currie,

It’s a higher layer of attack and the reason it works is because there is no human-recognisable connection between an account number and the beneficiary

At the risk of “reboiling” 15-20year old cabbage, there is a (partial) solution to this problem by abstraction. The down side is marginaly less flexibility but not so much that matters for the average joe (or has been dealt with in other ways for businesses via the BACS and equivalent systems).

The solution is a method whereby the full account details (ie Account Name and ISBN) are “read only” in the users account and refrenced by a simple two digit number.

So the user can only select a pre agreed account to pay into from a list that is unique to them and their account.

The method the user uses to add or subtract an account from that list is by filling in and signing a two part paper form that the bank then adds to the list after an agreed cooling of period and procedure (the details of this are a seperate security issue).

Thus even if an attacker got into the browser and displayed a “training screen” etc, the only accounts that the user could select for payment are those they have already authorised.

The reason this can work for ordinary users is that in (Europe certainly and) most countries the average user very very rarely makes “one off payments” from their account, it’s mostly regular payments to organisations with whom they have an account. One off payments can more easily be done with a cheque or credit card (which again have other unrelated security issues).

Clive Robinson • February 9, 2012 4:42 AM

@ Curious,

Wikipedia has an article about the .nu domain which claims that the domain is popular for alot of scandinavian and european countries

But does it give the reason?

I first came across this in Sweden but it did not hit home until I actually had to interact with small businesses and individuals in Sweden around 2000.

Put simply the agency responsable for the Swedish top level domain, would only hand out the use of the domain to “recognised organisations” such as Government, Public Companies and education etc. Othe individuals and small businesses were not alowed to play and thus had to find another domain to use…

It is the consiquence of the difference between the US UK and many WASP and other nations of “anything is permitted unless expressly forbidden” verse the more catholic Continental vie of “nothing is alowed unless expressly permitted” which is the so called “permiso/nonpermiso mindset”.

Curious • February 9, 2012 5:01 AM

@Clive Robinson
I read yesterday on wikipedia that “nu” simply sounds like “now” in a variety of languages.

Clive Robinson • February 9, 2012 11:03 AM

Woops just noticed the brain pulled the wrong quad letter acronym out this AM (more than a couple of hours sleep would help).

So, replace ISBN with IBAN in my post at February 9, 2012 4:32 AM

@ Curious,

I read yesterday on wikipedia that “nu” simply sounds like “now” in a variety of languages

I’m in danger of commiting the same mistake as I did earlier… But I vaguely remember being told the “nu” is the root of an old Germanic word, that spread across Northern Europe from East to West and has changed marginally with time and means effectivly “new”, it also went south with the Dutch East India and Boers and spread into various freshly invaded lands…

I guess if I count slowly to ten thousand somebody will either confirm or deny your or my interpritation of “nu”, or for even more fun give voice to another “theory” 🙂

Mark Currie • February 10, 2012 1:30 AM

@Clive Robinson

I agree that the predefined beneficiary is the safest. However, once-off payments are highly convenient and very difficult for both client and bank to revert back. There is a strong ratchet effect here.

If you choose to limit payments to predefined beneficiaries then how you register them becomes very important. You mention an official paper-based system with other checks etc. which sounds like a well thought-out method. I once had an argument with someone about this very issue. He claimed that his online banking was very safe since they only used predefined beneficiaries. However, when I asked him how he registered them he said that he did it online using a 2FA method 🙁

Clive Robinson • February 10, 2012 2:07 PM

@ Mark Currie,

However, when I asked him how he registered them he said that he did it online using a 2FA method 🙁

Ouch…

Why do so many people forget about the “weak link” that “breaks the security chain”…

I’m by no means perfect, but if I’d spent some time eliminating a threat vector from one area why would I either reintroduced it at some other point, or if already there not try and eliminate it as I had done originaly…

It’s not that I’m against two factor authentication, it can be made to work in some limited circumstances, it’s just that most times trying to do it it’s like trying to balance an egg on the point of a cone… You can do it but is it worth the effort? Especially when full two way transaction signing can be done for effectivly the same price (technology wise).

But… (ther always is one 😉 the sweat factor for the human goes way way up as does their error rate. And this is the real problem, any method that will get this right down without reducing security is highly desirable.

In some respects it’s the flip side of the ratchet effect users have got used to tapping in at most a short sequence once on logging in, they might (and have) go for a short sequence on each transaction if the only do one or two at a time. But not for many more than that.

Which when you consider a small business might do a hundred or so each day is a compleate non starter.

Hence much as I hate the idea a USB dongle or equivalent makes bussiness sense, for a while. But as sure as eggs are eggs some little “5cr0t3” is going to work out how to do the seamingly impossible and abuse that comms interface that closes the channels together and get malware or false flag data down it into the dongle. It’s why I rate finding a longter reliable solution up with getting the “Holy Grail” (from reading just a Dan Brown book 😉

Beck • January 31, 2014 10:19 AM

Interesting stuff. A lot of 2fa solutions are vulnerable to MitB attacks, but aren’t these just the in-band solutions? Companies that use out of band solutions (Duo Security and Toopher for example) push the notification through an outside channel (e.g. a mobile device) so the authentication can’t be compromised by a lurking hacker in the browser. Toopher even uses your cell phone’s location-awareness to automate the authentication so you don’t have to manually approve everything, which is a huge plus for me because I hate having to constantly authenticate. Honestly, I feel like the more I’m asked to approve an authentication, the less I pay attention to what it is I’m authenticating, which could be pretty dangerous in the long term.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.