SSL and internet security news

twofactorauthentication

Auto Added by WPeMatico

On Security Tokens

Mark Risher of Google extols the virtues of security keys:

I’ll say it again for the people in the back: with Security Keys, instead of the *user* needing to verify the site, the *site* has to prove itself to the key. Good security these days is about human factors; we have to take the onus off of the user as much as we can.

Furthermore, this “proof” from the site to the key is only permitted over close physical proximity (like USB, NFC, or Bluetooth). Unless the phisher is in the same room as the victim, they can’t gain access to the second factor.

This is why I keep using words like “transformative,” “revolutionary,” and “lit” (not so much anymore): SKs basically shrink your threat model from “anyone anywhere in the world who knows your password” to “people in the room with you right now.” Huge!

Cory Doctorow makes a critical point, that the system is only as good as its backup system:

I agree, but there’s an important caveat. Security keys usually have fallback mechanisms — some way to attach a new key to your account for when you lose or destroy your old key. These mechanisms may also rely on security keys, but chances are that they don’t (and somewhere down the line, there’s probably a fallback mechanism that uses SMS, or Google Authenticator, or an email confirmation loop, or a password, or an administrator who can be sweet talked by a social engineer).

So while the insight that traditional 2FA is really “something you know and something else you know, albeit only very recently,” security keys are “Something you know and something you have, which someone else can have, if they know something you know.”

And just because there are vulnerabilities in cell phone-based two-factor authentication systems doesn’t mean that they are useless. They’re still much better than traditional password-only authentication systems.

Powered by WPeMatico

New Attack Against Electrum Bitcoin Wallets

This is clever:

How the attack works:

  • Attacker added tens of malicious servers to the Electrum wallet network.
  • Users of legitimate Electrum wallets initiate a Bitcoin transaction.
  • If the transaction reaches one of the malicious servers, these servers reply with an error message that urges users to download a wallet app update from a malicious website (GitHub repo).
  • User clicks the link and downloads the malicious update.
  • When the user opens the malicious Electrum wallet, the app asks the user for a two-factor authentication (2FA) code. This is a red flag, as these 2FA codes are only requested before sending funds, and not at wallet startup.
  • The malicious Electrum wallet uses the 2FA code to steal the user’s funds and transfer them to the attacker’s Bitcoin addresses.

The problem here is that Electrum servers are allowed to trigger popups with custom text inside users’ wallets.

Powered by WPeMatico

Real-Time Attacks Against Two-Factor Authentication

Attackers are targeting two-factor authentication systems:

Attackers working on behalf of the Iranian government collected detailed information on targets and used that knowledge to write spear-phishing emails that were tailored to the targets’ level of operational security, researchers with security firm Certfa Lab said in a blog post. The emails contained a hidden image that alerted the attackers in real time when targets viewed the messages. When targets entered passwords into a fake Gmail or Yahoo security page, the attackers would almost simultaneously enter the credentials into a real login page. In the event targets’ accounts were protected by 2fa, the attackers redirected targets to a new page that requested a one-time password.

This isn’t new. I wrote about this exact attack in 2005 and 2009.

Powered by WPeMatico

Google Employees Use a Physical Token as Their Second Authentication Factor

Krebs on Security is reporting that all 85,000 Google employees use two-factor authentication with a physical token.

A Google spokesperson said Security Keys now form the basis of all account access at Google.

“We have had no reported or confirmed account takeovers since implementing security keys at Google,” the spokesperson said. “Users might be asked to authenticate using their security key for many different apps/reasons. It all depends on the sensitivity of the app and the risk of the user at that point in time.”

Now Google is selling that security to its users:

On Wednesday, the company announced its new Titan security key, a device that protects your accounts by restricting two-factor authentication to the physical world. It’s available as a USB stick and in a Bluetooth variation, and like similar products by Yubico and Feitian, it utilizes the protocol approved by the FIDO alliance. That means it’ll be compatible with pretty much any service that enables users to turn on Universal 2nd Factor Authentication (U2F).

Powered by WPeMatico

Perverse Vulnerability from Interaction between 2-Factor Authentication and iOS AutoFill

Apple is rolling out an iOS security usability feature called Security code AutoFill. The basic idea is that the OS scans incoming SMS messages for security codes and suggests them in AutoFill, so that people can use them without having to memorize or type them.

Sounds like a really good idea, but Andreas Gutmann points out an application where this could become a vulnerability: when authenticating transactions:

Transaction authentication, as opposed to user authentication, is used to attest the correctness of the intention of an action rather than just the identity of a user. It is most widely known from online banking, where it is an essential tool to defend against sophisticated attacks. For example, an adversary can try to trick a victim into transferring money to a different account than the one intended. To achieve this the adversary might use social engineering techniques such as phishing and vishing and/or tools such as Man-in-the-Browser malware.

Transaction authentication is used to defend against these adversaries. Different methods exist but in the one of relevance here — which is among the most common methods currently used — the bank will summarise the salient information of any transaction request, augment this summary with a TAN tailored to that information, and send this data to the registered phone number via SMS. The user, or bank customer in this case, should verify the summary and, if this summary matches with his or her intentions, copy the TAN from the SMS message into the webpage.

This new iOS feature creates problems for the use of SMS in transaction authentication. Applied to 2FA, the user would no longer need to open and read the SMS from which the code has already been conveniently extracted and presented. Unless this feature can reliably distinguish between OTPs in 2FA and TANs in transaction authentication, we can expect that users will also have their TANs extracted and presented without context of the salient information, e.g. amount and destination of the transaction. Yet, precisely the verification of this salient information is essential for security. Examples of where this scenario could apply include a Man-in-the-Middle attack on the user accessing online banking from their mobile browser, or where a malicious website or app on the user’s phone accesses the bank’s legitimate online banking service.

This is an interesting interaction between two security systems. Security code AutoFill eliminates the need for the user to view the SMS or memorize the one-time code. Transaction authentication assumes the user read and approved the additional information in the SMS message before using the one-time code.

Powered by WPeMatico

New Technique to Hijack Social Media Accounts

Access Now has documented it being used against a Twitter user, but it also works against other social media accounts:

With the Doubleswitch attack, a hijacker takes control of a victim’s account through one of several attack vectors. People who have not enabled an app-based form of multifactor authentication for their accounts are especially vulnerable. For instance, an attacker could trick you into revealing your password through phishing. If you don’t have multifactor authentication, you lack a secondary line of defense. Once in control, the hijacker can then send messages and also subtly change your account information, including your username. The original username for your account is now available, allowing the hijacker to register for an account using that original username, while providing different login credentials.

Three news stories.

Powered by WPeMatico

Criminals are Now Exploiting SS7 Flaws to Hack Smartphone Two-Factor Authentication Systems

I’ve previously written about the serious vulnerabilities in the SS7 phone routing system. Basically, the system doesn’t authenticate messages. Now, criminals are using it to hack smartphone-based two-factor authentication systems:

In short, the issue with SS7 is that the network believes whatever you tell it. SS7 is especially used for data-roaming: when a phone user goes outside their own provider’s coverage, messages still need to get routed to them. But anyone with SS7 access, which can be purchased for around 1000 Euros according to The Süddeutsche Zeitung, can send a routing request, and the network may not authenticate where the message is coming from.

That allows the attacker to direct a target’s text messages to another device, and, in the case of the bank accounts, steal any codes needed to login or greenlight money transfers (after the hackers obtained victim passwords).

Powered by WPeMatico

NIST is No Longer Recommending Two-Factor Authentication Using SMS

NIST is no longer recommending two-factor authentication systems that use SMS, because of their many insecurities. In the latest draft of its Digital Authentication Guideline, there’s the line:

[Out of band verification] using SMS is deprecated, and will no longer be allowed in future releases of this guidance.

Powered by WPeMatico