Monthly Archives: April 2010


By now you probably know the sordid case of the lost iPhone and the ongoing Apple-Gizmodo spat that culminated in the recent police raid on a Gizmodo editor’s home. The raid raises two very interesting and troubling issues. The first concerns state and federal journalist shield laws and how they apply to online journalists like Jason Chen. That deserves a separate treatment that I will defer to a later post.

The second issue is why the police descended on a home in mass to break down the door and cart away six computers in what is essentially an intellectual property dispute between two corporations. The reason, it turns out, for this strange action on the part of the high-tech crime task force is that Apple sits on their steering committee.

Meet the iPolice, Apple’s very own IP enforcement squad with handy police state powers.

When you make a call and have the police break into a citizens home and confiscate his possessions, doesn’t that qualify you as an evil corporate behemoth?

Full disclosure: I don’t own any Apple products. At this rate it not looking like I ever will.

Open source C# SPMl v2 implementation

Softerra has released an open source C# implementation of SPML V2 (DSML profile). I haven’t had time to play around with it yet, but it looks interesting.

Now what would be really great would be some developers to take this and create some implementations that do useful stuff. For instance write a service provider for provisioning and reconciling AD accounts. Or perhaps integrate it with Microsoft FIM.

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?


The Washington Examiner calls out Apple on it’s hypocritical Cap and Trade stance. They point out that Apple is calling for Carbon Taxes that it will largely avoid paying due to it’s offshore manufacturing.

Shifting out of neutral

A three judge panel in Washington DC has ruled that the FCC does not actually have the authority to impose net-neutrality regulations. This is a big victory for the free market internet, but I have no doubt that the Obama administration will respond by trying to enact net-neutrality via legislation.

One wonders how we have managed survived so far without it.

You have already agreed to be monitored

Steve Chapman poses the question, “would you volunteer to carry a device that lets the police monitor your location 24×7, every day?” He then lets you in on a secret, you already have. In fact chances are you have the locator on your person at this very moment.

It’s called a cell phone.

Just think of the privacy implications here. The government can tell if you spend the night at someone elses house, visit a red light district, attend a political rally, drive too fast, or get a medical procedure. They can know where you are at all times, both when you are out in public or when you are in a private residence.

Oh, and the current administration (like the last one) doesn’t think a warrant should be required for any of this.