I advised against using SMS some years before for a number of reasons (mainly because it is "an unreliable service" and spoofable on smart phones) and low and behold the attackers found another way around them which was to "call the phone company and tell them the phone was lost/broken and transfere the service to another phone".

It's obviouss with hindsight but as usual it was a weakness in the system that was not thought about and used a simple fact of "non aligned interests" between the phone service provider and the banks leveraging the phone service for something it was never designed for.

I've always said (for basic liabilty reasons) that the solution should be provided by one of the two interested parties with vested interests (ie the bank, as the bank probably won't trust a customer solution no matter what the advantages).

I've also said the solution should authenticate the transaction not the users at the start of communications (ie to limit MiTM attacks).

But also and more importantly the authentication process shouls put the customer in the loop and not alow modifications to the PC at any level to alow an "end run" around the security.

The implication of this is of course a side channel device (token) that is supplied by the bank and is not connected to the computer in any way and is preferably immutable so it cannot have malware put on it. So far such implementations are at best rare, so have not yet been considered by attackers in any great depth yet.

It will be interesting to see if they can think of ways around a properly implemented version...

I guess time will tell ;-)

This works as long as the attacker doesn't have access to your cell phone as well as your password, and as long as it is not easy to change your phone number through the web interface.

The odds against you having a birthday which is the same date
as a stranger born in a leap year are 1/366;
but in a classroom of 23
there is even money that
two persons have the same birthdate.

A battering ball hurled by a trebouchet
would almost never succeed in hitting
a particular stone in a castle's wall,
but it would hit any number of stones,
and knock them loose.

"... now what are possible solutions? It's easy to find fault now try proposing a solution"

I came up with a solution back in the 1990's to some of the issues (and have posted about it on Bruce's blog a number of times in the past).

However you have to remember that many of the organisations using very weak systems have many many customers and they don't want to be spending the money...

So instead as we have seen they go for a low cost system which is almost invariably weak in the way it is implemented by them. And as they know the system is weak and has more holes than a second hand string vest they also have a set of non negotiable rules that externalise the risk back onto the customer or the merchant or who ever as long as it's not them picking up the tab.

Untill this cost-risk issue is solved the situation will not change irrespective of how cheap or effective any given solution is....

Until somebody builds a better mousetrap, these two-factor auth methods are all we have to rely on and they still help me sleep better. Besides, we all know the biggest threat is the one from the inside, from which there are even fewer courses of action.

"What biometric alternatives could the company employ? What are some of the factors it should consider when decideing among the alternatives?"

The first question you should ask is what does biometrics in general get me and for what price.

Or to put it another way they are generaly costly unreliable and have way to many false indicators (both positive and negative) for a general purpose system with more than a handfull of employees.

Then if you still want Bio-metrics consider those that are not contentious with users. Fingerprint and Retina scans are deamed by many as to intrusive (they also have maintanence and health issues respectivly).

Then consider what your fall back options are and what they are likley to cost.

For instance a hand geometry device is not going to be a lot of use to some disabled or temporarily incapacitated person (think RSI supports and plaster casts etc etc).

As a general rule of thumb bio-metrics are not the answer to authentication systems due to numerous issues that are not considered by the system designers.

There is of course one aspect to them that is almost invariably ignored. You cann't change an individuals bio-metric easily (or at all) without harm.

Further bio-metrics are equivalent of PII of "data subjects" which brings a whole heap of other legal issues etc crashing down around the system depending on where you are in the world.

I would seriously take a long hard look at the alternatives first and decide why they are not acceptable prior to thinking about bio-metrics.

Then look at the down sides and decide what your liabilities are and how to mitigate them.

Then how you are going to mitigate people who have no or poor biometrics. And what you do when your chosen biometric fails due to injury etc.

Then how you are going to deal with maintanence and health issues relating to the biometric.

Then...

Here, the SMS contains the transaction details and a TAN code that the user need to enter on the web which can only unlock just that transaction as seen on the SMS.

As long as the users check if the info in the SMS is correct, no man-in-the-browser (zeus ..) can break this scheme.

What this basically gives you over any simple smart-card solution is the display on the trusted device (or at least a second device) that the malware can't deceive.

Where this scheme might break down is on smartphones, where you combine the webbrowser and the cell phone in a single (potentially vulnerable) device.

Phishers have all but given up on Austrian banks (for now).

Modern malware (Zeus being a great example) captures keystrokes from virtual and physical keyboards, the transmitted data, and it takes screen shots of the infected host. version 2 can do more things (like search the host for specific data) but for the point of this conversation, everything that is stored or transmitted from the infected host is available to the malware operator.

Once they capture your user ID, Password, and Shared Secret, they can simply establish their own session with the server and run their transaction scripts.

The only thing that a traditional Two Factor Authentication solution really gives you is some perimeter security (meaning the captured ID & Password won't give an attacker what he needs to establish a vpn connection into the targets corporate network) and it gives you some audit logs that you don't get with some out of the box vpn solutions (like Citrix Access Gateway)

"In many scenarios I have seen the cost of protecting an asset exceeding the value of the asset. This is not good security."

Unfortunatly if is very often difficult to judge the value of an asset, especially when it is not a physical item but information. It is worse when the asset being protected has low value in of it's self but can confer an unknown high value (such as an SMS confirming a funds transfer).

The solution is to step back from the problem and work out what you are currently doing and what you should realy be doing.

In the case of online banking what you need is not n-factor authentication of the users but two way authentication of the transaction.

This should be via a shared secret and out of channel secure authentication bassed on the key factors of the transaction including time.

The authentication using the transaction key factors prevents them being modified by a MITM attack, and the use of out of channel secure authentication prevents false display of transaction details by trojan etc. Finally the two way authentication assures both users that they are seeing and agreeing the same transaction.

However for some transactions this will effectivly be more expensive than the transaction is worth, but for others it will be a very small price in comparison to an individual transaction.

People in general will favor convenience over security. A system that is too complicated is not widely accepted until it is a standard way of life.

I think Bruce's point rings clear still today if not louder than ever, two-factor authentication is not a savior. Security in layers and done with diligence is the key. In many scenarios I have seen the cost of protecting an asset exceeding the value of the asset. This is not good security. It is simply just throwing money at a problem only to learn it will require more money later as risk changes.

Let us suppose to provide our users with a USB token equipped with a LCD display and an “OK” button.

Before performing fund transfers of any kind, the application is required to generate a simple message containing a summary of the operation being authorized. The message is transferred to the USB token that will show it on the LCD display. The user is then asked to check the message and press the “OK” button on the USB token if he agrees to authorize that operation.

When the user confirms the operation, the USB token electronically signs the message and gives it back to the Web application. As far as the USB token is a trusted environment, the entire process is secure, even if user's client computer is not trusted.

Theoretically, instead of the USB token, we could provide our users with a sheet of paper containing a simple table of “transaction confirmation codes”. In order to authorize the transaction, the user would be asked to enter the confirmation code found at the cross of the “transaction ID” row and the “transaction amount ($)” column.

Please follow the link below for more details on this proposal: http://www.scmagazineuk.com/...

Thank you for your attention and best regards,
Mario

In order to send funds, I am given a code to enter into a security device with a keypad, display and card reader. In combination with my (chipped) bank card, it generates a response code. The beauty of this system is that the authentication (question) code contains digits of the recipients bank account number, so if the numbers do not match up it is evident that an attack is being attempted.

I would prefer to see a write up of the failure of passwords and hello Two factor authentication.

Right now, it's easy to do phishing and MiM because people are trusting of what they get via insecured e-mails. You can certainly deploy a more paranoid browser, but until the web servers also get more paranoid, and check for browser certs, there's not much hope.

Banks could send a set of one-time-use keys on a flash drive, since most computers have USB. The FSF has a "Privacy Key" the provide new members.

If the two-factor devices only cost $5, banks can use them as inducements to open accounts with them.

When logging on, users would provide their username and password as normal, but the number on the token would have to be entered by clicking with the mouse on numbers that would appear at random locations on the screen, hopefully bypassing keyloggers.

This may add complexity for end users (and possibly create other headaches for the bank), but would improve security.

Any thoughts???

This would ensure both the phone and computer are in use by one person, as well as mitigate any threat from Keylogger software.

This assumes that the message sent from the phone can't be spoofed - I'm not sure if an attacker changing his caller ID would be able to get around that.

1) Financial institutions should consider some type of application streaming technology so that users do not operate through a browser installed on their own machine. Both Citrix and Softricity(now Microsoft) have shown that this technology works well. Can a trojan still get in the middle of this? Well, maybe, but it would be very difficult to write, and easier for the institution or end user to detect.

2) Use a keystroke analytics technology to ensure that passwords are actually typed in by the person assigned the password. ie: www.biopassword.com

Anyway, as many others have said, these methods can be defeated, but the global population of individuals with the combined lack of character and skills to do this becomes much smaller each time we improve our technology.

Most users, and I would guess all users with no background in security, myself included, could not tell the difference between a fake certificate and a real one and most citizens have no idea what a policemen's ID card should look like, and certainly could not detect a reasonable forgery.

And of course if the reward is big enough the bad guys will just set up their own CA or, at less cost, use the BBC (Bribery,Blackmail and Coercion) on an existing CA's employees.

user registers with the system and provides the site with their public key. whenever the user wishes to access the system the system generates a random string, m , and encrypts it with the users public key (lets call it u(m)) and then encrypts this with the systems private key (giving s(u(m)) ) and sends this to the user (either though a separate client or through the browser itself) the user then decrypts this with the systems public key (which has been verified by a certificate authority to prove its actually the system they want) giving the user u(m) and then the user decrypts u(m) with their private key to give m1. the user then encrypts m with the systems public key giving s(m1) and sends this back to the system, the system then decrypts s(m1) with its private key to give m1 and compares m if they are both equal then the user is authenticated.

Apologies if the above seems long winded.
It is likely that i would design a piece of client software which would enable most/all of the users actions to be carried out automatically.

does the above sound like a plausible solution?

I had implemented a similar solution last year for a large financial institution where we used digital certificates which were in turn embedded in smart cards and all certificates were X.500 v3 which is being supported by most products. We integrated the authentication system with SafeSign products which generates high quality challenge strings using a HSM. These strings were sent back to the client application which in turn digitally signs the challenge and submits back to the SafeSign application. The signature gets verified for integrity and the certificate is extracted from the signature and verified against the directory of the a commercial certifying authority using OCSP protocol. The authentication systems implemented at the CA end should be treated as the best in the present world. If verified the customer would be given an access to the resource.

Now the question is what if there is a MiM attack at the client application. Since the signature is generated on the smart card, there is no way he can manipulate the signature because we have embedded the public key in the hash before encrypting it with the private key. The attacker can make a copy of the signature but there is very little he can do with that. If he replaces his certificate in the PKCS 7 envelope, the signature would not match and also there is very small chance that the CA would issue duplicate certificates for him to impersonate the customer. There was a threat of the Smart Card PIN getting known to the attacker. We have encountered using the DH and AES algorithms implemented between the Graphical User Interface and the smart card service. The client and server communcation were using SSL protocol.

Well if the attacker can bypass all these things and get authenticated successfully then hats off to his knowledge.

Now comes about renewal and re-validation process. These can be resolved using a well thought business workflow which is to be done by the business analyst and well supported by us. We have integrated PKI solutions into Identity Minder concepts.

dreez

No single technology will implement security in itself. Security does consist of processes and Bruce is fully right to say that 2-factor authentication alone is not the solution to all authentication and security issues.

Of course MiM Attacks are hard to achieve, especially if we also talk strong encryption, but honestly how many people would simply click OK if they get a certificate warning or how many people would not recognize the little padlock at the bottom of IE or other browsers at all? Problem is also not that processes are too complicated, too many etc. problem is the stupidity of the user to ignore common sense and processes because they cause maybe a little inconvinience, problem is also that security sometimes causes too much inconvinience and goes OTT, which then of course forces the user to attempt circumventing a security meassure to gain the convinience back. In case of 2-factor auth for example write the token PIN on the back of the token which renders it useless. And yes the missing interoperability of tokens from different vendors contributes to the Risk. Nobody wants to run around with a multitude of different tokens. I think in total 2 tokens must be enough to cover all authentication requests. One for OTP and one USB token or SC to cover any certificates. I will personally require both very soon for the majority of our users. The OTP token will be used for authentication of any system remotely and access to network equipment or admin access to any server, the SC or USB token will be for Pre-Boot authentication and to hold any encryptiing or signing certificate (for e-mail etc.). This is combined with an auto-lock that locks a users workstation as soon as they token is removed. Clue this to the building entry card and you force users also to lock the WS if they are not attended (one of the thorns in my sore eyes). Of course there are also systems out there that combine USB tokens and OTP in one device, but if you have USB ports only on the back of the machine this becomes a bit of a hassle, even though it would probably be fun to watch users trying to enter the OTP, but Health & Safety would kick us if we have every user complaining about a pain in the neck (in every tru meaning of the word).

Many times it's also based on the fact that developers try to sell their lousy products as THE security solution for all problems (come on we all know the marketing talk of self protecting networks etc.). Again 2-factor authentication is only one little part of an overall security program, but it can never be the solution to all security problems. Same with ID Cards and biometrics.... Governments try to sell these as THE solution against ID Theft etc. however the Dutch system is already half way cracked as data can be freely read from up to 10 meters distance and it is only a question of time until it can also be freely written. And then we have governments that try to sell biometric ID cards but still allowing that somebody can say Joe Blogs when asked by police for the name instead of making the usage of false ID Data plain illegal. So it happened to me that somebody tried to get a credit card in my name (which was denied as the person did not have my secret password i implemented on my credit report). I went to the police just to hear that the plain attempt is not illegal and nothing can be done unless somebody nicked my money due to ID Theft.

Also please consider that Bruce said that 2-factor authentication is not the golden egg of security and not that 2-factor authentication is useless in all scenarios. I have to agree with Bruce that 2x auth is overhyped by banks etc. and is sold as the golden solution that will prevent all fraud simply by being implemented.

The same happens here with LloydsTSB who not too long ago changed from a simple password system (username/password) to a 3 step authentication that asks for a random pick of 3 characters of a predefined additional password. However now they allow that the username/ID can be saved on the browser (even if stating that it should not be done on PCs that are shared with multiple people, but how many people do ignore that.... over 80% as a wild guess), so effectively minimizing the entire system to a 2 step system again. Makes really sense and such nonsense should be illegal. Either I implement a 3-step authentication process or i don't.

Even if we would implement biometric IDs on such accounts it would not help to 100% prevent any potential for fraudulent transactions, even not if we combine this with additional 2-factor authentication and statistical Intrusion Analysis (i.e. user makes more typos than normal or deviates from the normal pattern of site usage, such as usual the pattern for the user is to first check the account balance, then detailed statement, then transactions). Just because a attack technology today is not feasable to be exploited does not mean that it is not easily exploitable tomorrow, MiM in encrypted sessions included, and as said the old Granny in the flat above will certainly simply click yes if i am able to conduct a MiM and to gain access to the private key or a certificate...... well enough trojans out there take nowadays already care of that, then combined with weak passwords and voila we have a security breach. 15 years ago nobody talked about MiM attacks, nobody talked about 2-factor auth to be honest (except geeks and nerds). And what does stop any attacker from brute forcing his way into a password protected certificate? In most cases a brute force will only take minutes as people of course use well known dictionary words.

The SMS solution is certainly nice and tricks any attacker that works plainly on remote attacks and relies on information transfered, but what if somebody gets hold of the mobile (or the 2-factor token)?

2-factor is certainly not the solution of all problems, but it can make life for an opportunistic attacker very difficult if not impossible. But no matter what solution we select the protection will never stop a real determined attacker with enough resources and criminal energy at hand, except where he meets his match on the white hat side. And even then there is still enough potential for a security breach. Is Internetbanking therefore unsafe to use (Internetbanking just as an example as it was used so often here)? It is not more insecure than if you go personally to your bank or if you use an ATM, I personally prefer the Internet than ATMs, at least i know 99.9% for sure that nobody can look over my shoulder unless they can install a camera in the right place to watch my monitor and keyboard (please note this is my preference and not a statement about what is more secure. The ATM can have a skimmer installed, my PC can have a keylogger installed. The ATM has in most cases enough oportunities to be monitored by hidden cameras that cannot be detected, my house doesn't offer this oportunity that easily and any attacker has it harder to hit me over the head and steal my card if i am in my flat).
And if somebody asks me what the best way to protect ones bank account i only remember at the times where one had to go to his/her branch to do anything. Staff at the bank knew each customer by name and if somebody would have tried to claim to be me they would have put a stop to it and called the cops. Is this nowadays still feasable in this fast paced world? No, of course not. We want globality and service availability around the clock This causes increased Risk, which can be mitigated by the use of 2-factor authentication, but once again it does not solve the problem, it only mitigates it.

And Bruce is also right with the comment about the ever changing face of security and threats. 10 years ago 2-factor authentication was better of an idea than sliced bread, but attacks have evolved and there are (even if many are theoretical for now) many ways around any authentication.
One example here is that users should not be allowed to install software, sure its fine and good and will prevent accidental user error, but if an attacker has physical access to a machine this is just a doddle to circumvent. On Unix simply boot into another OS and hack the passwd and shadow, on Windows use the Logon Bypass method to gain %SYSTEM%. And where this wouldn't help because of some fancy new technology simply replace the authentication API to accept any password and you are done.
Or how about Disk Encryption with pre-boot authentication? Nothing except time restraints will prevent an attacker from going down the route of brute forcing. And what user has a true 128 bit Entropy? No system does allow a permanent lockout after x amount of failed attempts (at least none that is commercially viable), but then it would also not be very userfriendly or feasable to use a lockout without any provisioning of an Escrow procedure (which in turn could be brute forced again).

Just my 2p on security and that there is no 100% secure system. Maybe its because of human nature that there can't be any 100% security. We seem to be somehow much better in finding ways around security than in creating security. You can watch a public place and cordon of a section that lies in the direct path between 2 points. It will take only minutes until people start to circumvent this security meassure. If we use tape it will happen faster, if we use temporary walls it is less likely. If you put up a 6" fence it is less likely that people will climb it, but then watch it during night time when the pubs close and you will get all sorts of drunks and jokers climbing over the fence. If you put a few Rottweiler (not fed for a week or so) into the fenced area you still wil get the occasional idiot climbing over the fence regardless of the danger.

And where technology doesn't help an attacker social engineering always does the trick. I claim that we run a good user education program with regards to password safety, and yet i just had two weeks ago a user with a problem and for troubleshooting i had to request a username and password for accessing a specific site. Instead of providing me with my own account the user simply sent me his details. After pointing (again) out that nobody must share their account details the answer i received was: I thought as you are the security manager and this is OK. My answer: Especially I as security manager should not get hold of any other account info. I know what I have to do in a non-trackable way to cause you a lot hassle in your life. All you will wonder about after being picked up by the police is what just happened there (and you will never understand). Then an explanation why this is legally not even an intrusion if the user shares willingly his password details (at least here in the UK it can't be seen as an intrusion and any court would kick the case out), and then suddenly a very white face. And despite all this i guarantee that this user next time around will gladly tell us his password again if asked. Will 2-factor auth ever prevent this users stupidity? Never. Just call him and ask him for his PIN and the current displayed passcode.

This just as an example on how easy it is.

I think Bruce only wanted to point out the fact that 2-factor auth is hyped over the odds as solution for everything and that it will be THE solution to prevent all future security threats. It is not, never will be, never can be.

http://www.dsssasia.com/htmdocs/company/...

Will appreciate comments. Thx.

My Bank is using PIN/TAN longer than they are using SSL (I used to use dial in and telnet sessions in the early 90s).

Since last year they offer authentication via smart card and they try to push it by subsidizing the reader (they recommend amongst others
http://www.reiner-sct.de/produkte/e-com.php ).

I would feel fully confident to use it,

- Something I have (the smart card AND the certified reader)
- Something I know (the PIN)
- Something to verify what I am doing (the display on the reader)

BUT there is a trade off which keeps me from switching:

As the the system is soooo secure, I will have problems to shown that I HAVE NOT done the transaction in question, so it is safer for me to use the weaker system (provided I follow the terms and conditions).
I have as risk a reasonable fee (the costs of the rollback and the retention the insurance imposes) for the hint that my computer got hacked.

For years, I've been quietly observing and sometimes commenting (by way of casual conversation) on the changing face of technology and the progress of Information Security and the computing industry (or lack thereof.)

This is a great discussion because it invites opinions from all sides of the spectrum. Some more fierce than others.

Man-in-the-middle (MiM or MITM) attacks, while achievable, present more of a technical challenge to the would-be criminal. This is why trojan horses and security exploit tools have become the method of choice for compromising a system over the 'net. Exploitations have become so pervasive, that it's turned into a daily cat and mouse game to keep your system secure.

While there are a myriad of opinions regarding which authentication method is best suited for the task, I believe that the answer lies in combining the strengths of existing technologies in order to come up with a viable and relatively (and I stress relatively) fool-proof solution. Since financial institutions are governed by the "Safeguards Rule" implemented by the FTC, among a host of others, their systems have to adhere to strict guidelines regarding information security. That doesn't mean they are completely immune, but at least there is a dedicated staff to address security issues at a moment's notice.

With that being said, I believe the four keys to online transaction security consist of:

* Secure infrastructure on the financial institution's side or online retailer
(Side note: Internal security incidents are on the rise and need to be addressed soon!)

* Strong cryptographic cipher to curtail eavesdropping

* Feasible and not-so-cumbersome authentication method (Note: A key ring full of fobs is not practical)

* Secure interface on the client side

The latter of course being the biggest problem. In scrambling to implement stronger security, companies are pouring large capital assets into information security, much of which is past onto the consumer by way of higher fees and such.

To address the last issue on the list, I suggest that financial institutions and online retailers get together and develop a standalone bootable CD (Mac/PC friendly of course) using an agreed upon distribution of Linux. In doing so, the loop of security will be completed and safer transactions can take place. Granted, everything works great in theory but I think this would be a step in the right direction. Throw in the likes of a PIN/TAN system, and things would be pretty secure. IMHO of course!

Before people start bouncing off the walls, I am not a Linux evangelist. While I rarely use it, I have conducted quite a bit of research on it and commend the open source community for its efforts. The use of Linux is preferable because there are no licensing restrictions and the source code will be open to the general public for scrutiny. This solution would not be mandatory as the CD would merely provide a sanitized environment, and therefore be geared towards the average consumer. Since bootable "Live" CD's do not affect the software installed on the user's machine, it should be clearly stated on the label so consumers won't think their data will be deleted by its use.

Distribution of such CD's would have to be thought out carefully in order to prevent criminals from cloning the media and pawning it off as official. Social engineers would be hard at work trying to lure people in so consumer beware!

To tie it in with the article: The two-factor authentication method provides for added security, but isn't the elusive "Silver Bullet", which I think is the point of the article. Upon reading through the comments, it is obvious that some users are taking the conclusion with a grain of salt and cast it off as a synical view of the industry. I don't share that opinion and applaud the efforts of security advocates that aim to shed light on the true state of information security.

Best of luck to us all!

To the issue of scope: What are the relative frequencies of Man-in-the-Middle and Trojan attacks? How difficult is it to effectively mount such an attack? (Schneier implies that a high degree of skill would be required to successfully mirror the look and functionality of the spammed site; which, in turn, suggests a lower threat level.) The current argument has an alarmist tone because it fails to effectively scope the problem.

To the issue of a solution path, simply, So what? Every security measure has one or more counter measures. The purpose of security is not to make it impossible to break into something, but to limit the players capable of such a break-in. Does two-factor communication effectively limit the field of potential hackers? A guru should ask questions that make you think, and, critically, provide a degree of insight. Where's the insight?

Postbank in the Netherlands has implemented a slightly different twist on the SMS scheme as an authentication form. SMS authentication is not required for logging in, but is required for confirming transactions.

A user defines one or more transactions, and when he is ready to send them he is asked for a confirmation code that is send to him as an SMS.
The SMS text contains a sequence number, the total amount to be transfered and the authentication code, this information is also displayed on the web site where the code is to be filled in.

This means gaining access to the site by the two means mentioned is not enough to illegaly perform transactions and (assuming the user checks the amount and the sequence number) hitchhiking on other transactions is not possible.

Except it isn't workable.

Because people will be issued with a plethora of fobs to carry around which will become extremely inconvenient. I currently have 3 SecurID tokens and they are bulky to carry in a pocket. Users will NOT want to have to carry a fob for every service they want to use - they will return to less secure but more practical passwords.

One solution would be for a single fob to be registered to an individual and then used for authenticating against any number of services / companies... I haven't made any assessment of the sharing of fob registration details between companies - is there a risk here? Or is there an impact on the fob vendor's bottom line by selling only one fob rather than n to each individual and so this solution isn't actively proposed.

For example, Vasco has a product which allows the user to enter data specific to a transaction which is combined with the OTP to create a hash for the transaction. A man-in-the-middle attack in this case would be confined to observation rather than using the OTP to authorise a different transaction from the one the user intended. Also, the phone-based second factor you mentioned in your article could be made to work if the message sent to the user displays the transaction that is being authorised along with a confirmation code. In this case, if an attacker had substituted a different transaction then the user would find out about it and would not send in the confirmation code - the attacker could not do it because they never get to see it (assuming the phone link is secure...). The real problem in this case is that SMS messaging is unreliable, so this type of scheme have never really got out of the pilot phase as far as I know.

Of course the complete solution is to use a client-authenticated SSL session instead of wasting time with tokens as this prevents a man in the middle from even getting in at the authentication stage. The costs of issuing and managing user certificates in a managed PKI solution are comparable to issuing OTP tokens.

http://www.guardian.co.uk/crime/article/...

"Police have foiled an audacious attempt to steal �220m from the London offices of a Japanese banking group, it emerged today."

Nothing is said about how Police detected the attack, but apparently keyloggers and small fund transfers were picked up as anomalous, and the small transfers led to arrests. The article goes on to say:

"'The rise of keyloggers poses a real threat to companies and this may be the first time we have evidence of organised criminals using the equipment to attack a bank,' Alan MacDonagh, managing director of the fraud consultancy Hibis Europe told the Financial Times."

What is the evidence for this claim? Do you know of several such "active attacks", and how successful have they been? Again, I would like to see more facts and less speculation. I am not convinced that those real-time attacks are so feasible in practice, at least not without provoking suspicion (aborted transactions etc.)

I'm also not convinced that an attacker only has to fool the most stupid internet users. In Germany, the last wave of phishing and keylogging attacks wasn't successful because the fraudulent transactions were detected early. At least this is what the banks are saying, which you may chose to believe or not.

You say: "The operating system is just running a program the user put there"

and I continue: "or let itself in through a vulnerability and grabed a feature (like hooking the keyboard)". And please, let's not talk about common users doing maintenance. It just isn't real. Either the system is selfhealing or, at least, we have to make [the core of] it as stateless as possible. (and one last point: let's try to keep the core and the apps as simple as we can; there are some features that shouldn't be there in the first place, e.g. Browser Helper Objects ?!? Come on...)

You say: (regarding sigs) "..._nothing_ will help against a Trojan attack..."

I say: "...unless the Trojan doesn't control the sig mechanism AND the user action doesn't depend on some data from the Bank" I do concede that the last condition MAY be the killer. And I'm thinking in a scenario where the Trojan might induce the user to sign something that wasn't really necessary and the user falling for it (even though the users might be aware that, say, they should only have to sign the ... whatever). But when we get to this point we're already performing without net.

One last thought: I truly think we should be putting more money on awareness. Big players have tried for years to keep the down side away from the news (to gather customers) but I think the time has come to educate people on the Do's and Dont's in an open way. In the end, it's always on their side.

(and this has been a kool discussion ;)

-- M

In the end I think it comes back to the stance that Bruce is taking wrt two factor authentication. Which as I understand it, is that in the face of the specific attacks he mentions, active Man-in-the-Middle attacks (works by user not verifying server) and active Trojan attacks (works by user installing bad code), two factor authentication doesn't provide a lot of additional value. With this I would have to agree.

He also proposes that in general, attacks are moving from passive (time shifted) methods to active (real time) methods, which is what makes them especially effective against two factor authentication. Again I would have to agree.

However, one has to take into consideration the "work factor" of moving from passive attacks to active attacks. I think that two factor authentication is a great technology that will overall increase security by "raising the bar", forcing the attacks to get much more sophisticated (which will tend to filter out all but the most determined attackers).

@M
You ask "...execution of a Trojan, wouldn't that be a flaw within the operating system?"
And the answer is: Yes, it is.

Not really. The operating system is just running a program the user put there. It generally doesn't know "good" programs from "bad" programs. In fact, most OS's, including Windows, provide users protection from installing programs unintentionally. For most activities, especially Internet oriented, users should never be logged in as a user with admin level privileges, but many (most) do. Why? Because many programs will not run properly unless the user is running with admin level privileges. This is not really a Microsoft OS problem, but a problem with the developers of these programs (what I call LPS, or Lazy Programmer Syndrome). Most programs that today require users to have admin level privileges, don't really require admin level privileges to run, but due to LPS, they were written that way, which is just another part of the whole security problem.

@M
Regarding having the client digitally sign some part of the transaction, I agree that this can help with a Man-in-the-Middle attack (assuming the transaction isn't setup such that the server sends data to be signed to the client), but _nothing_ will help against a Trojan attack (where the Trojan can change the data to be signed without the user knowing it, could replace the user's digital signature software, in part or in whole, completely replace the browser app, or whatever).

What you are suggesting is exactly what ABN-Amro in holland is using. I think it is fool proof with regards that nobody can wire money to an account that I have not given authorisation for. Viewing my private information like saldo etc. is a different Story.

In my opinion, with the current technology one can make hack resistant systems but not totally secured systems. This means security process to be out sourced to competent and capable agencies. Who can make some 'look ahead' procedure to counter the attack.

Next, offering security per secession is the better process to be followed.
On the other hand let us also see the 'multiple factors' that are in hand like Web, Wi, Wi Max, Mobile and PoT, allow customer to 'pick two factors' out this while using their known TWO FACTORS too.

May be use of SSL with strong key management process under enterprise or banks control will offer better non repudiation control.

May be one should follow old �Churchill's� policy of not using same path to commute twice in the near vicinity. This means security system need append the multiple choses !!!!

Simple to use but multiple system is better than strong single system.

Any comments on my two cents!!!