[Updated 5:36 pm ET 23 Mar 2011]
Sorry - two points of clarification:
1. Where I say "serial #" throughout my post below, we should keep in mind that the token has a hidden 'seed record' which is actually used in the algorithm, so that's another level of security. The serial # is not enough - you also need the seed # and the ability to match it to a given user's token.
2. I should've mentioned that there's also a feature which prevents brute-force attacks by disabling an account after x number of failed attempts, so if you have a very good educated guess on the PIN, along with the other data, you have a good shot. If you think you'll brute-force it, that isn't going to fly.
[end update]
I don't have any inside info, but it certainly sounds like the algorithm for generating the One-Time-Passwords (OTP) may have been accessed. This makes an attack much easier because to some degree it eliminates the "second factor" in the Two-Factor authentication. But not 100%.
If I know the algorithm, to spoof the token functionality, I still need the serial # of the token, matched to the user name, and the PIN. These things aren't impossible, though. You could stop by a person's desk, for example, and scribble down their serial # while they're getting coffee. If they're a co-worker, you probably know their user name and can make some guesses about the PIN.
Most people I know that use RSA tokens use a pretty simple PIN - a date, 4 digits of a phone number, something like that. So, if you use social engineering to get the serial # and user name, your down to having to guess the PIN, which is really a shorter, less secure password. And you're back to one-factor authentication. PINs may also be written down on the desk, scribbled on the back of the token (I've seen it), left in email or browser auto-fill, etc.
For an outsider to use this attack, it's a little more challenging than an insider. You'd need access to the serial numbers used by the company and the ability to match them with user names. Based on the info provided by RSA in their letter to customers, some or all of this may be in the RSA server logs. So, protecting those logs has just become critical.
If the token is installed on a smart phone or PC (software token), the token only works from that installed device. So, if the algorithm is public, the software tokens may have just become slightly more secure than the hardware tokens since it would be difficult to spoof the hardware configuration (or even to know the exact hardware) associated to that software token. ...at least, that's how I think it works.
So, a few shifts have been made if my assumptions are true:
- Software tokens may be more secure if the algorithm is known.
- Protecting the RSA server and logs, and access to those logs has become critical.
- Overall, the system is still somewhat secure, but people don't buy RSA tokens for 'somewhat secure'.
- RSA tokens have become pretty insecure against insider attacks.
If anyone knows something different, please correct me.
Security for the Digital Transformation: Cloud, Data, Identity & Access.
Showing posts with label two factor. Show all posts
Showing posts with label two factor. Show all posts
Wednesday, March 23
Thursday, October 22
Two Factor Authentication is Worth Nothing?
Apparently, Roger Dean, executive director of EEMA, recently declared two-factor authentication “not worth anything anymore.” According to the article, Dean's thinking is that man in the middle (MITM) attacks render strong authentication useless.
Isn't that like claiming that firewalls are worthless because they don't prevent viruses from being installed on desktops? Strong authentication (which includes two-factor) was never intended to prevent MITM attacks. That problem was already (theoretically) solved with SSL.
Perhaps Dean was reading Bruce Schneier's thoughts from back in 2005. I get it. Issuing tokens to users is not a panacea. But, there is no cure-all in the security space. We rely on SSL to establish secure links to sites, which should both identify the site as being who it says and prevent snooping. Theoretically, that end-to-end encryption and use of trusted certificate authorities is what would prevent MITM attacks.
But even when using SSL correctly (and assuming there are no flaws in SSL), there is still an authentication challenge that strong authentication techniques such as two-factor rise to meet. Without it, users may share credentials or use weak passwords exposing numerous other potential attack vectors.
I think Dean's frustration is focused in the wrong direction. Strong authentication techniques are good at what they do and (still) have their place in the security infrastructure. I think the problem he's seeing mainly lies in the user interface of SSL. Like any good security feature should, it does a good job of staying transparent to the end user. But a little too good. So good, in fact, that most users don't even know when it's not there. And that's the problem.
If we could force users to look for and expect the SSL connection and to confirm the domain with which they're connected, phishing and MITM would become immediately unprofitable. I'm surprised browser vendors haven't done that yet (and EV certificates are not the answer). Personally, I'd want to see a white list approach for personal banking and other regular-use sites coupled with a per-use hoop to jump through for occasional other data transfers.
But don't blame strong authentication for SSL's incompetence.
Isn't that like claiming that firewalls are worthless because they don't prevent viruses from being installed on desktops? Strong authentication (which includes two-factor) was never intended to prevent MITM attacks. That problem was already (theoretically) solved with SSL.
Perhaps Dean was reading Bruce Schneier's thoughts from back in 2005. I get it. Issuing tokens to users is not a panacea. But, there is no cure-all in the security space. We rely on SSL to establish secure links to sites, which should both identify the site as being who it says and prevent snooping. Theoretically, that end-to-end encryption and use of trusted certificate authorities is what would prevent MITM attacks.
But even when using SSL correctly (and assuming there are no flaws in SSL), there is still an authentication challenge that strong authentication techniques such as two-factor rise to meet. Without it, users may share credentials or use weak passwords exposing numerous other potential attack vectors.
I think Dean's frustration is focused in the wrong direction. Strong authentication techniques are good at what they do and (still) have their place in the security infrastructure. I think the problem he's seeing mainly lies in the user interface of SSL. Like any good security feature should, it does a good job of staying transparent to the end user. But a little too good. So good, in fact, that most users don't even know when it's not there. And that's the problem.
If we could force users to look for and expect the SSL connection and to confirm the domain with which they're connected, phishing and MITM would become immediately unprofitable. I'm surprised browser vendors haven't done that yet (and EV certificates are not the answer). Personally, I'd want to see a white list approach for personal banking and other regular-use sites coupled with a per-use hoop to jump through for occasional other data transfers.
But don't blame strong authentication for SSL's incompetence.
Friday, October 9
Cloud-Based Strong Authentication
Yesterday, RSA and Verisign announced a partnership on cloud-based secure authentication for the consumer market. Pretty interesting stuff. The management of these organizations should be commended for looking past their competitive rivalry to identify a new business opportunity.
The solution isn't new. Verisign has been offering its VeriSign Identity Protection (VIP) authentication services for quite some time. I've had a token that I use with my PayPal account (and my OpenID) for the past couple of years (made in China by ActiveIdentity). But adoption of the offering has been less than overwhelming.
We could probably all count on one hand the number of people we know with a non-work-based authentication token. And most of those are likely tokens handed out by banks and other financial companies that are tied to a single account. The VIP solution gives you a token to use across multiple sites. And there are a few other perks as well.
I don't know what they charge to add this strong authentication to your site. But, I expect that it's more competitive than implementing your own solution. And the end-users benefit from a single token that can be used across systems.
RSA hasn't been wildly successful in getting tokens into the hands of consumers. So, partnering with Verisign seems like a good move - leverage an existing solution to sell more product. And Verisign customers benefit from more choice. RSA has a lot of token options and some are impressive. Their manufacturing is done at their headquarters in MA and the quality assurance process is top rate (I've been through the tour).
In addition to overall quality, some provide additional convenience as well such as a token with an integrated smart chip (for access to encrypted laptops and digital signing) or the software tokens for BlackBerry, iPhone, Win Mobile, etc. that don't require an additional piece of hardware. I should note that the release only mentions hardware tokens, but in the consumer market, it would be a bad move to restrict usage to hardware only.
The solution isn't new. Verisign has been offering its VeriSign Identity Protection (VIP) authentication services for quite some time. I've had a token that I use with my PayPal account (and my OpenID) for the past couple of years (made in China by ActiveIdentity). But adoption of the offering has been less than overwhelming.
We could probably all count on one hand the number of people we know with a non-work-based authentication token. And most of those are likely tokens handed out by banks and other financial companies that are tied to a single account. The VIP solution gives you a token to use across multiple sites. And there are a few other perks as well.
I don't know what they charge to add this strong authentication to your site. But, I expect that it's more competitive than implementing your own solution. And the end-users benefit from a single token that can be used across systems.
RSA hasn't been wildly successful in getting tokens into the hands of consumers. So, partnering with Verisign seems like a good move - leverage an existing solution to sell more product. And Verisign customers benefit from more choice. RSA has a lot of token options and some are impressive. Their manufacturing is done at their headquarters in MA and the quality assurance process is top rate (I've been through the tour).
In addition to overall quality, some provide additional convenience as well such as a token with an integrated smart chip (for access to encrypted laptops and digital signing) or the software tokens for BlackBerry, iPhone, Win Mobile, etc. that don't require an additional piece of hardware. I should note that the release only mentions hardware tokens, but in the consumer market, it would be a bad move to restrict usage to hardware only.
Labels:
authentication,
Cloud,
Consumer market,
managed services,
RSA,
two factor,
Verisign
Wednesday, April 1
On Multi-factor Authentication
Luther Martin of Voltage Security posted a very interesting post on the future of multi-factor authentication. In it, he challenged commonly held beliefs on the subject. Specifically, he writes:
Martin goes on to suggest that using two authentication mechanisms of the same factor may be as secure as using two factors and lays out scheme A & B to discuss.
So here's my thoughts:
Wouldn't scheme A be more secure because you can't brute force it? Isn't that the whole point of having the second factor? All passwords can be brute-forced given enough time. Having the second factor removes that threat.
Of course, you could implement a strong password plus a kill switch after 10 bad tries, but that still relies on the user to implement safe password storage. And I generally think it's better to remove any responsibility from the end-user (especially if there's a convenience trade off).
Requiring users to carry/remember two username-password combinations for every system doesn't seem practical. Security will fail if users try to subvert it for the sake of convenience. And they will.
Usability needs to be a key consideration. A token/pin combination is a secure and easy-to-use way to beat the threat of brute-force attacks and poor password management. ...as is having a certificate installed on a particular PC and other second factor solutions.
It’s often claimed that multi-factor authentication is inherently more secure than single-factor authentication, but if you look at the history of this claim,it actually came from a vendor that wanted to make their multi-factor authentication product sound better than competitors' products.(I'm not sure if these are his thoughts or if he's saying that was the consensus at a recent X9 meeting.)
Martin goes on to suggest that using two authentication mechanisms of the same factor may be as secure as using two factors and lays out scheme A & B to discuss.
So here's my thoughts:
Wouldn't scheme A be more secure because you can't brute force it? Isn't that the whole point of having the second factor? All passwords can be brute-forced given enough time. Having the second factor removes that threat.
Of course, you could implement a strong password plus a kill switch after 10 bad tries, but that still relies on the user to implement safe password storage. And I generally think it's better to remove any responsibility from the end-user (especially if there's a convenience trade off).
Requiring users to carry/remember two username-password combinations for every system doesn't seem practical. Security will fail if users try to subvert it for the sake of convenience. And they will.
Usability needs to be a key consideration. A token/pin combination is a secure and easy-to-use way to beat the threat of brute-force attacks and poor password management. ...as is having a certificate installed on a particular PC and other second factor solutions.
Friday, February 20
Verisign's File Vault
Today, I configured my File Vault at Verisign's Personal Identity Portal.
Secure
If you read this blog, you probably know that nothing is 100% safe. And you probably distrust this type of offering. But, Verisign knows encryption as well as anyone. Verisign spun off from RSA (then RSA Data Security) in 1995 with some of RSA's public- and private-key cryptography technologies. They're really good at authentication and encryption which are exactly the two specialties I expect from an online storage vendor.
Convenient
They're giving you 2GB of storage space free - it requires Two-Factor authentication to get in and encrypts data on the back end. And it's an easy-to-use UI with no software install. It's probably a better option than backing up my docs on a USB key (subject to damage and loss) or using some other non-security-focused vendor.
Smart Business
I also like the business model. We all wonder how OpenID providers will make a profit. Verisign seems to be ahead of the pack in providing value-add to users. You get more than just an OpenID credential. You get strong authentication, secure storage, and a personal identity page (probably the least interesting, but still somewhat fun and on the right track).
So, they can sell 100 million tokens to customers who get real value above and beyond reducing the number of credentials they need to remember. And of course, Verisign can license this technology to banks, governments, or anyone else who wants to resell online safety deposit boxes along with secure two-factor authentication solutions under their own brand. Paypal already re-brands the token to protect their customer accounts.
I could easily imagine brick and mortar banks handing out tokens with every new on-line bill pay account and/or offering a virtual safety deposit box to every physical box customer. It's value for the customer and a business model that makes sense. I'd even pay for a new token every few years just to maintain a secure place to archive my important files.
I knew there was a reason I never setup that Amazon S3/JungleDisk account.
Secure
If you read this blog, you probably know that nothing is 100% safe. And you probably distrust this type of offering. But, Verisign knows encryption as well as anyone. Verisign spun off from RSA (then RSA Data Security) in 1995 with some of RSA's public- and private-key cryptography technologies. They're really good at authentication and encryption which are exactly the two specialties I expect from an online storage vendor.
Convenient
They're giving you 2GB of storage space free - it requires Two-Factor authentication to get in and encrypts data on the back end. And it's an easy-to-use UI with no software install. It's probably a better option than backing up my docs on a USB key (subject to damage and loss) or using some other non-security-focused vendor.
Smart Business
I also like the business model. We all wonder how OpenID providers will make a profit. Verisign seems to be ahead of the pack in providing value-add to users. You get more than just an OpenID credential. You get strong authentication, secure storage, and a personal identity page (probably the least interesting, but still somewhat fun and on the right track).
So, they can sell 100 million tokens to customers who get real value above and beyond reducing the number of credentials they need to remember. And of course, Verisign can license this technology to banks, governments, or anyone else who wants to resell online safety deposit boxes along with secure two-factor authentication solutions under their own brand. Paypal already re-brands the token to protect their customer accounts.
I could easily imagine brick and mortar banks handing out tokens with every new on-line bill pay account and/or offering a virtual safety deposit box to every physical box customer. It's value for the customer and a business model that makes sense. I'd even pay for a new token every few years just to maintain a secure place to archive my important files.
I knew there was a reason I never setup that Amazon S3/JungleDisk account.
Friday, February 22
Cold Boot Attacks on Encryption Keys
The EFF posted this article about a new found vulnerability in what they refer to as Popular Disk Encryption Technologies. After reading the details, it seems more like a vulnerability in File Encryption technologies -- these are the technologies that require a user to enter a password in order to encrypt or decrypt files and folders on the file system. The difference in my view is that the term Disk Encryption is usually used to refer to products that encrypt or protect the entire disk when it's shut down. This is important, though. File encryption is particularly important in shared use scenarios where you want to protect files or data from people who have physical access to your machine. What this tells us is that even if you log out or put the computer in sleep mode, someone can come along and run software to get the data that is stored in RAM which may include your encryption key (password). What they didn't say is whether other types of passwords or credential information is also stored in RAM. It's another argument for two-factor authentication where a password alone wouldn't be enough to carry out an attack on the data. At least, how I read it is that the password is what could be stored in RAM and not necessarily the protected data.
Monday, January 8
Yikkes! Bad Security
Dave Birch (Hyperion) posted about an administrator at a large financial firm who encourages his user population to tether their RSA SecurID tokens to their laptops. All I could really say is Yiikes! ...and I don't think I've ever used that word before. Imagine the look on his or her face when the CIO (or other IT manager) who approved the 2-factor authentication project in order to achieve greater security got that email.
Apparently, some of the employees of this organization complained about having to carry a token with them. I can understand that, but there are certainly other options -- think Blackberry or Mobile Phone token, software token, browser toolbar token, just to name a few. And even the latest token design is less bulky on your key chain if you elect to stay with physical tokens.
So, if this message gets back to the SecurID administrator who posted that message, please reach out to us. We can make life easier AND more secure. It's not an either-or scenario. These users can install a soft token on their mobile device and then leave their hardware token at home where they use it most.
The proposed tethered-token solution really minimizes the organization's security investment. And I can only guess that this practice would have a negative affect on a security or compliance audit.
[Addendum: Dave was pointing to another article.]
Apparently, some of the employees of this organization complained about having to carry a token with them. I can understand that, but there are certainly other options -- think Blackberry or Mobile Phone token, software token, browser toolbar token, just to name a few. And even the latest token design is less bulky on your key chain if you elect to stay with physical tokens.So, if this message gets back to the SecurID administrator who posted that message, please reach out to us. We can make life easier AND more secure. It's not an either-or scenario. These users can install a soft token on their mobile device and then leave their hardware token at home where they use it most.
The proposed tethered-token solution really minimizes the organization's security investment. And I can only guess that this practice would have a negative affect on a security or compliance audit.
[Addendum: Dave was pointing to another article.]
Subscribe to:
Posts (Atom)