Skip to content

Bit9

As Bit9 blogged about at the time, RSA made headlines last week when it announced that it has suffered a data breach at the hands of an extremely sophisticated attack. While we know very little about this specific incident, it is a good opportunity to discuss both the benefits and pitfalls of multi-factor authentication.

The idea behind multi-factor authentication is to employ multiple and independent methods to allow someone to validate your identity. Independent means that even if one factor were compromised, it would not be enough to compromise the system. The most common form of identification is passwords – or “something you know”. Even if a system uses multiple questions or pictures that you must identify, it is still 1-factor authentication, as these are all variations of something you know.

Multi-factor authentication comes when you introduce a completely new component, such as “something you have” or “something you are”. For example, when you retrieve money from an ATM, there are two factors at play: your PIN (something you know), and your bank card (something you have). One without the other is not enough. Biometric authentication (e.g. fingerprints, iris scanners, voice recognition) are examples of “something you are”. Each factor added to the authentication chain is another hurdle that an attacker must overcome to fake the system, fake your identity.

The choice of which factor or factors to use is a trade-off between security, convenience, and cost. It’s simply not cost effective to have fingerprint scanners everywhere we use passwords, for example. And in fact, even if we could, unlike passwords and some other methods, fingerprints cannot be easily changed. If someone did get their hands on (no pun intended) your fingerprints, that method of authentication is useless to you forever more.

We’ve all seen movies where a black ops team breaks into a multi-factor authentication system through a series of high-risk adrenaline pumping missions –stealing an iris scan by spraying something in the target’s eye, swiping the target’s access card with sleight of hand during a dinner party, and then cracking the password with some fancy cigarette-pack sized electronic device. It’s great entertainment, but it’s not really practical for even the most advanced criminals. Instead of trying to break each piece of authentication independently, real world attacks focus on the choke points – places in the system where all of the information can be stolen at the same time.

ATM skimming works on this principle. By placing a fake magnetic reader over the real one at an ATM, along with a hidden camera, they are able to steal both your card data (something you have) and your PIN (something you know). The choke point is the physical location of the ATM – there, criminals can obtain all the factors needed to assume your identity.

For most systems, the computer is the choke point. Consider a computer terminal where you have to both swipe a card and enter your password. If there is a trojan on the system, it can capture all information being input. Even if the system encrypts all of the data before transmitting it, too often the data resides in memory unencrypted, or is unencrypted at the point of entry (e.g. the keyboard or system driver for the magnetic card reader).

Which brings us to the RSA SecurID attack. SecurID is a hardware token that generates a “random” number every 30 or 60 seconds (which it either displays on an LCD panel or transmits to the computer automatically). That number must be entered into the system, usually along with a password. The idea is that even if the system were infected and the number were stolen, it is useless within a minute. Unlike passwords and biometric authentication, this type of “something you have” authentication can be used to create continually changing codes, mitigating the computer as a useful choke point. But in computers, nothing is truly random. Random numbers are generated using formulae and magic seed values. How else would the server on the other end of the system know whether the number you entered is actually valid? The server is able to predict what number your specific device will display at any given time. If attackers were able to steal this formula, they might be able to predict future hardware-token values. If, to do this, they require the serial number or other identifying information about each specific hardware-token device, then be on the lookout for phishing attacks or emails asking you for your token serial number or other information that might otherwise seem innocuous. As we’ve seen with some of the more sophisticated cyber attacks of late, enemies are both organized and patient. This could be just one phase in a longer term or multi-pronged plan to compromise one type of authentication.

But speaking purely theoretically, what if the stolen information was enough to predict future codes given enough data points – in other words, by matching the same user password with multiple token codes over several (or perhaps hundreds) of points in time? In that case, attacking the end terminal and monitoring both the user passwords and token codes might be enough for an attacker to assume a user’s identity. This is entirely speculative and I am not saying that SecurID has been compromised as such. I am simply noting that every authentication factor has both pros and cons, strengths and vulnerabilities. The level of sophistication required to reverse engineer such tokens, even given the seed values, is enormous.

The real point is that when considering multi-factor authentication, think about your choke points. Each additional factor adds a hurdle to an attacker if they are tackled independently. If you use systems where all these factors come together, and those factors are either unchanging (e.g. fingerprints and most passwords) or predictable, you are vulnerable.

email

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

*

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.


  • Blog

+1 617-393-7400 US