Posts Tagged ‘idp’

IdP risks, social engineering customer service, & Mat Honan

The blogosphere is on fire with tales of Mat Honan’s being hacked (does anyone say “blogosphere” anymore?). The source most seem to be pointing back to is Wired’s article. The best thing I’ve seen is my bud @NishantK‘s writeup where he breaks it all down. And I’m not just saying that because he points back to my own piece about IdPs and their risks relative to upcoming NSTIC style requirements. But that is part of why I’m writing this short piece. I won’t attempt to say again what others have no said very well about the #mathonenhack and what it means you should do (but I know I finally turned on Google two factor authentication – have you?). I would like to answer a question asked by Dave Kearns on twitter, though:

@dak3 question about IdP risk

@dak3 question about IdP risk

He was asking in the original context of the NSTIC comments. But I think it’s underlined by the eerie timing of discussing those risks and them watching this whole #mathonenhack play itself out in the media. In light of what happened and what it means for the risk and responsibility for an IdP, my answer stays the same. I don’t think NSTIC makes any IdP a bigger target then if they are already in the business of maintaining valuable assets for their own profit today. Later on, Dave also stated: “poor 3rd party IDP security practices means IT mgr (& CISOs) will draw the line.” There’s no doubt that there were some poor policies in place. And, as Nishant notes in his piece, Amazon and Apple have both changed some of that. But the key to making this happen comes down to the exploit of the brain of an Apple customer service rep when they decided that they would try to be helpful in the face of ambiguous results from their identity proofing procedures. Has that rep ever even been exposed to the concept of “identity proofing”? I can’t speak for Apple, but I’ve asked others and the answer has always been “no”. Apple in particular goes out of their way to be “friendly” when they can. Here it was used against them with terrible results. In the end, all the best process in the world can be exploited by getting to the right person and getting them to do the wrong thing for what they think is the right reason. At least, that will be true so long as we have people in the position to override our IAM systems.


Is the ID ecosystem #NSTIC wants too much risk for an IdP?

August 6, 2012 1 comment

I’m gearing up to go to the NSTIC convened steering group meeting in Chicago next week. Naturally, my inner nerd has me reviewing the founding documents, re-reading the NSTIC docs, and combing through the by laws that have been proposed (all fo which can be found here). I am also recalling all the conversations where NSTIC has come up. One trend emerges. Many people say they think the NSTIC identity provider responsibilities are too much risk for anyone to take on. With identity breaches so common now that only targets with star power make the news, there does seem to be some logic to that. If your firm was in the business of supplying government approved identities and you got hacked then you are in even hotter water, right?

The more it rolls around in my head, the more I think the answer is: not really. Let’s think about the types of organization that would get into this line of work. One that is often cited is a mobile phone provider. Another is a website with many members. One thing these two classes of organization – and most others I hear mentioned – have in common is that they are already taking on the risk of managing and owning identities for people. They already have the burden of the consequences in the case of a breach. Would having the government seal of approval make that any less or more risky? It’s hard to say at this stage, but I’m guessing not. It could lessen the impact in one sense because some of the “blame” would rub off on the certifying entity. “Yes, we got hacked – but we were totally up to the obviously flawed standard!” If people are using those credentials in many more places since NSTIC’s ID Ecosystem ushers in this era of interoperability (cue acoustic guitar playing kumbaya), then you could say the responsibility does increase because each breach is more damage. But the flipside of that is there will be more people watching, and part of what this should do is put in place better mechanisms for users to respond to that sort of thing. I hope this will not rely on users having to see some news about the breach and change a password as we see today.

This reminds me of conversations I have with clients and prospects about single sign on in the enterprise. An analogy, in the form of a question, a co-worker came up with is a good conversation piece: would you rather have a house with many poorly locked doors or one really strongly locked door? I like it because it does capture the spirit of the issues. Getting in one of the poorly locked doors may actually get you access to one of the more secure areas of the house behind one of the better locked doors because once you’re through one you may be able to more easily move around from the inside of the house. Some argue that with many doors there’s more work for the attacker. But the problem is that also means it’s more work for the user. They may end up just leaving all the doors unlocked rather than having to carry around that heavy keychain with all those keys and remember which is which. If they had only one door, they may even be willing to carry around two keys for that one door. And the user understands better that they are risking everything by not locking that one door versus having to train them that one of the ten doors they have to deal with is more important than the others. All of this is meant to say: having lots of passwords is really just a form of security through obscurity, and the one who you end up forcing to deal with that obscurity is the user. And we’ve seen how well they choose to deal with it. So it seems to me that less is more in this case. Less doors will mean more security. Mostly because the users will be more likely to participate.

The Upcoming Identity Apocalypse

February 12, 2010 3 comments

How’s that for a catchy title? Really it should read “the upcoming apocalypse for identity professionals”. Focusing on federated identity has made clear what happens when “bring your own identity” becomes the norm. There isn’t a place for identity management experts at every organization. We’re quite far from that, but it’s worth thinking about.

The first time I thought about “bring your own identity”, I found it silly. Who would want to be in a business like an IdP? Who would trust the people who would be in that business? The answer to the first question is easy. There is a long and growing list of identity providers, google and facebook most notably. But these identities are not made of the stuff that security conscious organizations want. Anyone can open a google account. Anyone with an email account can open a facebook account. No one wants just anyone to have access to their resources and services. The identity proofing just isn’t strong enough; these providers fail to answer the second question positively. But it’s easy to see how a whole crop of strongly verified identities from trusted sources could make their way into the market. It’s likely that banks, governments and large corporations will end up in this business. Why? Governments would do it for their own reasons; they have a lot of call to have electronic IDs for their citizens to do their own business. BankID in Sweden is a perfect example of this. For places where the government won’t or can’t do it, I envision banks doing it. Why? Loyalty is why. For a whole generation that largely doesn’t even have bank accounts and for whom switching cell phone providers is an everyday thing, the idea of having an anchor to a bank will seem absurd. But if that bank is their ID, the ID they use for daily business with their various businesses they have contracts with, then that would be a whole different matter. As predictions of a more mobile, fluid, skilled workforce are growing stronger, this idea carries more weight. Just picture Jane looking at some great balance transfer offer from Bank of America and wondering if she should switch over from Chase to take advantage. If she uses her Chase ID to access all her applications at the three active contracts she has today, then she may think twice. Does she really want to make them reprovision her access? What if there’s a mistake in the process? How long did it take the first time; does she want to wait that time again?

There is also good in this for the employers. I had a long conversation with a major pharma in NYC about how they have to go through hell today to provision their tokens for two factor access. Now imagine a completely non-centralized workforce (if you have to, this is here for many today). You want to take on a new contractor for a project. You want to create their accounts, but now you need to do the identity proofing. Where do you send them? Do you fly them to the main office? Is there anyone in your HR group even sitting at that office? Do you send them to the HR company you’ve outsourced to? Do you fly to meet them? The problems pile up quick. If you take their credential from somewhere like a bank that already has done identity proofing and has a large, robust network that is primed for doing just that, then maybe you’re a lot better off. After all, who do you trust more, the organization you’re going to send the contractor’s money to or the fresh out of college admin sitting at the desk in the random office you send this contractor to who likely doesn’t even have a passport much less have the ability to spot a fake passport. “But what if they open a bank account, give you that ID, use it to get in, then run a script to suck out all of your data and just disappear with it to sell to the highest bidder?!?” Fair question, but what’s to stop someone from doing all of that today? To open a fake bank account they would need proof of ID good enough to fool the bank. Unless you happen to have the resources of the NSA or FBI, you’re likely to be fooled by that, too. So you hire this hacker the traditional way and they do the same thing. Not only is the bank less likely to be fooled, but I’m sure someone could come up with a score of some kind for how trusted the ID is using real terms like how long the bank account has been open, how strong the proof of ID was when it was opened, how many other times it’s been used for trusted transactions, etc. Having the data and the impetus to make identity scores like that are just one of many things there IdPs could do to add value to the employers.

Finally we come back to the organization doing the hiring and we see that they don’t have many identities being managed on premise at all in the “bring your own identity” world. No identities means no identity professionals, either. Of course, there will be a swell of positions for these folks at the IdP organizations, but not as many spots as there were in the clients. So the music has started and there are only so many chairs. Luckily, nothing is ever so stark. It’s very likely there will be a swing from cloud and outsourced models back to on premise in some way at some point. Of course, you can have on premise services with federated “bring your own identity” style systems as well. But I’d never say anything will be so complete that it will see things completely go away. Things that work tend to stick around and evolve rather than disappear. There is also likely to be competition for the spots as a trusted IdP. That will mean more call for identity professionals who can add value to the offerings these organizations offer as an IdP. The cell phone companies will want in the game, but won’t have the same gravitas as banks. How will they compete? I’m sure there are identity professionals that could make them more competitive. In one of my favorite movies, Mindwalk, the poetic character muses that to people in the middle ages “judgment day was the ultimate day off, not the ultimate off day”. I think this apocalypse could be similar to that. There will be less people left after it, but the ones who are left will be able to make the kind of strong, flexible systems they have always wanted.

%d bloggers like this: