CardSpace Use Case - Lost or Stolen Cards

CardSpace Use Case - Lost or Stolen Cards

• dbeau

  The point of self-asserted identity (Personal Cards) is two fold:

  1. it eliminates the username/password game. Passwords are secrets we are trained to release. Passwords pretty much spell disaster.

  2. The CardSpace self-asserted identity is a form-fill convenience. Self-asserted claims are no different than the user typing in their information. You are getting is the convenience that sites will know your low-value identity claims from sumitting a card, and the fact that the possession of the information card can be cyptographically ensured (PPID and issuer key).

  OpenID requires that anyone wishing to assert their identity either

  (a) have that service provided to them (an identity provider)

  (b) provide that service themselves. (making them self-asserting)--with the problem that they have to host infrastructure to make that happen.

  (c) have an URL that they can assert control over. (I do, but my mother does not.)

  So, in the case of (b) -- what value is that You *still* don't know that the person is who they say they are, all you have is a common/unique moniker that you can reference them by.

  Email can accomplish that too-- it's got globally unique naming, and people remember those... Not only that, but you get proof of control of the email address, and it didn't take any new infrastructure on the part of the user.

  By the way, "CardSpace" is the identity selector on Windows. The cards themselves are simply "Information Cards"

  Now, that all being said, there is nothing stopping you from using Information Cards, and asking for the 'website' claim, which you can infer to be their OpenID URI, and completely skip the PPID altogether.
  

• jay22

  It's true, you will *always* have to do something on your side if their identity is stolen or lost.

  There is no possible way to guarantee:

  (a) people cannot have their identity stolen (badguy standing at your computer with a gun to a person's head until they release all the secrets and tokens)

  (b) people won't lose their identities (meteor striking the city where your identity is stored).

  g	Garrett Serack | Program Manager |Federated Identity Team | Microsoft Corporation blog:http://blogs.msdn.com/garretts

  
  
  

• sammy chen

  I certainly see the value in self-asserted identities and I am quite excited about the prospect. It is just my personal opinion that the self-asserted Information Cards in CardSpace on millions of PCs are more vulnerable to being lost or stolen then OpenIds or Verified Information Cards hosted at Verisign or some other big-company/big-government website.

  We are digging into the details of how to accept Identity 2.0's on our website. We are comparing our use cases based on Identity 1.0 and seeing what Identity 2.0 gives us. We see massive gains on not having to deal with Identity creation and maintenance and all of the operational support. For our first phase we are focusing on supporting pseudo-anonymous (self-asserted) identities.

  During this review process, we were looking at our "reset lost password" use case and that is when the analyst asked about lost "Information Cards". That can be for many reasons as we've explored in this thread. For CardSpace: client not making a backup and theft or loss of machine. For OpenId websites: the website shutting down, user forgetting URL, hacked site.

  What happens if our client loses their identity Likely, our client wants to be reassociated with their existing account. We need to come up with ways of doing that (website policy of "so sad, too bad", do some proofing of data you gave us, etc.).

  What happens if our client's (electronic) identity is stolen Likely, our client wants to prevent access to the account by the old identity and associate a new identity. I don't think a website policy of "so sad, too bad" will work here. This implies we will have to do something on our side to accomodate the client.

  Maybe a bit of Identity 1.0 comes back here because we need to store some things about the Identity 2.0 for proofing later on. Maybe our process will be to have them call us, tell us an application at the website for which they have identity information and other data and then proceed to proove to us they are who they say they are. Of course we've only started thinking about it which prompted the original post.

  
  

• HectorCruz

  In any system, you are going to have to have a recovery scenario, that is comparable to the bootstrap mechanism.

  So, yes, if you want to recover a lost identity, you need a second method of identifyng the user, and authenticating that they are who they say they are.

  Typical recovery scenarios include interogation of account facts (when did you create the account, when did you last use it, how often do you use it) and additional security questions (pet's name, etc..).  The interogation questions can be presented as multiple choice, and should give a good indication if that user has been in control of that account. Usage of answers to obscure questions (pet's name, mom's maiden name) are sharing of secrets that weaken as time goes on (how many places like to know that!)

  The second method, is of course, out-of-band communication (ie, their email). if you store contact information, you can use that to return their request. This is verifying that they have control of that contact information. Sending them a unique link to re-associate their account with a new card would be an appropriate use of that contact information.

  The best of course, combines both methods. They say "I lost my identity", you send a link to their preferred communication point, the come back, and answer some questions that demonstrate their knowledge of their account. this eliminates the need to have them share a secret (pet's name, etc...) but it does meet two common authentication criteria:

  something you have (control of the email account)

  and

  something you know (the usage of the account)

   

  Of course, if you are storing their OpenID, you can substitute that for the "something you have" part.

  Garrett

  
  
  

• vbjunkie

  I've been away. Thanks for the opinion Kim!

  For me this use case takes a bit of polish off of the user centric model from a resource provider's perspective. When you read the high-level concepts of Identity 2.0 you get excited about eliminating identity management from one's website. But like everything else once you get past the marketing and into implementation details you usually find more work then you thought.

  It looks like we'll need a bit more identity data on the account to handle this use case. The extra work comes in building the infrastructure to handle it. I either need to setup pages to handle challenge/response functions or the infrastructure to handle 'account resets' by email. Of course the overall work and liability is less than Identity 1.0. I wonder how many other use cases like this are out there in the Identity 2.0 model for which we will have to build. Hopefully we'll catch them through threat modelling.

  Actually another use case I am thinking as I write is that a person will want many self-asserted cards associated to one of our accounts. Take the case that I have my self-asserted InfoCard at home on my Vista machine. I come to work and my company won't allow anything personal put onto my machine from floppies, usb keys, or even email. So I have no way of importing my self-asserted card from home. Or maybe I am not savy enough to understand computers enough to even do export and imports. I have no choice but to create a new self-asserted card on my work machine and I really need to access that existing website account from both home and work all the time.

  Now, back to the implementation of this code, for CardSpace, are there plans to release ASP.NET 2.0 Web Controls and a Membership provider It would also be really cool to see a Web Control under the Login toolbox called 'RecoverLostIdentity2.0' alongside the Identity 1.0 PasswordRecovery, ChangePassword and CreateUserWizard :D.

  
  

• Vijay Chegu

  Garrett's response is interesting and leads me to try to disentangle several things here.

  The most common way by far in which sites deal today with lost passwords is by sending a new password out through email.

  What's going on is this: the username and passord are linked to an email address, and control of that email address is leveraged to relink a new password.

  The principle can be applied to self-issued cards: an Information Card is linked to an email address, and if the machine is lost or the owner wants to employ a different card, control of the email address is used to link in a new Card

  Now, when my blog was hacked it occurred to me that although I retained very little information, an attacker could (in a serious enough breach) extract my list of email addresses and wreak havoc with them.  So my question became how to further my data minimalization to eliminate even this threat.

  The answer would be to store the encrypted hash of the email address as an account identifier.  These hashes would reveal zilch if stolen, unless decrypted.  And even if the attacker could decrypt them, all he would only be able to do is determine if a some email address of interest was part of the pool of account identifiers, a really minimal breach. 

  Any other information necessary for account operation could be drawn from the user's infocard at runtime, and dissipate at the end of the session.  Auditing could be done in encrypted form and taken offline regularly.  This would be true data minimalization.

  So that's how I would propose handling the problem.

   

  
  
  

• PeacError

  You know, I am wondering what is the point of self-asserted CardSpace then if my website still has to capture a bunch of identity information I know it is not the exact same identity information but it is identity information all the same. And as you said, then you've got people using their secrets on all different websites and we are back to the password pandemic all over again. I assume our website isn't the only one out there that needs to consider lost or stolen cards.

  I am starting to feel it is better to use the OpenId protocol for non-verified identities since that information is kept at a 3rd party website and would be more reliable then one's PC. I mean better in the sense that my website has less to do and less liability from keeping someone else's identity data. We don't need to code for the likely scenario of one of thousands of users losing their machine with the self-asserted CardSpace. We can gamble on an OpenId website not shuttering its doors. A person has a better chance of remembering their OpenId URL as compared to the PPID system value of a CardSpace. It would be nice to have that Passport central website for this scenario.

  Of course CardSpaces delivered from Secured Token Service providers will be just as good as OpenId because they'll be on 3rd party websites. Again I am talking within the context of lost or stolen self-asserted CardSpaces.

  
  
• CardSpace Use Case - Lost or Stolen Cards