Outrageous Claims Part 1: It's All About Trust

In the summer of 2011, I did a series of blog posts and a presentation at SharePoint Saturday: The Conference in Washington DC which were called "Real World Claims". My goal was to talk about the good, bad, and ugly of settings up claims authentication in SharePoint.

In 2013, we now have a new version of SharePoint and an improved
version of ADFS in Windows Server 2012. There are more products on the market that are supporting claims authentication through SAML, and technology folks have gotten better at configuring claims - and if I had to guess based on the web analytics, I'd say that my blog articles probably played a part in that.

There's also been much revelation regarding the activities of agencies such as NSA and GCHQ which threaten to undermine the public's trust of Internet security standards in general. It's important to understand that the security of claims authentication is largely dependent on SSL, and therefore whatever the outcome of shifting in this space will have a direct impact on claims, both from a technical and a business point of view.

All that being said, it's time to revisit claims authentication in light of these things. Tonight I am presenting at the local BSPUG, and in the coming weeks and months I am going to be devoting more of my time to blogging so I can update the old information and provide some new insights on this topic.


So, today it is my great pleasure to introduce you to the first chapter of Outrageous Claims. Why did I call it that? Is it because my kids all think I've been to the moon, and that the Kraken started the Great Fire of Baltimore? Well, maybe. The answer will reveal itself in time, but for now a brief description will suffice.

DISCLAIMER: The examples in this article are purely hypothetical. I do not hold a security clearance, because the government thinks I can't be trusted. So, I only know what I read in the paper. If it turns out to be true, "don't Taze me bro!" Also, that Google search I did the other day about carbon tetrachloride and aluminum powder was because I was curious about something I saw in an anime and not because I'm trying to make explosives. Also, in my defense, I may have pirated that anime from BitTorrent, but only after I'd rented the DVDs from Netflix first, so it's time deferred viewing. Just sayin'.


At its heart, claims authentication is about trust. You trust me to tell you the truth, and I'm telling you that my user name is Thomas Carpe and that my phone number is 410-633-5959. Actually, it’d be a claims provider that's telling you these two things about me, so I guess you also trust that claims provider too.

In most claims configurations, this trust is represented by an exchange of certificates. Your system that consumes claims gives a public key certificate to a claim provider. In exchange, the claim provider gives your consumer a public key certificate too, so that they both know they're talking to each other and not somebody else. The login page for the provider gives an SSL certificate to me when I log in, so that I know my username and password aren't being sent all over cyberspace in plain text, and so that I know I'm really using Windows Live ID and not somebody pretending to be Microsoft who's cleverly replaced my DNS server or something.

There's also an implied trust that both I the user and the claim consumer have about the provider. I believe that my identifying information will be safe - or at least I want to believe - and that my password, e-mail, and phone number will not be stolen (or sold) to hackers, spammers, and other ne'er-do-wells. The consumer wants to believe that the provider has done enough due diligence to be reasonably sure that I really am who I say that I am.
So what happens when our trust is tested?

My favorite example is to say that sometimes Dan Usher might be feeling spunky and decide one day to login to the SPSEvents web site using a fake account he's created as Scott Hoag on Google. He plans to login to the web site for SPSDC and post a funny message posing as Scott and telling everyone that he's giving up SharePoint work so he can go into the beer making industry. But, he needs to get the admin to grant him access to do it, thus the charade.

That's actually a pretty easy thing to do. Back in the early days of claims AuthN and Open ID, providers used to be willing to give up information like an email address, which would have gone a long way toward figuring out that our fake 'Scott' is actually sending his email to "usherbot@gmail.com". For complicated reasons, providers aren't willing to give this information up so easily anymore, which actually makes it easier for Dan to play his trick and harder for our system to realize what's going on.

Somewhere, the trust that claims providers had of their consumers was tested, and they failed that test. Now, consumers have to have faith that what they are being given from the provider is correct. Another trust test.

What Dan is doing in the above example is making an outrageous claim, namely that he is Scott. It becomes a problem when we believe it at face value.

Claims authentication was supposed to free us from the cost of maintaining secure username/password stores and managing a thousand passwords for the many sites we log into. But now, if we want to keep Dan from playing his little joke, we have to ask each user to give us something that can't be faked like their e-mail address or phone number, store it in our [secure] database, and then verify it - I assume by calling each potential new user and asking them what account they'll be using to get into our site. Obviously, that works better for some scenarios than others.

(Aside from the fact that they're buds, why do I always pick on Dan and Scott when I talk about this scenario? Maybe I'm hoping that one of them will mention me in a presentation or blog post. Anyway, it's all in fun.)


Here's another example. Recently it was revealed that the NSA can now successfully attack SSL and that many SSL certificates have already been compromised. (NYT, Guardian, ProPublica) So what? What if NSA wants to break the certificates Al Qaeda uses to send communications? That's reasonable and it's good for our national security.

But, Al Qaeda doesn't have an IT department with firewalls and hundreds, of dedicated servers. If they did, we could pretty easily bomb it out of existence. All their communications would appear to be concentrated and they'd be easy to follow. Al Qaeda does what many small businesses do when they need to get a lot done on a budget - they use cloud services.

So, NSA isn't going after SSL certificates for the enemies of America, it's going after certificates of some of America's largest cloud service providers: Google, Amazon, Microsoft, Twitter, and Facebook - and just about any other provider that they think the enemy might run to if they decide to take their operation underground.

So, why is that a problem? Because SSL is the lock on the front door of your house. Whenever you log in to a web site like Gmail or Facebook, it's SSL that ensures your password cannot be sniffed out over the wires using SIGINT, and that you have some assurance that Gmail is still being run by Google and not by Fly-by-Night Honey Pots, Inc.

What I am saying is that once you compromise SSL, the sky is the limit. That's saying a lot for services that run in the cloud! If you break someone's SSL certificate, that means that you can read all their traffic including logins and passwords. It also means that you can pretend to be them.

So, say you've scooped up petabytes of network traffic that were secured with SSL and you filter out just the ones that go to the Facebook login page. Crack the SSL certificate and watch thousands of passwords fall out. Some of those usernames and passwords will work on other sites too like LinkedIn or Twitter, or if the user isn't very password savvy maybe their online bank. They may work for years to come. If you have interest in someone on the Internet, maybe because you think they're a bad guy, and you know the password of someone close to them, well… that could be a very powerful weapon indeed.

But that's only half the picture of what SSL gives you. Collecting so much data is expensive and time consuming. But, what if you had a little box over in AT&T communications HQ that could track traffic just enough to look for DNS requests to Facebook.com that come from certain IP addresses? Whenever it finds one, instead of directing the traffic as usual, it replaces the IP address with one that points to a special proxy server. The proxy has a false copy of Facebook's SSL certificate, so people are told that it's really legit, and they willingly enter their username and password for the site, plus all the traffic to and from is being decrypted (and recorded) in real time.

If you had a setup like that, just imagine what you could do! Say you find out tomorrow that every bad-ass in the world has switched from Facebook to Qik. As soon as you get their SSL broken, you can reconfigure your little DNS spoofing and proxy operation and start listening in on everything they're doing. And all you have to do to accomplish you goal is lie to everyone on the Internet.

Now, those are outrageous claims! …and a test of trust.