One of our folks pointed out that you can go to the below link and, for a $1 charge on your credit card, change your address online with no other verification being done. Seems quite scary – if someone steals (or buys on the internet) your credit card information, they can have all your mail forwarded to them. Another area in which personal identity management, Trufina, or other verified ID Cards (Cardspace comes to mind) could be very useful…

https://moversguide.usps.com/

I went to their comments/contact us section and wrote the following question:

It seems as though a valid credit card is all I would need to change my address – How is this considered secure? If someone steals my credit card they will be able to change my address with the USPS. There are hundreds of locations on the internet that buy/sell credit cards, from what I’ve heard. How can this be considered secure? I ask partly to see if the USPS would be interested in using a more sophisticated solution. Our company, Trufina, would offer the USPS the same solution, but with a much higher level of identity verification.

www.trufina.com

Chris Madsen

Update: I just received the following email reply, and it seems like the USPS is definitely trying to do right by providing a convenience to the US public, but it still seems dangerous to allow a credit card to authenticate oneself. To me the question is how much is good enough, does the proof of knowledge of a credit card number, prove you are the true owner of that card (even with the CVC2/CID code) and the associated identity?

Here is their response:

Dear Postal Customer,

In efforts to provide you with a secure online transaction, there is a
$1.00 authentication processing fee .

When you enter your credit card information the information is used to
validate your transaction by verifying that the address you provided
matches the billing address for your credit card.

If you choose not to use your credit card to submit your change of
address electronically, please feel free to select the print and mail
option on the site.

Sincerely,
USPS MoversGuide Technical Support Group

Linden Lab, Second Life’s creator, has unveiled an identity verification system for residents. It’s voluntary right now but necessary if residents want to access restricted regions in the metaverse where explicit sexual or excessively violent content is available.

The service – in beta – uses Aristotle’s Integrity technology and involves entering a Social Security number, driving licence or passport, although the data will not be stored by Linden Lab or Aristotle. This is not as complete as Trufina’s process (we try to prove that the person who is typing in the drivers license/SSN is in fact the owner of that identity attribute – but its a great start.

The 101 responses to the blog post were mostly negative, with quite a few being concerned that either Linden Labs or Aristotle may misuse their identity data. Several users also wanted to keep their anonymity. Linden Labs defended the move saying “Anonymity has long been both a benefit and a challenge for online communities: a benefit because it offers opportunities to reinvent yourself; a challenge when it comes to the creation of trusting relationships. With the option to verify aspects of their real life identity, such as age and name, Second Life Residents can begin to build trust and safety systems inside the virtual world and their virtual community.�

As long as sites and the providers they use make sure the data they collect (either from the user, or via public records checks) is controlled by the user, and not used for ANY other purposes then everybody wins. Such a offering demands a large amount of trust between the user, the site, and the identity provider. Trust which must not compromised. 

 

I saw this post by Bob Blakley about the meaning of OpenID, and I thought it brought up some great questions. We, at Trufina, have been following OpenID, Cardspace, and various other ID initiatives, for a long time (in internet years), and hope these initiatives become widely adopted. Anyway, here is Bob’s post, and my comments follow: September 04, 2007

 

What is OpenID for?

 

 

Blogger: Bob Blakley

There’s been a bit of a dust-up over OpenID recently in the blogosphere.  First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID.  Then Stefan Brands amplified the critique in a long blog post.  David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems.  I have less confidence than David, but I’ll leave that topic for later.  What I’d like to do first is talk about getting the horse before the cart.

What I’d really like to see, as a security guy, is a problem statement and a risk analysis.  Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:

1. What are the assets to be protected?

What do OpenID’s designers intend it to be used to protect?  Blog comment lists?  Blog entries?  Persistent consumer accounts on commercial servers?  Persistent employee accounts on corporate servers?

2. What are the services to be offered?

What services do OpenID’s designers intend it to offer?  Authentication of users as the legitimate possessors of OpenID URLs?  Linkage of OpenID URLs to user accounts on web-facing systems?  Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?

3. What quality of protection is claimed for these services?

Is the OpenID protocol intended to protect against phishing?  Is it intended to protect against man-in-the-middle attacks?  Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code?  Is it intended to protect against session-splicing or session hijacking?  Is it intended to protect against active or passive wiretapping?

4. What is the threat model?

What threats is OpenID designed to protect against?  Accidental failures at a participating party?  Malicious behavior by users?  Malicious behavior by relying parties?  Malicious behavior by OpenID providers?  Wiretappers?  Hackers attempting to penetrate a relying party?  Hackers attempting to penetrate a provider?  Hackers attempting to penetrate a client system?  Cryptanalysts?

5. What is the trust model?

Who trusts whom to do what?  Does the user trust the OpenID provider to actually check his password?  Does the provider trust the relying party not to send maliciously constructed OpenID URL strings?  Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times?  Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov�?) 

All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these.  The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.

 This is my comment:

  Bob, great questions/suppositions… Please excuse some responses:1) is the answer SSO or more? It would seem that the 1.1 spec is intended for exactly that, and the 2.0 spec is out there still because (IMHO) the answer to your question has not been decided upon (please correct me if I’m wrong).  2) I’d say that’s a ‘yes’, 3) if the answer to 1) is right, I’d say no. if not, great question. 4) Humm, that’s a lot of different trust scenarios, but the first one is the question – what trust model does the community really believe OpenID will solve. 5) Seems that the only thing is that someone has been able to authenticate against a valid OpenID enabled URL.
I don’t think the 2.0 spec is a solution looking for a problem – the 2.0 spec solves a great many issues. To me the question is – whether or not the community wants to support the added complexity of the 2.0 spec to solve the problems it solves. the 1.1 spec is perfect for SSO scenario, with little or no trust model, IMHO.