Entries Tagged "authentication"

Page 10 of 28

Heartwave Biometric

Here’s a new biometric I know nothing about:

The wristband relies on authenticating identity by matching the overall shape of the user’s heartwave (captured via an electrocardiogram sensor). Unlike other biotech authentication methods—like fingerprint scanning and iris-/facial-recognition tech—the system doesn’t require the user to authenticate every time they want to unlock something. Because it’s a wearable device, the system sustains authentication so long as the wearer keeps the wristband on.

EDITED TO ADD (12/13): A more technical explanation.

Posted on December 5, 2013 at 1:16 PM • View Comments

Risk-Based Authentication

I like this idea of giving each individual login attempt a risk score, based on the characteristics of the attempt:

The risk score estimates the risk associated with a log-in attempt based on a user’s typical log-in and usage profile, taking into account their device and geographic location, the system they’re trying to access, the time of day they typically log in, their device’s IP address, and even their typing speed. An employee logging into a CRM system using the same laptop, at roughly the same time of day, from the same location and IP address will have a low risk score. By contrast, an attempt to access a finance system from a tablet at night in Bali could potentially yield an elevated risk score.

Risk thresholds for individual systems are established based on the sensitivity of the information they store and the impact if the system were breached. Systems housing confidential financial data, for example, will have a low risk threshold.

If the risk score for a user’s access attempt exceeds the system’s risk threshold, authentication controls are automatically elevated, and the user may be required to provide a higher level of authentication, such as a PIN or token. If the risk score is too high, it may be rejected outright.

Posted on November 7, 2013 at 7:06 AM • View Comments

Apple's iPhone Fingerprint Reader Successfully Hacked

Nice hack from the Chaos Computer Club:

The method follows the steps outlined in this how-to with materials that can be found in almost every household: First, the fingerprint of the enrolled user is photographed with 2400 dpi resolution. The resulting image is then cleaned up, inverted and laser printed with 1200 dpi onto transparent sheet with a thick toner setting. Finally, pink latex milk or white woodglue is smeared into the pattern created by the toner onto the transparent sheet. After it cures, the thin latex sheet is lifted from the sheet, breathed on to make it a tiny bit moist and then placed onto the sensor to unlock the phone. This process has been used with minor refinements and variations against the vast majority of fingerprint sensors on the market.

I’m not surprised. In my essay on Apple’s technology, I wrote: “I’m sure that someone with a good enough copy of your fingerprint and some rudimentary materials engineering capability—or maybe just a good enough printer—can authenticate his way into your iPhone.”

I don’t agree with CCC’s conclusion, though:

“We hope that this finally puts to rest the illusions people have about fingerprint biometrics. It is plain stupid to use something that you can´t change and that you leave everywhere every day as a security token”, said Frank Rieger, spokesperson of the CCC. “The public should no longer be fooled by the biometrics industry with false security claims. Biometrics is fundamentally a technology designed for oppression and control, not for securing everyday device access.”

Apple is trying to balance security with convenience. This is a cell phone, not a ICBM launcher or even a bank account withdrawal device. Apple is offering an option to replace a four-digit PIN—something that a lot of iPhone users don’t even bother with—with a fingerprint. Despite its drawbacks, I think it’s a good trade-off for a lot of people.

EDITED TO ADD (10/13): The print for the CCC hack was lifted from the iPhone.

Posted on September 24, 2013 at 9:20 AM • View Comments

iPhone Fingerprint Authentication

When Apple bought AuthenTec for its biometrics technology—reported as one of its most expensive purchases—there was a lot of speculation about how the company would incorporate biometrics in its product line. Many speculate that the new Apple iPhone to be announced tomorrow will come with a fingerprint authentication system, and there are several ways it could work, such as swiping your finger over a slit-sized reader to have the phone recognize you.

Apple would be smart to add biometric technology to the iPhone. Fingerprint authentication is a good balance between convenience and security for a mobile device.

Biometric systems are seductive, but the reality isn’t that simple. They have complicated security properties. For example, they are not keys. Your fingerprint isn’t a secret; you leave it everywhere you touch.

And fingerprint readers have a long history of vulnerabilities as well. Some are better than others. The simplest ones just check the ridges of a finger; some of those can be fooled with a good photocopy. Others check for pores as well. The better ones verify pulse, or finger temperature. Fooling them with rubber fingers is harder, but often possible. A Japanese researcher had good luck doing this over a decade ago with the gelatin mixture that’s used to make Gummi bears.

The best system I’ve ever seen was at the entry gates of a secure government facility. Maybe you could have fooled it with a fake finger, but a Marine guard with a big gun was making sure you didn’t get the opportunity to try. Disney World uses a similar system at its park gates—but without the Marine guards.

A biometric system that authenticates you and you alone is easier to design than a biometric system that is supposed to identify unknown people. That is, the question “Is this the finger belonging to the owner of this iPhone?” is a much easier question for the system to answer than “Whose finger is this?”

There are two ways an authentication system can fail. It can mistakenly allow an unauthorized person access, or it can mistakenly deny access to an authorized person. In any consumer system, the second failure is far worse than the first. Yes, it can be problematic if an iPhone fingerprint system occasionally allows someone else access to your phone. But it’s much worse if you can’t reliably access your own phone—you’d junk the system after a week.

If it’s true that Apple’s new iPhone will have biometric security, the designers have presumably erred on the side of ensuring that the user can always get in. Failures will be more common in cold weather, when your shriveled fingers just got out of the shower, and so on. But there will certainly still be the traditional PIN system to fall back on.

So…can biometric authentication be hacked?

Almost certainly. I’m sure that someone with a good enough copy of your fingerprint and some rudimentary materials engineering capability—or maybe just a good enough printer—can authenticate his way into your iPhone. But, honestly, if some bad guy has your iPhone and your fingerprint, you’ve probably got bigger problems to worry about.

The final problem with biometric systems is the database. If the system is centralized, there will be a large database of biometric information that’s vulnerable to hacking. A system by Apple will almost certainly be local—you authenticate yourself to the phone, not to any network—so there’s no requirement for a centralized fingerprint database.

Apple’s move is likely to bring fingerprint readers into the mainstream. But all applications are not equal. It’s fine if your fingers unlock your phone. It’s a different matter entirely if your fingerprint is used to authenticate your iCloud account. The centralized database required for that application would create an enormous security risk.

This essay previously appeared on Wired.com.

EDITED TO ADD: The new iPhone does have a fingerprint reader.

Posted on September 11, 2013 at 6:43 AM • View Comments

Human-Machine Trust Failures

I jacked a visitor’s badge from the Eisenhower Executive Office Building in Washington, DC, last month. The badges are electronic; they’re enabled when you check in at building security. You’re supposed to wear it on a chain around your neck at all times and drop it through a slot when you leave.

I kept the badge. I used my body as a shield, and the chain made a satisfying noise when it hit bottom. The guard let me through the gate.

The person after me had problems, though. Some part of the system knew something was wrong, and wouldn’t let her out. Eventually, the guard had to manually override something.

My point in telling this story is not to demonstrate how I beat the EEOB’s security—I’m sure the badge was quickly deactivated and showed up in some missing-badge log next to my name—but to illustrate how security vulnerabilities can result from human/machine trust failures. Something went wrong between when I went through the gate and when the person after me did. The system knew it but couldn’t adequately explain it to the guards. The guards knew it but didn’t know the details. Because the failure occurred when the person after me tried to leave the building, they assumed she was the problem. And when they cleared her of wrongdoing, they blamed the system.

In any hybrid security system, the human portion needs to trust the machine portion. To do so, both must understand the expected behavior for every state—how the system can fail and what those failures look like. The machine must be able to communicate its state and have the capacity to alert the humans when an expected state transition doesn’t happen as expected. Things will go wrong, either by accident or as the result of an attack, and the humans are going to need to troubleshoot the system in real time—that requires understanding on both parts. Each time things go wrong, and the machine portion doesn’t communicate well, the human portion trusts it a little less.

This problem is not specific to security systems, but inducing this sort of confusion is a good way to attack systems. When the attackers understand the system—especially the machine part—better than the humans in the system do, they can create a failure to exploit. Many social engineering attacks fall into this category. Failures also happen the other way. We’ve all experienced trust without understanding, when the human part of the system defers to the machine, even though it makes no sense: “The computer is always right.”

Humans and machines have different strengths. Humans are flexible and can do creative thinking in ways that machines cannot. But they’re easily fooled. Machines are more rigid and can handle state changes and process flows much better than humans can. But they’re bad at dealing with exceptions. If humans are to serve as security sensors, they need to understand what is being sensed. (That’s why “if you see something, say something” fails so often.) If a machine automatically processes input, it needs to clearly flag anything unexpected.

The more machine security is automated, and the more the machine is expected to enforce security without human intervention, the greater the impact of a successful attack. If this sounds like an argument for interface simplicity, it is. The machine design will be necessarily more complicated: more resilience, more error handling, and more internal checking. But the human/computer communication needs to be clear and straightforward. That’s the best way to give humans the trust and understanding they need in the machine part of any security system.

This essay previously appeared in IEEE Security & Privacy.

Posted on September 5, 2013 at 8:32 AM • View 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 PM • View Comments

Security Risks of Too Much Security

All of the anti-counterfeiting features of the new Canadian $100 bill are resulting in people not bothering to verify them.

The fanfare about the security features on the bills, may be part of the problem, said RCMP Sgt. Duncan Pound.

“Because the polymer series’ notes are so secure … there’s almost an overconfidence among retailers and the public in terms of when you sort of see the strip, the polymer looking materials, everybody says ‘oh, this one’s going to be good because you know it’s impossible to counterfeit,'” he said.

“So people don’t actually check it.”

Posted on May 20, 2013 at 6:34 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

Google's Authentication Research

Google is working on non-password authentication techniques.

But for Google’s password-liberation plan to really take off, they’re going to need other websites to play ball. “Others have tried similar approaches but achieved little success in the consumer world,” they write. “Although we recognize that our initiative will likewise remain speculative until we’ve proven large scale acceptance, we’re eager to test it with other websites.”

So they’ve developed a (as yet unnamed) protocol for device-based authentication that they say is independent of Google, requires no special software to work—aside from a web browser that supports the login standard—and which prevents web sites from using this technology to track users.

The great thing about Google’s approach is that it circumvents the really common attack that even Google’s existing mobile-phone authentication system can’t prevent: phishing.

They have enough industry muscle that they might pull it off.

Another article.

Posted on January 22, 2013 at 12:04 PM • View Comments

1 … 8 9 10 11 12 … 28

Sidebar photo of Bruce Schneier by Joe MacInnis.