Tag Archives: Authentication

Familiar Ground

Johannes Ernst is predicting the demise of the RDBMS (and by extension Oracle) due to the growing popularity of NoSQL. While these kinds of technology trends are hard to predict, there is a lot of logic to what Johannes is saying. He could very well be proven prophetic.

But this is familiar ground. We have been here before.

I remember in the mid 90’s when Object Databases were going to kill the RDBMS. Of course what really happened was that Object-Relational-Mapping APIs became popular instead.

Later XML Databases were going to kill the RDBMS. Instead RDBMS vendors added native XML capabilities to their mainline products.

There are specific functional areas where RDBMSs have been displaced. For instance LDAP directories have mostly replaced RDBMSs for identity and authentication information.  But this has not dented overall RDBMS usage.

So can NoSQL slay the RDBMS after OO and XML failed? Perhaps, but I wouldn’t short Oracle just yet.

Advertisements

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.

Orcs in space, with one time passwords

My oldest son recently attended a games design summer camp (for 5-6 graders) and one of their tasks was to design a StarCraft level. As a result he become quite addicted to StarCraft as did my middle son. It’s very interesting watching your children take to a computer game that is older than they are.

So I was looking around the Blizzard site trying to find out when StarCraft 2 is going to be released, and I came across this, a one-time-password authentication token for securing your on-line game account for the various Blizzard games. It doesn’t explicitly say it, but I am guessing it’s SecureID, although there is the possibility it is an OATH based system.

I am sure that only a small percentage of gamers use it, but I was pretty impressed. Many financial sites still don’t offer OTP protection, but you can get it for your on-line gaming account.

It’s all a matter of consumer priorities, I guess.

Flashers

It looks like Flash cookies, which are really old news, are back in the news (via Bruce Schneier). This form cookie is particularly insidious because it does not honor the cookie policies of your browser of choice.

This Wired article decries the practice of using flash cookies as a “backup” in order to recreate cookies the user has deleted. In fact if you use the BofA online banking web app, that’s exactly how the SiteKey knows your computer is the one you normally log in from. If you attempt to access your account from a different computer it will not detect that web cookie or Flash cookie and force you to answer additional challenge questions.

BTW if you want to know what sites have dumped these critters on you, Adobe has a Flash cookie manager plug-in which you can find here.

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.

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.