Entries Tagged "security tokens"

Page 1 of 2

Smart Contract Bug Results in $31 Million Loss

A hacker stole $31 million from the blockchain company MonoX Finance , by exploiting a bug in software the service uses to draft smart contracts.

Specifically, the hack used the same token as both the tokenIn and tokenOut, which are methods for exchanging the value of one token for another. MonoX updates prices after each swap by calculating new prices for both tokens. When the swap is completed, the price of tokenIn­that is, the token sent by the user­decreases and the price of tokenOut­or the token received by the user­increases.

By using the same token for both tokenIn and tokenOut, the hacker greatly inflated the price of the MONO token because the updating of the tokenOut overwrote the price update of the tokenIn. The hacker then exchanged the token for $31 million worth of tokens on the Ethereum and Polygon blockchains.

The article goes on to talk about how common these sorts of attacks are. The basic problem is that the code is the ultimate authority—there is no adjudication protocol—so if there’s a vulnerability in the code, there is no recourse. And, of course, there are lots of vulnerabilities in code.

To me, this is reason enough never to use smart contracts for anything important. Human-based adjudication systems are not useless pre-Internet human baggage, they’re vital.

Posted on December 2, 2021 at 8:32 AM • View Comments

Yubico Security Keys with a Crypto Flaw

Wow, is this an embarrassing bug:

Yubico is recalling a line of security keys used by the U.S. government due to a firmware flaw. The company issued a security advisory today that warned of an issue in YubiKey FIPS Series devices with firmware versions 4.4.2 and 4.4.4 that reduced the randomness of the cryptographic keys it generates. The security keys are used by thousands of federal employees on a daily basis, letting them securely log-on to their devices by issuing one-time passwords.

The problem in question occurs after the security key powers up. According to Yubico, a bug keeps “some predictable content” inside the device’s data buffer that could impact the randomness of the keys generated. Security keys with ECDSA signatures are in particular danger. A total of 80 of the 256 bits generated by the key remain static, meaning an attacker who gains access to several signatures could recreate the private key.

Boing Boing post.

EDITED TO ADD (6/12): From Microsoft TechNet Security Guidance blog (in 2014): “Why We’re Not Recommending ‘FIPS Mode’ Anymore.“

Posted on July 1, 2019 at 5:55 AM • View Comments

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.

Posted on May 1, 2019 at 6:14 AM • View Comments

Quantum Tokens for Digital Signatures

This paper wins “best abstract” award: “Quantum Tokens for Digital Signatures,” by Shalev Ben David and Or Sattath:

Abstract: The fisherman caught a quantum fish. “Fisherman, please let me go,” begged the fish, “and I will grant you three wishes.” The fisherman agreed. The fish gave the fisherman a quantum computer, three quantum signing tokens and his classical public key.

The fish explained: “to sign your three wishes, use the tokenized signature scheme on this quantum computer, then show your valid signature to the king, who owes me a favor.”

The fisherman used one of the signing tokens to sign the document “give me a castle!” and rushed to the palace. The king executed the classical verification algorithm using the fish’s public key, and since it was valid, the king complied.

The fisherman’s wife wanted to sign ten wishes using their two remaining signing tokens. The fisherman did not want to cheat, and secretly sailed to meet the fish. “Fish, my wife wants to sign ten more wishes.”

But the fish was not worried: “I have learned quantum cryptography following the previous story (The Fisherman and His Wife by the brothers Grimm). The quantum tokens are consumed during the signing. Your polynomial wife cannot even sign four wishes using the three signing tokens I gave you.”

“How does it work?” wondered the fisherman.

“Have you heard of quantum money? These are quantum states which can be easily verified but are hard to copy. This tokenized quantum signature scheme extends Aaronson and Christiano’s quantum money scheme, which is why the signing tokens cannot be copied.”

“Does your scheme have additional fancy properties?” the fisherman asked.

“Yes, the scheme has other security guarantees: revocability, testability and everlasting security. Furthermore, if you’re at the sea and your quantum phone has only classical reception, you can use this scheme to transfer the value of the quantum money to shore,” said the fish, and swam his way.

Posted on October 6, 2016 at 7:03 AM • View Comments

Tor Appliance

Safeplug is an easy-to-use Tor appliance. I like that it can also act as a Tor exit node.

EDITED TO ADD: I know nothing about this appliance, nor do I endorse it. In fact, I would like it to be independently audited before we start trusting it. But it’s a fascinating proof-of-concept of encapsulating security so that normal Internet users can use it.

Posted on November 27, 2013 at 6:28 AM • View Comments

Using the iWatch for Authentication

Usability engineer Bruce Tognazzini talks about how an iWatch—which seems to be either a mythical Apple product or one actually in development—can make authentication easier.

Passcodes. The watch can and should, for most of us, eliminate passcodes altogether on iPhones, and Macs and, if Apple’s smart, PCs: As long as my watch is in range, let me in! That, to me, would be the single-most compelling feature a smartwatch could offer: If the watch did nothing but release me from having to enter my passcode/password 10 to 20 times a day, I would buy it. If the watch would just free me from having to enter pass codes, I would buy it even if it couldn’t tell the right time! I would happily strap it to my opposite wrist! This one is a must. Yes, Apple is working on adding fingerprint reading for iDevices, and that’s just wonderful, but it will still take time and trouble for the device to get an accurate read from the user. I want in now! Instantly! Let me in, let me in, let me in!

Apple must ensure, however, that, if you remove the watch, you must reestablish authenticity. (Reauthorizing would be an excellent place for biometrics.) Otherwise, we’ll have a spate of violent “watchjackings” replacing the non-violent iPhone-grabs going on today.

Posted on February 14, 2013 at 11:42 AM • View Comments

Balancing Security and Usability in Authentication

Since January, the Conficker.B worm has been spreading like wildfire across the Internet: infecting the French Navy, hospitals in Sheffield, the court system in Houston, and millions of computers worldwide. One of the ways it spreads is by cracking administrator passwords on networks. Which leads to the important question: Why in the world are IT administrators still using easy-to-guess passwords?

Computer authentication systems have two basic requirements. They need to keep the bad guys from accessing your account, and they need to allow you to access your account. Both are important, and every authentication system is a balancing act between the two. Too little security, and the bad guys will get in too easily. But if the authentication system is too complicated, restrictive, or hard to use, you won’t be able to—or won’t bother to—use it.

Passwords are the most common authentication system, and a good place to start. They’re very easy to implement and use, which is why they’re so popular. But as computers have become faster, password guessing has become easier. Most people don’t choose passwords that are complicated enough to remain secure against modern password-guessing attacks. Conficker.B is even less clever; it just tries a list of about 200 common passwords.

To combat password guessing, many systems force users to choose harder-to-guess passwords—requiring minimum lengths, non alpha-numeric characters, etc.—and change their passwords more frequently. The first makes guessing harder, and the second makes a guessed password less valuable. This, of course, makes the system more annoying, so users respond by writing their passwords down and taping them to their monitors, or simply forgetting them more often. Smarter users write them down and put them in their wallets, or use a secure password database like Password Safe.

Users forgetting their passwords can be expensive—sysadmins or customer service reps have to field phone calls and reset passwords—so some systems include a backup authentication system: a secret question. The idea is that if you forget your password, you can authenticate yourself with some personal information that only you know. Your mother’s maiden name was traditional, but these days there are all sorts of secret questions: your favourite schoolteacher, favourite colour, street you grew up on, name of your first pet, and so on. This might make the system more usable, but it also makes it much less secure: answers can be easily guessable, and are often known by people close to you.

A common enhancement is a one-time password generator, like a SecurID token. This is a small device with a screen that displays a password that changes automatically once a minute. Adding this is called two-factor authentication, and is much more secure, because this token—”something you have”—is combined with a password—”something you know.” But it’s less usable, because the tokens have to be purchased and distributed to all users, and far too often it’s “something you lost or forgot.” And it costs money. Tokens are far more frequently used in corporate environments, but banks and some online gaming worlds have taken to using them—sometimes only as an option, because people don’t like them.

In most cases, how an authentication system works when a legitimate user tries to log on is much more important than how it works when an impostor tries to log on. No security system is perfect, and there is some level of fraud associated with any of these authentication methods. But the instances of fraud are rare compared to the number of times someone tries to log on legitimately. If a given authentication system let the bad guys in one in a hundred times, a bank could decide to live with the problem—or try to solve it in some other way. But if the same authentication system prevented legitimate customers from logging on even one in a thousand times, the number of complaints would be enormous and the system wouldn’t survive one week.

Balancing security and usability is hard, and many organizations get it wrong. But it’s also evolving; organizations needing to tighten their security continue to push more involved authentication methods, and more savvy Internet users are willing to accept them. And certainly IT administrators need to be leading that evolutionary change.

A version of this essay was originally published in The Guardian.

Posted on February 19, 2009 at 1:44 PM • View Comments

The Failure of Two-Factor Authentication

Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.

The problem with passwords is that they’re too easy to lose control of. People give them to other people. People write them down, and other people read them. People send them in e-mail, and that e-mail is intercepted. People use them to log into remote servers, and their communications are eavesdropped on. They’re also easy to guess. And once any of that happens, the password no longer works as an authentication token because you can’t be sure who is typing that password in.

Two-factor authentication mitigates this problem. If your password includes a number that changes every minute, or a unique reply to a random challenge, then it’s harder for someone else to intercept. You can’t write down the ever-changing part. An intercepted password won’t be good the next time it’s needed. And a two-factor password is harder to guess. Sure, someone can always give his password and token to his secretary, but no solution is foolproof.

These tokens have been around for at least two decades, but it’s only recently that they have gotten mass-market attention. AOL is rolling them out. Some banks are issuing them to customers, and even more are talking about doing it. It seems that corporations are finally waking up to the fact that passwords don’t provide adequate security, and are hoping that two-factor authentication will fix their problems.

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 real threat is fraud due to impersonation, and the tactics of impersonation will change in response to the defenses. Two-factor authentication will force criminals to modify their tactics, that’s all.

Recently I’ve seen examples of two-factor authentication using two different communications paths: call it “two-channel authentication.” One bank sends a challenge to the user’s cell phone via SMS and expects a reply via SMS. If you assume that all your customers have cell phones, then this results in a two-factor authentication process without extra hardware. And even better, the second authentication piece goes over a different communications channel than the first; eavesdropping is much, much harder.

But in this new world of active attacks, no one cares. An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can’t do it himself. And a Trojan attacker doesn’t care, because he’s relying on the user to log in anyway.

Two-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won’t work for remote authentication over the Internet. I predict that banks and other financial institutions will spend millions outfitting their users with two-factor authentication tokens. Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.

This essay will appear in the April issue of Communications of the ACM.

Posted on March 15, 2005 at 7:54 AM • View Comments

1 2

Sidebar photo of Bruce Schneier by Joe MacInnis.