BrowserID a Threat to Individual Freedom?

The folks at Mozilla recently introduced BrowserID. You can compare it to OpenID, but there are some key differences. The basic idea - a single set of authentication credentials across multiple sites and simplified logon to each as facilitated by the browser. Ian Yip took an interesting look at BrowserID from the an Identity Management industry perspective and how it relates to what we call identity federation. For more details on how it works, check Lloyd Hilaiel's post.

But that's not what I wanted to write about. I'm more interested in SC Magazine's article headlined Mozilla BrowserID "seriously flawed" and Roger Clarke's Reaction to Mozilla's BrowserID Proposal, which was the subject of the SC Mag article. My first point is simply: go read it. It gives you a lot to think about. My second point, though, is a little more complex.

Clarke makes some interesting and compelling arguments about Internet privacy and individual freedom. I can't say that his logic is incorrect or that his points are invalid, because they're not. But his anger (characterized by phrases like "seriously flawed 'identity management' schemes" and "its design is seriously threatening to individual freedoms") may be a bit misplaced.

I agree with Richard that BrowserID is not THE solution to solve the Internet's authentication and privacy problem. But that's not the challenge that Mozilla has sought to solve. Not every site that requires a logon is a major privacy risk. I have probably 50 or more web site accounts to manage and I welcome solutions to my credential management problem. I'm a security guy but I will gladly introduce some level of risk to make life easier when browsing a large number of those sites. We all do to a degree. e.g.) It's less risky to go to a library anonymously to look something up in a book but the Internet at home is just so much more convenient that we risk being eavesdropped or introducing malware to our systems every time we use it.

It reminds me of the old argument that two-factor authentication is useless because it's susceptible to MITM attacks. BrowserID won't be a silver bullet for all authentication scenarios and maybe not even for ANY scenarios that require high security or strong assertions about the user, but it could still be a useful way for end-users who want to simplify the logon process. Claiming that BrowserID is seriously flawed because it doesn't address issues outside of its own scope just seems wrong and even somewhat irresponsible. The IT industry's version of media sensationalism maybe?

I don't mean to pick on SC Mag - the title got me to read Richard's article, which is the purpose of a strong title, but I'm pulling for one of these solutions (OpenID, CardSpace, BrowserID) to make it into the mainstream so that my life will be a little easier. And creating hysteria and FUD around them doesn't help with user adoption.

The RSA Breach

[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.

Business Case for Claims-Based Authorization

Jackson Shaw provided a great use-case for claims-based authorization this week. While I've always seen the value of the claims-based approach, I've always felt that the thing that's missing is the motivation. End-users and consumers are typically motivated by what is easier or cheaper. Corporations, similarly, are motivated financially and not, as we might hope, by security or privacy as an end in itself. But his example, which applies to any major corporation who gives discounts based on employer (hotels, car rentals, wireless phones, etc.) shows that there are millions of dollars on the line.

$$$ = motivation

It might be just what corporations need to push them toward adoption -- and that includes providing incentives for customers to move to a claims-based model. I think mobile phone companies are situated perfectly - they can provide the authentication mechanism built into the devices they sell, which makes it potentially easier for users to browse the web (could solve the 'numerous passwords' problem) - remember:

Easier = motivation

...and they have a huge financial motivator because many big companies negotiate mobile plan discounts for employees.

But perhaps budgets can be pooled together by a consortium of companies that are losing money to create a compelling solution that end-users will want to adopt. And in the end, we'll see better security and privacy as a result.

Identity as a Platform

I was asked for my thoughts on an article titled Hosters Need to Think about Identity as a Platform Play. When I clicked to read the article, I was happy to see it was written by Novell's Dale Olds who always has interesting and informed things to say.

I agree with Olds' assessment. SaaS platform vendors (hosters) should really get on the ball with offering identity services as part of their hosting packages. They should do similar with data encryption as well (both to the endpoint and in storage). Security is complicated -- extremely important and extremely easy to get wrong. It only takes a small oversight somewhere along the line to break the chain. SaaS application vendors would be wise to leverage proven, trusted solutions for access management rather than trying to create their own.

I think Olds overstated how simple it would be for applications to switch platforms. It seems to me that it's pretty complicated even in the case of moving a simple PHP website to another host. And most SaaS applications will be much more complicated than that. And the other part of that thought was that providing identity services would tie-in the application provider to that platform. I would recommend to hosting providers that they make it easier rather than harder to move. That'll be a key differentiator and ultimately drive more business/revenue to your brand. (I'm not saying that Dale was recommending to purposely make it complicated - it's just how it is.) BUT - there's still a business driver to build identity into the platform. Removing the complexities of security from the application development process could save 30% of time and resources in standing up a new application versus having to build it all from scratch.

And to Steve (from Axciom)'s point (in the comments), yes! Ideally, Platform as a Service vendors will provide more than authentication. Baked in security could incorporate firewalls, authentication, multi-factor authentication (& transaction-based), authorization, encryption (in-motion and at-rest), activity and access audit, SoD monitoring, and more.

We're obviously very early in this whole process. I think we're moving in the right direction, but it'll take time to get it all right.

IAM in the Cloud - from Verizon and Novell

Interesting newcomer to the Identity in the Cloud space. I look forward to seeing a side-by-side comparison of these solutions. Clearly, when organizations are ready to have their identities managed outside of their own walls (even if just external accounts), there will be a number of options available. I see an opportunity for a few good independent consultants to really understand the intricacies of all these options so they can help customers wade through all the terminology and misconceptions. ...because I don't think it'll be easy.

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.

Provisioning to the Cloud

I posted recently about identity in the cloud. Many identity vendors are doing interesting things to get their solutions 'in the cloud' or available 'as a service'. It's a lot of buzz, but there's also some actual cost savings and operational efficiencies at the bottom of these efforts.

Today, Optimal IdM announced their cloud provisioning solution. Similar to what Identropy is doing with IC2, Optimal IdM's solution leverages existing provisioning solutions and acts as a connector to cloud applications.

This use case of acting as a connector for remote, unknown, complex, or varied systems is a perfect fit for virtual directory technology. MaXware released a similar connector for Salesforce in 2006 while I was still an employee. Perhaps they were ahead of their time? The virtual directory solution can be added to virtually (no pun intended) any environment and provide immediate connections up to numerous, complex cloud systems, thus saving cost and effort as compared to developing custom connectors.

Having said all those nice things about the virtual directory approach and once again encouraging IAM integrators to consider virtual directory solutions while whiteboarding on how to meet requirements, I should be fair and point out an alternate viewpoint. If you already have a provisioning solution from the likes of Courion, Novell, Oracle or IBM, and a requirement to provision to cloud applications, you owe it to yourself to take a close look at Identropy's IC2 offering before making any purchase decisions. That's exactly what it's designed to do.

Another interesting note - I spoke to someone from Arcot today (think secure token-less authentication) who informed me that all of their solutions for secure authentication are now available as a service. They already have one of the most widely deployed authentication-as-a-service solutions on the market, so it seems to be a natural migration to offer their other solutions from the cloud as well.

Who recently said there was no more innovation in the IAM space? The latest innovation in this space is in direct response to the market complaints that IAM is too complex. Once simplicity is realized, innovation will no doubt trend elsewhere. I call that a success in meeting customer demand.

Identity in the Cloud

Over the past year, there have been a number of identity management solutions popping up that aim to help companies deal with identities in Software-as-a-Service (SaaS) / Cloud applications. Here's a list of the solutions that I've encountered:

Cloud Identity - SaaS Identity and Access Management solution. Provides provisioning, workflow, audit reporting, and SSO. Leverages existing enterprise credentials. [more info]

Conformity - SaaS Identity and Access Management solution. Provides provisioning, workflow, and audit reporting for select cloud applications. Leverages Active Directory (or other on-premise repository) accounts as the source. [more info]

Identropy IC2 - Identity Management solution for SaaS applications. Leverages existing Identity infrastructure and work flow to provision accounts to cloud applications via the IC2 SPML gateway. [more info]

MyOneLogin - SaaS Identity and Access Management solution. Provides SSO and Secure Logon to cloud applications and web sites. Enables Account Management for select SaaS applications. Tracks SaaS application usage across apps from a single location. [more info]

Nordic Edge Opacus - SaaS Identity and Access Management solution. Provides Secure Logon to cloud applications. Synchronizes accounts from on-premise repository to cloud systems. Enables delegated user administration for cloud applications. [more info]

PingConnect - SaaS SSO solution for Salesforce CRM, Google Apps, and 60+ other SaaS applications. Leverages existing enterprise credentials, Google Apps Logon ID, or Salesforce credentials. [more info]

SecurAct - SaaS Identity and Access Management solution. Provides provisioning, work flow, SSO, and audit reporting for both local and cloud applications. Leverages Active Directory accounts as the source. [more info]

Symplified - SaaS Identity and Access Management solution. Provides provisioning, audit reporting, authentication, and SSO across local and cloud apps. Leverages existing enterprise credentials. Can also prevent side-door access. [more info]

NOTE TO VENDORS - please feel free to reach out if my description above is incorrect. I'm happy to make corrections where appropriate or provide additional differentiators. I also encourage comments that help identify how products stand apart from the others by end-users or vendors.

[Updated Aug 04, 2009]
[Updated Jul 29, 2009]

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:

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.

ADAM Pass Through Authentication to AD

A few years ago, I wrote a post that referenced ADAM passthrough authentication to Active Directory without providing much info. Since then, people searching on that topic have found themselves on my blog (probably hoping for more information). So, I thought I'd cover it in more detail.

Disclaimer:
I haven't actually done this in a few years, so my information may be out of date, but I'm sure someone will speak up if I'm wrong. ...they always do ;) I will assume you know what ADAM is, why you'd use it, where to get it, and how to install & configure it.

Why:
A few quick scenarios where pass through authentication is useful:

1. You want to put a portion of your Active Directory users into the DMZ for authentication by publicly-facing applications, but you don't want to expose an AD DC in the DMZ. In this scenario, the app can leverage a DMZ'ed ADAM for authentication. ADAM will still need to make a request to a DC, so AD is partially exposed, but in a more controlled way.
2. You want to leverage AD credentials for application authentication, but the app wants to store information about users that is not currently in AD and you don't want to extend the schema. You could stand up an ADAM instance, extend its schema however you want, enable passthrough authentication, and point the app to ADAM instead of AD.
3. You have an app that is used by people that have an AD account AND people that don't. And your app only accepts a single authentication store.

Here's what you need to know about using ADAM for pass through authentication to AD:

• The ADAM installation process gives you the ability to import the schema for UserProxy objects from a file called ms-userproxy.ldf – you'll need to import that object to enable the passthrough functionality. You can do it after the install if you need to.
• For an account to perform a passthrough authentication (aka a bind redirection) from ADAM, the account must be configured as a UserProxy object. A standard user account can not authenticate through to Active Directory.
• The UserProxy object has an attribute called ObjectSid, which is critical to this functionality. For passthrough authentication to work, the account's ObjectSid must be populated with the SID of the associated Active Directory user account (this will actually work with any security principal object).
• When a UserProxy account attempts to bind to the ADAM instance, ADAM recognizes the account as a proxy and forwards the authentication request to Active Directory.
• Passthrough authentication only works for accounts that live in the forest to which the ADAM server is joined (or to a trusted domain or forest). So, that's how ADAM knows where to send the request.
• Passthrough authentication only works with simple binds. So, the password is being passed to ADAM in clear text. You'll want to be aware of that and use SSL as appropriate.

That's pretty much all you need to know to get passthrough authentication working. As I recall, it's that simple.

Comments/Corrections:
PLEASE leave a comment if you're here because you want to do this for a reason I haven't mentioned above or if you have additional information. Am I wrong? Did I leave anything out?

More Information:
Microsoft refers to this as Bind Redirection for ADAM Proxy Objects. So, that's the terminology you'll want to use to find more information.

Know what you're protecting against

You know that advertisement where the CEO (Todd Davis) gives out his social security number and tells you how secure it is because he uses his company's product to protect his identity information? Well, there have been 20 people who used his social security number to get a drivers license. And there was one "guy in Texas who duped an online payday loan operation last year into giving him $500 using Davis' Social Security number".

Today, I read a few articles (including this one and this one) that suggest that LifeLock should be chastised because it doesn't protect you against everything that one might think it should. My first reaction was to agree with the writers. I always knew there was no way for a product to protect your SSN against any or all unwanted uses. And they shouldn't claim it does. And ha ha for Mr. Davis' identity being compromised.

But, then I read Davis' rebuttal, "There's nothing on my actual credit report about uncollected funds, no outstanding tickets or warrants or anything" and I realized that this isn't really a case of a product not doing what it claims to do. It's a case of mis-aligned expectations about what a product can (or should) do.

It reminded me of all the times I've heard that some strong authentication technique isn't effective because it's susceptible to man-in-the-middle techniques. Sure it is, but that's the wrong problem. SSL was developed to solve that problem. There are certainly issues with SSL (mostly around user experience and education about how it works), but strong authentication is not the answer.

In the same way, there are problems with relying on SSN as authentication. And LifeLock won't protect against that. But, if it keeps your credit report clean, then maybe it's doing what it's supposed to. I haven't really followed the ads and I have no idea what the company promises its customers, but I thought I'd use this opportunity to remind you of the old cliche – there is no silver bullet. Analyze your risks and know which types of threats a security solution will be effective at protecting you against.

Correctly aligned expectations yield happy customers.

The SecurID Killer

I'm a fan of RSA's SecurID product. It's got a highly secure approach, nearly indestructible hardware form factor, lots of form factor options, tons of partners and coverage for apps, servers and devices, and a flawless track record. But the competition has been creeping up.

Some try a similar approach to RSA with key fobs displaying numbers or other hardware tokens:

ActivIdentity
Aladdin Knowledge Systems
EnTrust
CryptoCard
MyPW
SecureComputing
Vasco

Others have a software only approach:

AdmitOne (formerly BioPassword) - uses keystroke dynamics
Arcot - uses PKI
PassFaces - uses user's ability to remember human faces
PhoneFactor - uses mobile phone as the device

Some are biometric:

DigitalPersona
L-1

And they all have redeeming qualities. But many are susceptible to keystroke logger attacks (which are getting more and more sophisticated). Others are cheaply made hardware. Some just lack partnerships and market penetration.

But there's a new kid on the block. And it seems to be a very cool solution that may quickly become a force to be reckoned with. It's a very small form factor, seemingly very secure, extremely easy to use, requires no client software, inexpensive, and works on any platform.

Welcome YubiKey to the arena.

I'll let you figure out the details for yourself.

It won't allow you to converge a single credential for physical and logical access and it won't work across multiple systems (unless it's used with OpenID or something like that) and it won't serve as a single form factor for multiple uses (like signed email and remote VPN). But, it's a pretty cool new entrant to this arena. And that's a feat in itself.

Let me know if I missed your company and you'd like to be added to the list.

User-Centricity in the Enterprise

Most of the on-line discussions about Identity Management over the past few years seem to have been about consumer authentication. The industry has developed solutions for user-centric authentication models. I'm not going to go into detail here or try to define those models. But, now that OpenID and other technologies has brought the user-centric model to reality, I'm beginning to see more chatter about user-centricity in the enterprise.

Patrick Harding doesn't seem to think that the enterprise is the right place for a user-centric model. I agree. I also agree with Pamela Dingle who noted that user-centric technology may be useful in an enterprise for the purpose of users keeping some information up-to-date.
I would qualify that, though, by saying that it's only going to be the information that the enterprise decides is unimportant enough to leave in users' hands. Companies never allow employees to update critical information on their own -- job title, pay grade, SSN, email address, etc.. Nor do they allow employees to decide what information they choose to share with the company's HR department. Companies require forms to be filled out completely. And if there are blank spaces, there's often warning that it could be just cause to rescind the employment offer.

Nishant Kaushik doesn't seem to think that the user-centric model is right for an enterprise environment. And Johannes Ernst disagrees.

I've been thinking about this for a while and I'm with Patrick and Nishaunt on this one. The goal of user-centricity is to give control of their identity information to the end users. That's great in the consumer world. Enterprises, however, have been spending millions on Identity Management specifically so that they (the enterprises) can control identity information more effectively. In the consumer world, it makes sense for people at home to want control over their information as it travels across the Internet. But, in a corporate environment (or government or education) employees and associates don't have rights over their identity information. Since Johannes is the one I've seen to recently claim otherwise, I'll look at his comments.

First, he talks about potential customers. For most enterprises, potential customers are anonymous or simply contact info and notes about whatever the enterprise can learn about their interest in the company's product. He talks about current customers and their desire to use user-centricity when interacting with the enterprise. OK, I can see that point, but that's not really enterprise. To me, that's still a consumer solution.

He then talks about affiliates. This is the typical use-case for Federation. Since this is about business transactions, the most important component of the federation model seems to be the non-technical stuff -- business agreements, contracts, terms of use, processes, etc.. It's not a scenario where you want one business partner to decide to withhold information from the other for the purposes of privacy or information control. Affiliates don't tend to share personal information, but business account information and transactional information that are both critical to the transaction in process.

Finally, he mentions user-centricity within an enterprise's own internal systems. Specifically, he gives the example of a personal cell phone number. To me, that's not enterprise data -- you can manage sharing your personal contact information with friends and close co-workers through social networking sites. Company-sponsored cell phones and IM addresses should be part of the corporate identity management infrastructure. Employees may be allowed to keep information up-to-date, but they're not allowed to decide which managers can view their information and which can't. The company makes the decisions about information use.

I don't know if I'm "defining away the issue of user-centric identity in the enterprise", but I don't see any major value or realistic adoption of a user centric model within an enterprise. The examples presented in the argument for it seem to be consumer scenarios and not enterprise scenarios. If you're expected to be available at 2am, then it's the enterprise who controls where your cell phone number is posted for anyone who needs to find you.

Let me be clear. I'm not bashing Mr. Ernst or trying to minimize his argument. He's obviously an intelligent guy and has contributed a great deal to the industry. But I'm challenging him and others to give me better examples of where the user-centric model may be useful within the enterprise. Because right now, I don't see it.

Internet InSecurity

I stumbled across this today

and thought it was pretty cool idea. Use a 3-minute video to educate employees on the dangers lurking in their inbox and reduce your enterprise risk. Nice and simple. And free.

Then, this evening I saw this

IRS employees giving out usernames and passwords to someone who called them on the phone and didn't even attempt to identify themselves. Why worry about password hacking techniques when all you need to do is call up Jerry or Sally at the IRS and ask them to change their password so that you can use their account? Well, at least the IRS doesn't have any sensitive information in its systems. (pardon the sarcasm)

And I remembered this

People don't even bother to look for the security mechanism (SSL icon or the HTTPS in the URL) when it's present so they can conduct their Internet banking.

And I recalled the old adage

We made it foolproof and they produced better fools.

We really have to take users out of the equation and make the security mechanisms invisible. Or make it impossible for them to accomplish a task without taking proper precaution -- like maybe build a browser that doesn't accept any form input unless the site uses SSL with a trusted certificate so the user doesn't need to think about that stuff. Of course, even that won't stop the old phone-call-password-change gag.

It makes you wonder about all the work being done on the identity metasystem for a secure Internet. Putting users in charge of their own information sounds dangerous. Are Jerry and Sally going to take their secure infocard with SSN and credit card info and send it to any site that asks for it? After all, why create more than one card? - that sounds like work.

As a society, we seem to have a massive mental block related to digital security. Maybe we need public service announcements on TV and radio about digital identity theft and secure password management. I think it'll be another decade before the Internet security issue is really figured out for the masses. Unfortunately, it may take that long for general knowledge about computer security to infiltrate society and for the security technology to meet people half-way with making security transparent.

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.]