banking Archives - Page 9 of 19 - Schneier on Security

Entries Tagged "banking"

Page 9 of 19

Man-in-the-Middle Attack Against Chip and PIN

Nice attack against the EMV—Eurocard Mastercard Visa—the “chip and PIN” credit card payment system. The attack allows a criminal to use a stolen card without knowing the PIN.

The flaw is that when you put a card into a terminal, a negotiation takes place about how the cardholder should be authenticated: using a PIN, using a signature or not at all. This particular subprotocol is not authenticated, so you can trick the card into thinking it’s doing a chip-and-signature transaction while the terminal thinks it’s chip-and-PIN. The upshot is that you can buy stuff using a stolen card and a PIN of 0000 (or anything you want). We did so, on camera, using various journalists’ cards. The transactions went through fine and the receipts say “Verified by PIN”.

[…]

So what went wrong? In essence, there is a gaping hole in the specifications which together create the “Chip and PIN” system. These specs consist of the EMV protocol framework, the card scheme individual rules (Visa, MasterCard standards), the national payment association rules (UK Payments Association aka APACS, in the UK), and documents produced by each individual issuer describing their own customisations of the scheme. Each spec defines security criteria, tweaks options and sets rules—but none take responsibility for listing what back-end checks are needed. As a result, hundreds of issuers independently get it wrong, and gain false assurance that all bases are covered from the common specifications. The EMV specification stack is broken, and needs fixing.

Read Ross Anderson’s entire blog post for both details and context. Here’s the paper, the press release, and a FAQ. And one news article.

This is big. There are about a gazillion of these in circulation.

EDITED TO ADD (2/12): BBC video of the attack in action.

Posted on February 11, 2010 at 4:18 PM • View Comments

Online Credit/Debit Card Security Failure

Ross Anderson reports:

Online transactions with credit cards or debit cards are increasingly verified using the 3D Secure system, which is branded as “Verified by VISA” and “MasterCard SecureCode”. This is now the most widely-used single sign-on scheme ever, with over 200 million cardholders registered. It’s getting hard to shop online without being forced to use it.

In a paper I’m presenting today at Financial Cryptography, Steven Murdoch and I analyse 3D Secure. From the engineering point of view, it does just about everything wrong, and it’s becoming a fat target for phishing. So why did it succeed in the marketplace?

Quite simply, it has strong incentives for adoption. Merchants who use it push liability for fraud back to banks, who in turn push it on to cardholders. Properly designed single sign-on systems, like OpenID and InfoCard, can’t offer anything like this. So this is yet another case where security economics trumps security engineering, but in a predatory way that leaves cardholders less secure. We conclude with a suggestion on what bank regulators might do to fix the problem.

Posted on February 1, 2010 at 6:26 AM • View Comments

MagnePrint Technology for Credit/Debit Cards

This seems like a solution in search of a problem:

MagTek discovered that no two magnetic strips are identical. This is due to the manufacturing process. Similar to DNA, the structure of every magnetic stripe is different and the differences are distinguishable.

Knowing that, MagTek pairs the card’s magnetic strip signature with the card user’s personal data to create a one-of-a-kind digital identifier. MagTek calls this technology MagnePrint.

Basically, each card gets a “fingerprint” of the magnetic strip printed on it. And the reader (merchant terminal, ATM, whatever) verifies not only the card information, but the fingerprint as well. So a thief can’t skim your card information and make another card.

I see a couple of issues here. One, any fraud solution that requires the credit card companies to issue new readers simply isn’t going to happen in the U.S. If it were, we’d have embedded chips in our credit cards already. Trying to convince the merchants to type additional data in by hand isn’t going to work, either. We finally got merchants to type in a 3–4 digit CVV code—that basically does the same thing as this idea (albeit with less security).

Two, physically cloning cards is much less of a threat than virtually cloning them: buying things over the phone and Internet, etc. Yes, there are losses here, but I’m sure they’re not great enough to justify all of this infrastructure change.

Still, a clever security idea. I expect there’s an application for this somewhere.

Posted on December 18, 2009 at 6:32 AM • View Comments

Malware that Forges Bank Statements

This is brilliant:

The sophisticated hack uses a Trojan horse program installed on the victim’s machine that alters html coding before it’s displayed in the user’s browser, to either erase evidence of a money transfer transaction entirely from a bank statement, or alter the amount of money transfers and balances.

Another article.

If there’s a moral here, it’s that banks can’t rely on the customer to detect fraud. But we already knew that.

Posted on October 6, 2009 at 6:40 AM • View Comments

Nice Use of Diversion During a Robbery

During a daring bank robbery in Sweden that involved a helicopter, the criminals disabled a police helicopter by placing a package with the word “bomb” near the helicopter hangar, thus engaging the full caution/evacuation procedure while they escaped.

I wrote about this exact sort of thing in Beyond Fear.

EDITED TO ADD (10/13): The attack was successfully carried off even though the Swedish police had been warned.

Posted on October 1, 2009 at 7:01 AM • View 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 AM • View 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.

Stealing 130 Million Credit Card Numbers

Someone has been charged with stealing 130 million credit card numbers.

Yes, it’s a lot, but that’s the sort of quantities credit card numbers come in. They come by the millions, in large database files. Even if you only want ten, you have to steal millions. I’m sure every one of us has a credit card in our wallet whose number has been stolen. It’ll probably never be used for fraudulent purposes, but it’s in some stolen database somewhere.

Years ago, when giving advice on how to avoid identity theft, I would tell people to shred their trash. Today, that advice is completely obsolete. No one steals credit card numbers one by one out of the trash when they can be stolen by the millions from merchant databases.

Posted on August 27, 2009 at 7:02 AM • View Comments

Small Business Identity Theft and Fraud

The sorts of crimes we’ve been seeing perpetrated against individuals are starting to be perpetrated against small businesses:

In July, a school district near Pittsburgh sued to recover $700,000 taken from it. In May, a Texas company was robbed of $1.2 million. An electronics testing firm in Baton Rouge, La., said it was bilked of nearly $100,000.

In many cases, the advisory warned, the scammers infiltrate companies in a similar fashion: They send a targeted e-mail to the company’s controller or treasurer, a message that contains either a virus-laden attachment or a link that—when opened—surreptitiously installs malicious software designed to steal passwords. Armed with those credentials, the crooks then initiate a series of wire transfers, usually in increments of less than $10,000 to avoid banks’ anti-money-laundering reporting requirements.

The alert states that these scams typically rely on help from “money mules”—willing or unwitting individuals in the United States—often hired by the criminals via popular Internet job boards. Once enlisted, the mules are instructed to set up bank accounts, withdraw the fraudulent deposits and then wire the money to fraudsters, the majority of which are in Eastern Europe, according to the advisory.

This has the potential to grow into a very big problem. Even worse:

Businesses do not enjoy the same legal protections as consumers when banking online. Consumers typically have up to 60 days from the receipt of a monthly statement to dispute any unauthorized charges.

In contrast, companies that bank online are regulated under the Uniform Commercial Code, which holds that commercial banking customers have roughly two business days to spot and dispute unauthorized activity if they want to hold out any hope of recovering unauthorized transfers from their accounts.

And, of course, the security externality means that the banks care much less:

“The banks spend a lot of money on protecting consumer customers because they owe money if the consumer loses money,” Litan said. “But the banks don’t spend the same resources on the corporate accounts because they don’t have to refund the corporate losses.”

Posted on August 26, 2009 at 5:46 AM • View Comments

Swiss Security Problem: Storing Gold

Seems like the Swiss may be running out of secure gold storage. If this is true, it’s a real security issue. You can’t just store the stuff behind normal locks. Building secure gold storage takes time and money.

I am reminded of a related problem the EU had during the transition to the euro: where to store all the bills and coins before the switchover date. There wasn’t enough vault space in banks, because the vast majority of currency is in circulation. It’s a similar problem, although the EU banks could solve theirs with lots of guards, because it was only a temporary problem.

Posted on July 28, 2009 at 7:13 AM • View Comments

←Previous 1 … 7 8 9 10 11 … 19 Next→

Sidebar photo of Bruce Schneier by Joe MacInnis.