Category Archives: Password Management

Next war on passwords

Google is the latest vendor to try to slay the password beast. I wish them the best, I really do. But password authentication hasn’t been the defacto security for this long without a reason.

Still, if any vendor has a shot it’s Google.

Enter the Migrator

One common business case we get is to migrate from various directory servers to AD. This is usually an issue of per user license cost but lower maintenance is also a factor. Companies are realizing that since they are maintaining AD anyway, why pay for and maintain other multiple directory servers as well? For employee accounts it usually doesn’t make sense to have the same account in two places and need additional processes just to keep them in sync.

There are several ways you can migrate directories. You could use a one-time import/export, a Metadirectory, or a provisioning system, but these approaches have several key drawbacks. One issue is that in most cases you can’t migrate the user passwords. Another issue that the migration may require custom attributes to be added to AD (try getting your AD team to agree to that).

But the biggest issue is that these directories exist for a reason. There are client apps, sometimes tens or hundreds, which rely on the information in the old directories. Most home grown apps written for one directory won’t be able to switch over to AD without extensive rewriting. Even commercial apps that support AD may require significant and disruptive configuration changes.

Enter the Migrator (obscure Disney reference intended)

A virtual directory can be your Migrator. The solution is to standup a virtual directory that merges your AD with the old directory into a single view that emulates the old directory. Run both directories side by side while migrating the accounts. When a password change is made the virtual directory can update both AD and the old directory with the new value, so after running side-by-side long enough, most of the passwords will have been migrated. Eventually the old directory can be retired.

This approach has two main advantages:

  • no changes need to be made to the client applications
  • no schema changes need to be made to AD.

There is a good white paper that covers this in detail on the OptimalIdM web site (no registration required).

Pulling LDAP

Mark Diodati sums up the recent SPML threads here. But one questions that needs to be answered, if not SPML then what? One alternative that has been put forward by Mark Diodati, Mark Wilcox, and others is the LDAP (or DSML) pull model of provisioning.

This model is to expose your user accounts via LDAP using a Virtual Directory (VD) instance exposed to your service provider. The service provider would periodically make calls to the VD to look for account CRUD operations.

There are several compelling advantages to this model;

  • LDAP is already a standard protocol
  • There are defacto standard schemas (the most common of which is the standard AD account)
  • This is really just an extension of a model that has already been embraced in the enterprise (look at how many apps can be AD enabled)

Could that be it? Is the solution to service provider provisioning really this simple? No, at least not without SAML. While this model shows promise there is a problem; passwords. If your enterprise is not ready to use SAML to authenticate to your service provider, then you are left with two choices; both unpleasant.

First you could just punt on passwords and force your users to manage their passwords on their own. This is no worse than the situation without any provisioning, but certainly not where you could be if you used a provisioning solution to push the passwords out to the service provider as needed.

The second is to expose your password hashes via your VD. If your service provider supports the same salting and hashing algorithms, then the passwords could be synchronized by copying the hash across. In fact the recent version of the Google apps dir sync utility claims to be able to do just that.

But think about this for a moment. If you do that then the service provider knows the clear text password to log into your network for every one of your users that actually uses the service. After all, the user has to provide the clear text password to the service provider’s login page to generate the hash value to compare to the hash you sent them. If that’s the same as the hash value in AD, then the service provider knows your AD password by definition.

Do you trust Google with the clear text AD passwords? I’m not picking on Google; there simply aren’t any service providers I would trust with that information.

Another alternative I have heard is that the service provider’s login page would make an LDAP bind call back to the VD with the supplied password to do the authentication. Again, that gives the service provider a clear text version of your AD password.

Are you sure you really want to do that?

But if your enterprise and your service provider can implement SAML, then the LDAP pull model looks a lot more compelling. I would be curious to hear from anyone that has implemented this or is thinking of implementing it. And if anyone is using the password hash sync approach, I would be interested in hearing about as well.

On a first name basis

Here is an all too familiar tale of someone who penetrated a company’s email system because of lax passwords:

The message, he says, included the Web address to Sapphire’s e-mail server and the recruit’s new e-mail address and password. Goldenberg says he logged on as the recruit and quickly figured out the log-ons of three other employees. Like the recruit, they used their first name as part of their e-mail address – and as their password.

Glass half full, and covered with prints

Dave Kearns notes the city of Bozeman is walking back its requirement that applicants supply user ID and passwords to all social networking sites. But then he closes with:

Just one more reason to drop the use of passwords in favor of a biometric authentication. Even Bozeman, I’d hope, wouldn’t ask you to leave your finger on file!

Is the glass half empty or half full? Either way it’s covered with prints, which you should think about before jumping into biometrics. Then watch the Myth-Busters fool several fingerprint readers with covertly obtained fingerprint samples. After watching that you probably are going to start feeling uneasy about fingerprint readers.

And it seems facial recognition systems can be fooled with pictures of the face blown up to full size.

I wouldn’t bet the farm on voice authentication either.

Forbidden Fruit

A recent survey from CyberArk reveals that a third of IT staff admit snooping on their colleagues:

More than one-third of information technology professionals abuse administrative passwords to access confidential data such as colleagues’ salary details or board-meeting minutes, according to a survey.

Data security company Cyber-Ark surveyed more than 400 senior IT professionals in the United States and Britain, and found that 35 percent admitted to snooping, while 74 percent said they could access information that was not relevant to their role.

In a similar survey 12 months ago, 33 percent of IT professionals admitted to snooping.

Of course this is a vendor survey so assume the usual caveats. But still this is a surprising number to me. Surely all of these people must realize that getting caught would be grounds for termination, for doing something that they are unlikely to get more than a voyeuristic benefit from. Is knowing how much your boss makes really worth getting fired over? It wouldn’t be to me.

Some just can’t resist the forbidden fruit I suppose.

Cheap and easy

Mark Dixon has an excellent point in this post on why we still use passwords:

It was ease of use, not a technology-driven obsession with safety,  that led to wide adoption of the seat belt.

I think we face the same thing with passwords.   Intellectually, it is simple to understand why we should get rid of passwords.   However, in practice, widespread adoption will be triggered more by ease of use than perception of safety.  When an easier method for authentication emerges, people will adopt it – not because it is safer, but because it is easier.  If that easier method is also more secure, voila!  We will have achieved our desired result.

While I agree with Mark’s point, there is an important distinction that is not getting made in this discussion, the difference between personal and professional accounts. And this distinction goes right to the heart of Mark’s argument.

For personal accounts (for example your Facebook, Yahoo, LinkedIn, or Twitter account) ease of use is the single biggest driver. People will not, in general, use another authentication technique that isn’t as easy as passwords. Actually it has to be easier than passwords by an order of magnitude or it won’t displace the incumbent technology. It also has to be understandable to the average user so they believe that it really is secure (one could argue this is really just another aspect of ease of use). Try explaining client certificate authentication to your grandmother if you don’t believe me.

Also, the sensitivity of the account really makes little difference. Most users won’t treat their on-line banking account any different than their Facebook account. Bank of America offers a SecureID option for their on-line banking. That should be a no-brainer right? I don’t have any numbers but I would be shocked if they were getting anywhere north of %1 adoption of SecureID by their customers.

For professional accounts (your PC, enterprise resources, or hosted service account) ease of use is not the primary driver, cost is. Cost is understood by most enterprises to mean the monetary cost of your credential plus the measurable cost to support you using it. I used the word “measurable” for a reason. Most companies don’t care how hard it is for you to understand and use a specific authentication mechanism if you are a salaried employee. That cost is hidden to them. On the other hand the cost to the company for you to call the help desk if you have an authentication problem is measurable and tracked along with the cost to issue new credentials when needed.

For both personal and professional accounts, passwords rule the roost because they are easy to use, cheap to deploy, cheap to support, and easy to understand.

But if an authentication mechanism becomes popular that is cheap to deploy and support, it may have a chance to displace passwords for professional accounts.

Jeff’s OpenID account gets hacked

No, not me (at least not me so far as I know). The Jeff in question is Jeff Atwood of the Coding Horror blog (one of my favorite dev blogs). Jeff relates how his OpenID account was hacked here and here. It’s fascinating reading, especially because the hacker was of the friendly sort who apparently just did it to point the vulnerability.

The hacker was able to obtain the unsalted hash of Jeff’s password on a different site. He then looked up that password using one of the reverse hash web sites available. He then guessed Jeff’s OpenID provider and tried the password there. Since Jeff had used the same password in both places, the hacker was able to log into OpenID and impersonate Jeff at Jeff’s StackOverflow web site, which depends on OpenID.

Here is an interesting question: is it dangerous to reveal your preferred choice of OpenID providers? I suspect there is nothing dangerous about, given peoples propensity to flock to one of the big players anyway. Even if there are a plethora of OPs, the bad guys will just script a solution that tries a list known OPs until a hit is made.

A good question indeed

Mark Dixon responds to this Dave Kearns article comparing passwords to buggy whips by posing a very good question:

The big question is, “Replace username/password with what?”

I personally like the use of secure certificates, as illustrated in Henry Story’s use of certificates in his demonstration iPhone app I blogged about recently.  However, the mechanism for distributing, installing and managing such credentials for ordinary computer users seems like a daunting task.  I also personally like the Information Card concept, at least for the conceptual metaphor it uses.  But that isn’t a raging success and this technique is certainly burdened by its own challenges.

This is a question that is not asked enough, much less sufficiently answered. All of the competing approaches suffer from drawbacks that make them less acceptable in many cases.

Like Mark I also think highly of certificates as the solution. But there are significant lifecycle deployment issues that are too daunting for most users. There is also another issue that does not get enough attention, physical security. When using a certificate you are really dependent on the physical security of the container holding the private key. If it’s a smart phone in your possession, great. If it’s a laptop in your possession, also great. If it’s a beige box sitting unsecured in your cubicle while you are at lunch, not so great.

Information Cards are a good solution, but also suffer from the same physical security issues. Of course the card can be PIN protected, but a PIN is really just another password (albeit a local one) and now you get into some of the same issues as with passwords, for example the PIN for less frequently used cards written on a yellow stick attached to the monitor.

Biometrics is a hot area of research now. It seems every week some new breakthrough in earlobe recognition or some other phrenological magic is announced. But as of yet there are just too many problems with biometrics to displace passwords.

If cost is no issue OTP devices are a great way to go. But cost is always an issue.

Password authentication is like an impressionistic painting. The farther you move away from it, the better it starts to look.

Tightly coupled vs loosely coupled in the enterprise

Ping Identity’s Andre Durand makes some interesting observations about internal IdM vs Federation projects in the enterprise:

What’s interesting about our conversations is that invariably, they talk about one or more of their internal provisioning, IdM or WAM projects that is basically not meeting their expectations. What I find interesting about this is that federation deployments, by their very distributed nature, are taking an entirely different approach. Most if not all centralization projects are large, costly, complex and long. This makes them inherently more risky, and introduces higher and higher probabilities of failure at one or more levels.

He is absolutely right that centralization projects typically larger, more costly, and just plain harder than federation projects. Centralization is harder because it creates tight coupling between systems where as federation creates a loose coupling between systems. And tight coupling of systems made by different vendors (and often the same vendor) can be very hard and risky.

So Federation (loose coupling) is always the best way to go, right?

No. It’s often the best way to go but there are many times that tight coupling simply must be done. Often that means using a provisioning system and a means of synchronizing accounts (IBM TIM, Sun SIM, MS ILM, etc). Sometimes that means configuring your systems to centralize the identity (Quest Vintella,  Centrify, etc).

And here is where I will let you in on the dirty little secret of provisioning. It’s really all about deprovisioning. Typically enterprises don’t care if it takes weeks for you to get access to all of the resources you need to do your job. They care in the abstract (usually), but not enough to actually do anything about it. But the minute your employment is ended, your access to all your enterprise resources needs to be turned off.

And for that you need centralization of some sort.

Of course I have seen plenty of cases where systems are tightly coupled from an identity standpoint but loose coupled from and authentication standpoint. This is where the two systems share synchronized or centralized accounts, but are SSO enabled via federation. One common use case is using federation to bridge different vendors WAM solutions.