Entries Tagged "two-factor authentication"

Page 3 of 4

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.

Posted on February 6, 2012 at 1:23 PMView Comments

RSA Security, Inc Hacked

The company, not the algorithm. Here’s the corporate spin.

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

Here are news articles. The worry is that source code to the company’s SecurID two-factor authentication product was stolen, which would possibly allow hackers to reverse-engineer or otherwise break the system. It’s hard to make any assessments about whether this is possible or likely without knowing 1) how SecurID’s cryptography works, and 2) exactly what was stolen from the company’s servers. We do not know either, and the corporate spin is as short on details as it is long on reassurances.

RSA Data Security, Inc. is probably pretty screwed if SecurID is compromised. Those hardware tokens have no upgrade path, and would have to be replaced. How many of the company’s customers will replace them with competitors’ tokens. Probably a bunch. Hence, it’s in RSA’s best interest for their customers to forget this incident as quickly as possible.

There seems to be two likely scenarios if the attackers have compromised SecurID. One, they are a sophisticated organization who wants the information for a specific purpose. The attackers actually are on RSA’s side in the public-relations spin, and we’re unlikely to see widespread use of this information. Or two, they stole the stuff for conventional criminal purposes and will sell it. In that case, we’re likely to know pretty quickly.

Again, without detailed information — or at least an impartial assessment — it’s impossible to make any recommendations. Security is all about trust, and when trust is lost there is no security. User’s of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers’ trust.

Posted on March 21, 2011 at 6:52 AMView Comments

Eliminating Externalities in Financial Security

This is a good thing:

An Illinois district court has allowed a couple to sue their bank on the novel grounds that it may have failed to sufficiently secure their account, after an unidentified hacker obtained a $26,500 loan on the account using the customers’ user name and password.

[…]

In February 2007, someone with a different IP address than the couple gained access to Marsha Shames-Yeakel’s online banking account using her user name and password and initiated an electronic transfer of $26,500 from the couple’s home equity line of credit to her business account. The money was then transferred through a bank in Hawaii to a bank in Austria.

The Austrian bank refused to return the money, and Citizens Financial insisted that the couple be liable for the funds and began billing them for it. When they refused to pay, the bank reported them as delinquent to the national credit reporting agencies and threatened to foreclose on their home.

The couple sued the bank, claiming violations of the Electronic Funds Transfer Act and the Fair Credit Reporting Act, claiming, among other things, that the bank reported them as delinquent to credit reporting agencies without telling the agencies that the debt in question was under dispute and was the result of a third-party theft. The couple wrote 19 letters disputing the debt, but began making monthly payments to the bank for the stolen funds in late 2007 following the bank’s foreclosure threats.

In addition to these claims, the plaintiffs also accused the bank of negligence under state law.

According to the plaintiffs, the bank had a common law duty to protect their account information from identity theft and failed to maintain state-of-the-art security standards. Specifically, the plaintiffs argued, the bank used only single-factor authentication for customers logging into its server (a user name and password) instead of multi-factor authentication, such as combining the user name and password with a token the customer possesses that authenticates the customer’s computer to the bank’s server or dynamically generates a single-use password for logging in.

As I’ve previously written, this is the only way to mitigate this kind of fraud:

Fraudulent transactions have nothing to do with the legitimate account holders. Criminals impersonate legitimate users to financial institutions. That means that any solution can’t involve the account holders. That leaves only one reasonable answer: financial institutions need to be liable for fraudulent transactions. They need to be liable for sending erroneous information to credit bureaus based on fraudulent transactions.

They can’t claim that the user must keep his password secure or his machine virus free. They can’t require the user to monitor his accounts for fraudulent activity, or his credit reports for fraudulently obtained credit cards. Those aren’t reasonable requirements for most users. The bank must be made responsible, regardless of what the user does.

If you think this won’t work, look at credit cards. Credit card companies are liable for all but the first $50 of fraudulent transactions. They’re not hurting for business; and they’re not drowning in fraud, either. They’ve developed and fielded an array of security technologies designed to detect and prevent fraudulent transactions. They’ve pushed most of the actual costs onto the merchants. And almost no security centers around trying to authenticate the cardholder.

It’s an important security principle: ensure that the person who has the ability to mitigate the risk is responsible for the risk. In this case, the account holders had nothing to do with the security of their account. They could not audit it. They could not improve it. The bank, on the other hand, has the ability to improve security and mitigate the risk, but because they pass the cost on to their customers, they have no incentive to do so. Litigation like this has the potential to fix the externality and improve security.

Posted on September 23, 2009 at 7:13 AMView Comments

Hacking Two-Factor Authentication

Back in 2005, I wrote about the failure of two-factor authentication to mitigate banking fraud:

Here are two new active attacks we’re starting to see:

  • Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.
  • Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

Here’s an example:

The theft happened despite Ferma’s use of a one-time password, a six-digit code issued by a small electronic device every 30 or 60 seconds. Online thieves have adapted to this additional security by creating special programs–real-time Trojan horses–that can issue transactions to a bank while the account holder is online, turning the one-time password into a weak link in the financial security chain. “I think it’s a broken model,” Ferrari says.

Of course it’s a broken model. We have to stop trying to authenticate the person; instead, we need to authenticate the transaction:

One way to think about this is that two-factor authentication solves security problems involving authentication. The current wave of attacks against financial systems are not exploiting vulnerabilities in the authentication system, so two-factor authentication doesn’t help.

Security is always an arms race, and you could argue that this situation is simply the cost of treading water. The problem with this reasoning is it ignores countermeasures that permanently reduce fraud. By concentrating on authenticating the individual rather than authenticating the transaction, banks are forced to defend against criminal tactics rather than the crime itself.

Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card’s existence isn’t even verified. The credit card companies spend their security dollar authenticating the transaction, not the cardholder.

More on mitigating identity theft.

Posted on September 22, 2009 at 6:39 AMView Comments

Credit Card with One-Time Password Generator

This is a nifty little device: a credit card with an onboard one-time password generator. The idea is that the user enters his PIN every time he makes an online purchase, and enters the one-time code on the screen into the webform. The article doesn’t say if the code is time-based or just sequence-based, but in either case the credit card company will be able to verify it remotely.

The idea is that this cuts down on card-not-present credit card fraud.

The efficacy of this countermeasure depends a lot on how much these new credit cards cost versus the amount of this type of fraud that happens, but in general it seems like a really good idea. Certainly better than that three-digit code printed on the back of cards these days.

According to the article, Visa will be testing this card in 2009 in the UK.

EDITED TO ADD (12/6): Several commenters point out that banks in the Netherlands have had a similar system for years.

Posted on December 4, 2008 at 6:17 AMView Comments

Bank Botches Two-Factor Authentication

From their press release:

The computer was protected by two layers of security, a unique user-identifier and a multiple-character, alpha-numeric password.

Um, hello? Having a username and a password — even if they’re both secret — does not count as two factors, two layers, or two of anything. You need to have two different authentication systems: a password and a biometric, a password and a token.

I wouldn’t trust the New Horizons Community Credit Union with my money.

Posted on April 13, 2007 at 7:33 AMView Comments

Fighting Fraudulent Transactions

Last March I wrote that two-factor authentication isn’t going to reduce financial fraud or identity theft, that all it will do is force the criminals to change their tactics:

Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses.

Here are two new active attacks we’re starting to see:

  • Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.
  • Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

The solution is not to better authenticate the person, but to authenticate the transaction. (Think credit cards. No one checks your signature. They really don’t care if you’re you. They maintain security by authenticating the transactions.)

Of course, no one listens to me. U.S. regulators required banks to implement two-factor authentication by the end of this year. But customers are rebelling, and banks are scrambling to figure out something — anything — else. And, amazingly enough and purely by accident it seems, they’ve stumbled on security solutions that actually work:

Instead, to comply with new banking regulations and stem phishing losses, banks and the vendors who serve them are hurriedly putting together multipronged strategies that they say amount to “strong” authentication. The emerging approach generally consists of somehow recognizing a customer’s computer, asking additional challenge questions for risky behavior and putting in place back-end fraud detection.

[…]

Despite the FFIEC guidance about authentication, the emerging technologies that actually seem to hold the most promise for protecting the funds in consumer banking accounts aren’t authentication systems at all. They’re back-end systems that monitor for suspicious behavior.

Some of these tools are rule-based: If a customer from Nebraska signs on from, say, Romania, the bank can determine that the log-on always be considered suspect. Others are based on a risk score: That log-on from Romania would add points to a risk score, and when the score reaches a certain threshold, the bank takes action.

Flagged transactions can get bumped to second-factor authentication — usually, a call on the telephone, something the user has. This has long been done manually in the credit card world. Just think about the last phone call you got from your credit card company’s fraud department when you (or someone else) tried to make a large purchase with your credit card in Europe. Some banks, including Washington Mutual, are in the process of automating out-of-band phone calls for risky online transactions.

Exactly. That’s how you do it.

EDITED TO ADD (12/6): Another example.

Posted on November 27, 2006 at 6:07 AMView Comments

Failure of Two-Factor Authentication

Here’s a report of phishers defeating two-factor authentication using a man-in-the-middle attack.

The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit — a tactic used by some security-savvy people — you might be fooled. That’s because this site acts as the “man in the middle” — it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.

I predicted this last year.

Posted on July 12, 2006 at 7:31 AMView Comments

Microsoft's BitLocker

BitLocker Drive Encryption is a new security feature in Windows Vista, designed to work with the Trusted Platform Module (TPM). Basically, it encrypts the C drive with a computer-generated key. In its basic mode, an attacker can still access the data on the drive by guessing the user’s password, but would not be able to get at the drive by booting the disk up using another operating system, or removing the drive and attaching it to another computer.

There are several modes for BitLocker. In the simplest mode, the TPM stores the key and the whole thing happens completely invisibly. The user does nothing differently, and notices nothing different.

The BitLocker key can also be stored on a USB drive. Here, the user has to insert the USB drive into the computer during boot. Then there’s a mode that uses a key stored in the TPM and a key stored on a USB drive. And finally, there’s a mode that uses a key stored in the TPM and a four-digit PIN that the user types into the computer. This happens early in the boot process, when there’s still ASCII text on the screen.

Note that if you configure BitLocker with a USB key or a PIN, password guessing doesn’t work. BitLocker doesn’t even let you get to a password screen to try.

For most people, basic mode is the best. People will keep their USB key in their computer bag with their laptop, so it won’t add much security. But if you can force users to attach it to their keychains — remember that you only need the key to boot the computer, not to operate the computer — and convince them to go through the trouble of sticking it in their computer every time they boot, then you’ll get a higher level of security.

There is a recovery key: optional but strongly encouraged. It is automatically generated by BitLocker, and it can be sent to some administrator or printed out and stored in some secure location. There are ways for an administrator to set group policy settings mandating this key.

There aren’t any back doors for the police, though.

You can get BitLocker to work in systems without a TPM, but it’s kludgy. You can only configure it for a USB key. And it only will work on some hardware: because BItLocker starts running before any device drivers are loaded, the BIOS must recognize USB drives in order for BitLocker to work.

Encryption particulars: The default data encryption algorithm is AES-128-CBC with an additional diffuser. The diffuser is designed to protect against ciphertext-manipulation attacks, and is independently keyed from AES-CBC so that it cannot damage the security you get from AES-CBC. Administrators can select the disk encryption algorithm through group policy. Choices are 128-bit AES-CBC plus the diffuser, 256-bit AES-CBC plus the diffuser, 128-bit AES-CBC, and 256-bit AES-CBC. (My advice: stick with the default.) The key management system uses 256-bit keys wherever possible. The only place where a 128-bit key limit is hard-coded is the recovery key, which is 48 digits (including checksums). It’s shorter because it has to be typed in manually; typing in 96 digits will piss off a lot of people — even if it is only for data recovery.

So, does this destroy dual-boot systems? Not really. If you have Vista running, then set up a dual boot system, Bitlocker will consider this sort of change to be an attack and refuse to run. But then you can use the recovery key to boot into Windows, then tell BitLocker to take the current configuration — with the dual boot code — as correct. After that, your dual boot system will work just fine, or so I’ve been told. You still won’t be able to share any files on your C drive between operating systems, but you will be able to share files on any other drive.

The problem is that it’s impossible to distinguish between a legitimate dual boot system and an attacker trying to use another OS — whether Linux or another instance of Vista — to get at the volume.

BitLocker is not a panacea. But it does mitigate a specific but significant risk: the risk of attackers getting at data on drives directly. It allows people to throw away or sell old drives without worry. It allows people to stop worrying about their drives getting lost or stolen. It stops a particular attack against data.

Right now BitLocker is only in the Ultimate and Enterprise editions of Vista. It’s a feature that is turned off by default. It is also Microsoft’s first TPM application. Presumably it will be enhanced in the future: allowing the encryption of other drives would be a good next step, for example.

EDITED TO ADD (5/3): BitLocker is not a DRM system. However, it is straightforward to turn it into a DRM system. Simply give programs the ability to require that files be stored only on BitLocker-enabled drives, and then only be transferrable to other BitLocker-enabled drives. How easy this would be to implement, and how hard it would be to subvert, depends on the details of the system.

Posted on May 2, 2006 at 6:54 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.