I had an article published, this time over as SearchSecurity. Attacks illustrate need for stronger authentication.

It is more on the need for mutual and transaction authentication in addition to session authentication for financial service web applications. I think this will be particularly true for brokerage applications where the infrequency of transactions make them hard to audit and the high dollars involved make them attractive targets.

Let me know what you think!

Lance James at Secure Science has screen shots of the phish attack against CitiBank's business site that uses a hardware token one-time password system. You can see them on WaPo's Security Fix Blog.

Before everyone gets all up in arms about this in the blogosphere. Let's talk about authentication types:

Session Authentication - authenticating the user to the host to create a session
• Mutual Authentication - The host is authenticated to the user, as well as vice-versa
• Transaction Authentication - A transaction is authenticated in a manner cryptographically distinct from the session authentication mechanism

Much has been written about how SSL isn't effective against MITM attacks because nobody actually verifies the SSL certificate (this is way WiKID's mutual authentication method checks the cert for the user before showing the OTP).

Transaction authentication could be done via transaction analysis as it is for credit cards, but, while that might be effective for consumer accounts with regular payments, commercial and brokerage accounts would be much tougher. I don't think we need "digital signing", in a strict sense of the term, but I do think you need something that is distinct from the session authentication method or the attacker will fake a session time-out to get the user to give them another passcode. WiKID's ability to handle multiple 'domains' with separate public/private key pairs provides a cryptographically distinct method that uses the same token client.

As I predicted, the hysteria around the , well, hysteria in the information security blogosphere, which is a pretty small part of the blogosphere.

As I discussed before, this is a failure of mutual authentication not two-factor authentication. Here are some the headlines:

• Fraudsters defeat two-factor authentication
• Phishers rip into two-factor authentication
Phishers crack two-factor authentication

On the other hand, and sadly in the minority, zencoder has it right: Pundits Blaming 2-Factor Authentication…Again

you can’t use 2-factor authentication to protect a telnet session and expect it to be valid hosts guaranteed on both ends…telnet doesn’t have that sort of capability built into the protocol; but that’s not a problem with the 2-factor auth.

Security Curve, is also on the right track transaction authentication to make financial services acceptably secure online.

I think we do as much of a disservice to the Internet community when we inaccurately blame technology as when we inaccurately promote it as a silver bullet.

The SEC has noticed a dramatic rise in fraud against online brokerage accounts. This is a very interesting article in that it shows how an attacker can take over accounts and make money without necessarily removing money from those accounts. All they need is a couple of "legitimate" account that the fraudsters open, a thinly traded small-cap stock and to control a couple of pwned accounts with enough money to manipulate the targeted stock. The article describes "pumping" as using pwned accounts to drive up the price of stocks that you hold. However, you can also make money on the way down:

• First, open the two online brokerage accounts. In Account A purchase the targeted stock. You will have to do it in such a way that the stock price doesn't rise. In Account B, do nothing for now.
• Second, use your nefarious means to gain control of some accounts. Sell all their existing holdings and start buying shares in the targeted company.
• As the stock price rises, sell all your shares in Account A, probably to the poor guy in the pwned account.
• After you sell all the stock in Account A at high prices, start short-selling in Account B. You will need to pay attention to the short-selling rules for the exchange. For example, on the NYSE you can only short-sell a stock on an up tick.
• Dump all the stock in the pwned account as quickly as possible
• Clear out your short positions in Account B.
• Start laundering your profits.

There are a number of interesting points:

• One, it is harder to track because of the number of accounts used. The attacker also now has three or more different accounts probably at different brokerages with money for laundering, so it is more likely that they will successfully get cash.
• The fraudster can make money as the stock rises and falls.
• It is yet another reason for a small cap stock to not be a public company. The main reason being meeting regulatory requirements.

As a side note, this confirms one of my predictions for 2006 which is good, because it doesn't look like any of the others will come to pass any time soon. It also points to the need for improved transaction authentication.

The Washington Post has an article today about the the increase in online brokerage fraud.

E-Trade Financial Corp., the nation's fourth-largest online broker, said last week that "concerted rings" in Eastern Europe and Thailand caused their customers $18 million in losses in the third quarter alone.

Kurt at anti-virus rants has a pair of posts, one on what is man-in-the-middle attack and a follow up on why tokens won't stop phishing, which lead me to an earlier post on why safe site indicators fail.

My comments:

• If the one-time passcodes are used to authentication transactions instead of sessions, they would stop phishing. Though it would be best to have both session and transaction authentication, especially for accounts that are difficult to analyze for fraudulent transactions such as commercial and brokerage accounts.
• Good host authentication will probably require software on the client side, but banks are very reluctant to distribute software. This gives an edge to the bad guys who have no problem with distributing software whatsoever.

Passwords have been around forever and it's starting to show. The next level of authentication security is two-factor authentication. Your ATM card is an example of two-factor authentication: you need both possession of the card and knowledge of the PIN to get cash. There are a number of factors that are pushing two-factor authentication toward a tipping point.

• Compliance - Increasingly companies are deploying two-factor authentication because they are forced to. The credit card companies are requiring merchants and payment processors to meet the PCI Data Security requirements, which require two-factor for remote access to their networks. Banks are subject FFIEC guidelines which are promoting two-factor authentication.
• Risks are increasing - Hackers are now coin-operated - the do it for the money. And there are many ways for them to make money with stolen information with very little risk of being arrested. Hackers are targeting corporations in very targeted, hard-to-stop ways. Defense in depth will be required and two-factor authentication will be used for employee remote access and also inside the firewall for key systems and admin accounts.
• Ease of use - There are more two-factor solutions today. Some run on USB drives, some on cell phones and Blackberries, some on PCs. We even have a Firefox extension. These options are more convenient than tokens and in some cases, more convenient than passwords.
• Cheaper - All these options are driving prices down, making two-factor authentication less expensive than passwords - because resetting passwords costs money too. WiKID provides both a commercial version and an open source version.
• Password overload - People have more and more accounts on-line and more and more passwords. They either re-use passwords, use simple, breakable password or forget them.
• Private Personal Information - It's everywhere. If you have an HR database you have information that is valuable to hackers. They can be on the other side of the world and sell personal information on the Internet.
• Single Sign-On - There are a number of great single sign-on projects today (InfoCards, OpenID, Higgins,etc) These tools promise to reduce the number of accounts and passwords you have. At the same they put a lot of eggs in one basket and you need to protect that basket.
• SaaS - Software as a Service is exploding thanks to web-based apps like Salesforce.com, Google Apps for your Domain, Amazon Web Services and all the great web 2.0 applications. The weakest link in the security of these applications is the passwords. It is far simpler to steal a user's password than try to break into the server or decrypt the SSL tunnel.
• Increasing value of intangible items - The Internet has created new intangible items that have value: your eBay reputation or virtual money in Second Life for example. Access to these items is totally based on your credentials and you will want to protect them as there have already been examples of Stealing real identities to steal virtual items to sell for real cash

On the otherhand, there are some of the reasons you might not see true two-factor authentication in the near future:

• The secret second factor - Cookies, flash objects, IP addresses and MAC addresses can be used surreptitiously to attempt to validate a computer or browser. However, these are easily spoofed or actively deleted by the user. If you are a regular cookie deleter or have privacy software that deletes them for you, you might find that you get asked additional "security questions".
• More of 1 Factor authentication - You might see more of one factor instead of two factors. The best example of this is the "security questions" referred to above. Have more of one factor does not make it two factor. Two different factors are required because the attack complexity increases.
• Misguided expectations for two-factor authentication - Deploying it won't solve all your problems. Moreover, some financial institutions are deploying in a sub-optimal way. For example, some banks are using tokens for session authentication which, without mutual authentication, is still vulnerable to Man-in-the-Middle attacks or browser vulnerabilities. This could cause a backlash against two-factor. They should use the one-time passwords to validate transactions rather than the sessions. After all they are trying to stop fraudulent transactions.

What did I miss?

I forgot to mention that I have an article up on SearchSoftwareQuality: Stronger authentication needed for Web applications. Here's the gist:

In this article we consider three authentication processes in a typical complex Web application that requires security, such as online banking or brokerage transactions:

• Session authentication -- validating the user to the site
• Mutual or host authentication -- adding validation of the site to the user
• Transaction authentication -- validating that the correct user is requesting the transaction