Tag Archives: Google

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.

Advertisements

There is always my way out…

Google’s new privacy policy is generating a lot of discussion. The controversial part is that Google is going to cross reference the data it collects on different services for the purpose of tweaking the ads and search results you see.

The creeps a lot of people out. What creeps them out even more is that you can’t opt out.

Of course there is always my way out… (cue lightning flash and creepy James Earl Jone laugh).

Seriously though, don’t use Google services exclusively. Use Bing instead of Google for searching. Use Yahoo instead of GMail. Buy an iPhone, or if you want an Android phone, create a new email account just for phone use. Use Facebook instead of Google+.

If you give one company all your data what do you think they are going to do with it?

You ultimately have control over this in your choice of providers. You can opt out by switching.

Stealing the keys to the kingdom

There are some interesting tidbits coming out about the Chinese hack of Google. Apparently the source code to Google’s SSO technology was a target (although this is misstated in the headline as a “password system”). It’s unknown at this point what source code (if any) was taken, but this highlights the nightmare scenario of the SSO world.

If a vulnerability is found in your token generation code such that someone can spoof a token, then your SSO system and every system connected to it is compromised.

Of course just having the source code is not in itself a problem. Typically there is a private key that is used to encrypt or sign the token. But protecting that private key is the issue and that is where the source code is key. If you think your key has been compromised you can replace it. But the code that authenticates the user and generates the token needs to get the private key to do the encryption (or signing (or both)). If the secret algorithm to access that key is compromised, then the attacker can then attempt to penetrate the system where that key lives and get the key. With the key and token generating code in hand the attacker can then access any SSO protected system.

And here is an ugly secret. If the SSO technology is public key encryption, they key on needs to exist where the token is initially generated. If it’s based on symmetric key encryption then the key has to exist on every server in the SSO environment.

So just use public key encryption, that solves the problem right? Not so fast. One critical aspect of SSO is inactive session timeout. That requires the token to be “refreshed” when used so that it expired based on inactivity. Refreshing the token at every server in the SSO system (every PEP if you will) requires either that server to have the key, or it make a remote calls to a common authentication service to refresh the token.

There are pluses and minuses to both approaches. One puts the keys to the kingdom in more locations but the other adds overhead to the token refresh. When security and performance collide, who do you think usually wins?

These kinds of trade offs are what make SSO so interesting to me.

Note that I am not talking about federated SSO (SAML or openid) or intranet SSO (Kerberos) as they present a different set of challenges.

I thought xauth was a Unix command…

Axel Nennker is calling out Google and Meebo for the privacy aspects of the new XAuth spec.

Peter Yarid has some thoughts here, but criticizes it more from a business than privacy standpoint.

Techie-buzz has this candidate for the understatement award:

There are of course privacy implications because not every user would want every website in the world to know what social networks it uses.

Gee, you think?

Just a bit more complicated than that

Phil Windley posts about Google’s recent moves in China and describes them as a result of conflict between Google’s desired to do what’s right (not censor) and doing what it needs to do to stay in business in one of the largest markets in the world. That’s an interesting take on it, but it doesn’t wash with recent history.

To be clear, Google was fine with doing evil for several years now. The lived with the government restrictions and did business up until recently when they were penetrated (reportedly badly) by hackers that no one seriously believes aren’t at least backed by the Chinese government. Also the decision to buck the government was also made easier by Google’s own lagging competitive position in China.

If the real story ever comes out I’m sure it will be fascinating. Until then I’m not sold on Google’s altruistic motives in this dispute.

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.

MAD, MAD, MAD, MAD World

Nico Popp suggests that incidents such as the recent Google hack may lead to governments and large corporations adopting a form of Mutually Assured Destruction cyber defense.

On one hand there is a lot of sense in this, especially for governments. However I suspect retaliation would be more of a economic (or worst case military) nature.

At some level that’s exactly what is going on with the Google case. Google obviously believes that the Chinese government is behind the attack and Google has retaliated by threatening to stop censoring content in China, even at the risk of getting thrown out of the country. Of course now they seem to be backing down and both sides are now looking for a face saving compromise.

But one problem with the MAD theory of cyber-warfare is that you most often don’t have any idea who to retaliate against. At least not with sufficient degree of certainty.

So for now, MAD looks pretty unlikely in the cyber-warfare game.