Entries Tagged "two-factor authentication"

Page 3 of 5

Here's How Brazilian Crooks Steal Billions

Man-in-the-middle attack against a Brazilian payment system:

Brazil has an extremely active and talented cybercrime underground, and increasingly Brazilian organized crime gangs are setting their sights on boleto users who bank online. This is typically done through malware that lies in wait until the user of the hacked PC visits their bank’s site and fills out the account information for the recipient of a boleto transaction. In this scenario, the unwitting victim submits the transfer for payment and the malware modifies the request by substituting a recipient account that the attackers control.

This is the sort of attack that bypasses any two-factor authentication system, since it occurs after all authentication has happened. A defense would be to send a confirmation notice to another device the account-owner owns, confirming the details of the transaction.

Posted on July 9, 2014 at 7:30 AMView Comments

Twitter's Two-Factor Authentication System

Twitter just rolled out a pretty nice two-factor authentication system using your smart phone as the second factor:

The new two-factor system works like this. A user enrolls using the mobile app, which generates a 2048-bit RSA keypair. The private key lives on the phone itself, and the public key is uploaded to Twitter’s server.

When Twitter receives a new login request with a username and password, the server sends a challenge based on a 190-bit, 32 character random nonce, to the mobile app—along with a notification that gives the user the time, location, and browser information associated with the login request. The user can then opt to approve or deny this login request. If approved, the app replies to a challenge with its private key, relays that information back to the server. The server compares that challenge with a request ID, and if it authenticates, the user is automatically logged in.

On the user end, this means there’s no string of numbers to enter, nor do you have to swap to a third party authentication app or carrier. You just use the Twitter client itself. It means that the system isn’t vulnerable to a compromised SMS delivery channel, and moreover, it’s easy.

Posted on August 8, 2013 at 12:20 PMView Comments

Bypassing Two-Factor Authentication

Yet another way two-factor authentication has been bypassed:

For a user to fall prey to Eurograbber, he or she must first be using a computer infected with the trojan. This was typically done by luring the user onto a malicious web page via a round of unfortunate web surfing or email phishing attempts. Once infected, the trojan would monitor that computer’s web browser for banking sessions. When a user visited a banking site, Eurograbber would inject JavaScript and HTML markup into their browser, prompting the user for their phone number under the guise of a “banking software security upgrade”. This is also the key to Eurograbber’s ability to bypass two-factor authentication.

It’s amazing that I wrote about this almost eight years ago. Here’s another example of the same sort of failure.

Posted on December 10, 2012 at 1:04 PMView Comments

Man-in-the-Middle Bank Fraud Attack

This sort of attack will become more common as banks require two-factor authentication:

Tatanga checks the user account details including the number of accounts, supported currency, balance/limit details. It then chooses the account from which it could steal the highest amount.

Next, it initiates a transfer.

At this point Tatanga uses a Web Inject to trick the user into believing that the bank is performing a chipTAN test. The fake instructions request that the user generate a TAN for the purpose of this “test” and enter the TAN.

Note that the attack relies on tricking the user, which isn’t very hard.

Posted on September 14, 2012 at 11:23 AMView Comments

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

Sidebar photo of Bruce Schneier by Joe MacInnis.