Authentication Mystery: When Membership.GetUser is null

When Membership.GetUser is null or nothing, but login succeeds (and fails on a bad password), check the path as such…

<authentication mode=”Forms” >
    <forms …
               …  >           

Mine was set to path =”blahblah/blah”.  I changed it to “/” and things worked again.

Has something to do with browsers rejecting the cookie because it didn’t look like it was coming from the right server.

Who are you and who do you know?

This is an interesting problem somewhat related to authentication and authorization. It is screaming for another name starting with ‘a’ and ending in ‘ation’. It asks the question, who are you? Who do you know? Can you prove that you know them through some sort of reciprocal authentication process? What rights do you grant your various relationships?

Why Do We Care Who you Know?

This is a special case of authorization. If you have verifiable claims about who you know, then that information can be used to authorize you see information concerning your friends and collegues. This is part of the trend of putting users in control of their own information. The alternative would be for an overworked administrator to create a authentication group, say a Window group or an Azman group, which has the special right of being able to view your data. This would mean an application of one million users would have one million Azman or Windows groups, an administrative nightmare and the administrator would have to use an out of bound method (like making phone calls) to verify the relationship.

This is also a special case of authentication. A friends list is most interesting when you I know you because you gave me a secret which lets me correlate the person I created the identity with subsequent authentication attempts. I know you know your friends because you gave me a secret which matches the secret I got from one of your friends. For example, if you can tell me the sum of the digits in your email address and your fiends email address, maybe I can believe you without letting you know what the true email address of your claimed friend is. Of course, there are better cryptographic methods for this.

Current Technologies

Current technologies focus on public claims and not much on the verification of the claims.

You try to authenticate me and ask, “Who are you?” I give you my OpenId or InfoCard. I send back some claims and maybe an hCard.

You ask for some claims, “Who do you know?” I give you one of the following: a FOAF document, bunch of XFN links, a XOXO/OPML list. Ugh.

  • FOAF– hard to make by hand, no browsers can read it. This answers, “Who’s in your email address book?”
  • XFN– doesn’t support time, no way to prove relationships short of spidering the links in hopes of finding a reciprocal XFN link. This answers, “Who amongst your friends have a URL that is associated with their identity?” I wouldn’t easily be able to make a meaningful XFN link to my grandmother.
  • OPML is just an hierarchical list structure, not specific to a friends list and is mostly used for blog readers, so a OPML list answers, “Who’s blog do you read?” Somehow this format seems redundant, since XML already is a hierarchical data structure. XOXO is the microformat of the same.
  • hCard — This is a business card, also answers, “Who’s in your address book?” (It is the microformat of the vCard standard)

Proof of Relationship. In FOAF, proving relationships requires knowing something secret about your friend, say their email address. You publish a crytopgraphic hash of your friend’s email address, the friend does the same. In XFN, your friends need to be able to publish html pages with XFN. The relying party would query both domains and see if they match. Authentication is as good as the internet domain name system, so an XFN relationship is really between the users represented by the Whois database, which is mostly minimally authenticated people. Worse, many, many people might have the ability to publish to a given domain. OPML has the same problems as XFN in proving a reciprocal relationship. hCard lacks a way to uniquely link two hCards. I publish my hCard with the name Matthew Martin, which is shared by 100′s of people. To form a link you’d need to do a complicated fuzzy match of address, phone number, name and other address information.

Claims. Out of FOAF, XFN, OPML, hCard, only XFN makes claims about the type of the relationship. OPML implies a bogger-reader relationship. FOAF implies only a friend relationship, the only other category is “not-friend” indicated by leaving someone out of the FOAF file. hCard implies no particular relationship at all. I could publish a list of hCards on my website and there is no way to know what the implied semantic meaning of the relationship is. Maybe it’s just a list of lawn mowing companies I’m considering hiring, maybe they are my best friends.

Rights Granting. None of these say anything about what it means for someone to be a friend, so right now this is handled in an ad hoc fashion. For example, Flickr lets you grant different rights to the public versus your friends list. The rights would have to be simple, maybe Read, Write, Update, Delete. The contexts would also have to be simple, maybe a URL for a context. What would rights granting look like if one of the above were extended?

- Friend List
—– John Doe
—– Jane Doe
———Read–(photos)– Friends
———Read–(vacation photos)– Verified Friends
——–Write–(comments), Met
——–Write–(posts), Family
———Read–(wishlist), Friends, Family

The system would have to be extensible to rights that don’t fall into the Read/Write/Update/Delete categories and right would need some domain restrictions. The format would have to be extremely simple to make and robust to validation errors.

Tools. None of these have very good tool support, but the tool support is better than any proprietary technique you can think up. XFN and hCard can be browsed with any browser. FOAF is going to languish until browsers have support for RDF documents in general. In theory, they all can be parsed as XML.

Ubiquity. Formats that rely on domain control mean users need to open accounts on ClaimId or the like to get a page associated with themselves. Email is almost ubiquitous. Cell phone control does a better job of identify one person, but is not as ubiquitous. Domain control is mostly restricted to super users and geeks. SSL is restricted to people with spare cash and are geeks. SSL certificates that actually verify an identity claim to any degree cost a lot more money and require the relying party to check the SSL certificate issuer’s issuance policies, not an easily automatable process. Of these, only ClaimId or email control are in the grasp of my mother.

Privacy of Friends. Maybe I don’t want my friends URL, email address, phone number and address to be misused. FOAF addresses this issue, but doesn’t require users to protect their friends from spam. XFN assumes that the URL of your friend is public. hCard makes no effort to address the privacy issue. A good friends list would let the user decide if he trusts the world with their claims about their friends, a hash of their friends claims, an encrypted copy of the claims (ie. the relying party can store my friends data, but not read it), or maybe I entrust the relying party with the identity but not claims about my friends at all.

Any relationship verification system needs to be able to prevent mischief. Any system that can be exploited, will eventually be overrun with spam and other attempts to get rich quick.

Games people play with the question

Aspirational Claims. Claiming someone is a friend when they are not a friend at all. Fortunately, my best friend Bill Gates doesn’t fall into this category. To prevent this, you’d have to get a friends list from both candidates and find the reciprocal claim.

Misrepresentation. You have a relationship, but you misrepresent it. They met you, but they are not a close friend like you claim. If the relationships fall on a neat continuum, you could pick the minimum relationship claimed by both. For example, if one person claims the other is a brother, but the other only claims they are kin, then the verifiable claim is mere kinship.

No one can be expected to make a claim that will restrict their rights. When an administrator puts people into groups, he has no qualms about putting people in the the “Limited user” group. Who will make claims that will give them less access to the people they know? If I claim I’m a best friend, I get access to the juicy gossip. If I claim I only met someone, I get just the public information. Any one guess what I will claim? This is misrepresentation again. Again, to prevent this you’d have to calculate the minimum reciprocal relationship.

The relying party relies on stale information. They were your friend, but they aren’t any more. Reciprocations are only reliable if friends lists have start and stop dates and a duration that the claim is good for. For example, if John Doe is my friend, I need to record him on my friend list as a friend since 2004 and this claim is good for a year.

Good Manners. No one wants to be hostile, so people will over-reciprocate and claim a stronger relationship than they would want to if you get them to privately explain the extent of their friendship. For example, if John Doe says I’m his best friend forever and I think he’s just an acquaintance and only for the next year, If it is important to know the true extent of a relationship. If you make people rate their relationship on a scale of 1 to 10, people will be biased towards 10. If you ask binary questions, there will be less of a bias due to politeness.

The relying party needs to know the strength of the relationship, but the two claimants don’t want to reveal the fact to the other person. This means public friends lists will be dogged by good manners biases. If the friend list was secret and the user got back limited information on friends list based authorization check, users would be more likely to be honest.

Humor. The XFN romance attributes appear to be used for humorous intent. All developers who write sample XFN links claim they have a crush on Don Box. Surely some of them must be joking. Real developers have a crush on Scott Gu.

Unidirectional claims. These are unverifiable, so what can they be used for? Who can verify if I have or had a crush on Kylie Minogue? If I and Kylie Minogue were in the same database, would she grant extra rights to her account data to people who claim a crush on her? (Or more likely, restrict rights to deter stalkers?)

Unauthenticated Other Friend. You authenticate a user. The user claims he has Kim Cameron as a friend. But this guy claims that Kim Cameron friend list can be found at, which is actually a domain controlled by the party claiming to be a friend of Kim Cameron. So no relationship claims should be accepted by the relying party

Some Characteristics Of a Commercial Grade Relationship Architecture

Uses private friends lists. E.g. “If a relying party asks, I will let them know that John Doe is someone I barely know, but please don’t tell John Doe the details, just give him a yes/no on an authorization check”

Uses authenticated friends lists. E.g. “John Doe is my friend, you know, they guy in your authentication store that sent you his friend list”

Relies on reciprocal claims. E.g. “John Doe is my friend, just go check his friends list”

Has time a time dimension. E.g. “John Doe was my co-worker from 2000-2004.” “Jane Doe is a friend since 2000″ “I am willing for these claims to be valid for the next six months”

Has a rights list. E.g. “These are my friends and when I say friend, I mean they can read my blog and comment. When I say family, I mean they can also write blog entries.”

Has a enterprise grade API, maybe a SOA based server based on WCF.

Some Characteristics of a Good Enough Relationship Architecture

Relies on public friends lists. Authenticating friends to a private store is expensive and require co-ordination.
Rights granted based on level of friendship and quality of claim. Most claims will be unreciprocated and unverified. Authenticated friends should be differentiated from unauthenticated. Likewise, unreciprocated are differentiated from reciprocated. If transaction costs are important and it is not important to guarantee that people don’t play games with the system, reciprocated claims based on domain control might be good enough.
Based on plain old semantic HTML. HTML has a universally available data viewer. RDF and XML don’t.
Has a simple API. Maybe a some HTML GET commands (REST) or some Javascript checks. Obviously Javascript would only be useful for data that is already public. For example, a Javascript API might use my friends list to filter a public photo RSS stream down to just my co-workers photo’s.
Works with google and other ‘found API’s. For example, the “who link’s to me” could be used as a way of verifying reciprocal claims.

Outsourcing Identification

Three of my favorite website now use the same cryptographic keychain and password:

  • Paypal
  • Ebay.

That’s because Ebay owns them all. Similar situation for Flickr and Yahoo.  Gmail and Google Analytics.  Make you wonder if it is the ID system that helps drive consolidation or if it’s just cheaper to have one authentication system for the whole portfolio of companies a big corporation owns– probably a bit of both.

I wish Ebay would make their authentication service available to the world, in an InfoCard/OpenID sort of way, because plain OpenId is still single factor identification.  (InfoCard is a type of two factor identification if you call your entire physical computer the one factor and the network logon/InfoCard pin the other factor.)

Bill Monk is interesting because , but you can sign in using your Facebook ID. [I can't tell who owns them, maybe the same company as Facebook?]  I’m planning on using bill monk to keep track of how much money I owe my son.  He gets paid for chores & accomplishments and sometimes is allowed to spend it.  Accounting is currently done on a piece of paper on the fridge, not exactly a web 2.0 user experience.

Cardspace/InfoCard for the people!

I posted an irate comment about how hard it is to implement Infocard on a hosted ASP.NET account on a shared server.  It is a bit short of impossible and probably can’t be done securely with most hosting plans.

Let me say despite my cynicism, I hope Infocard succeeds, because the core concept of passwordless authentication is genius and an unqualified good thing. 

Kim Cameron, architect of InfoCard replied on his blog and agreed with me that requiring SSL for InfoCard on the smallest of websites, such as blogs was overkill.  There is hope that in of InfoCard,  sites will be able to accept authentication and receive claims without SSL. [Now that I think about it, this should also solve the decrypting-the-response-and-claims problem in ASP.NET]

Any how, here are some reasons why I think that enabling Infocard for small sites—-however it may be accomplished—-is important:

Ubiquity.  Identity systems need to be ubiquitous.  When I arrive in a town at go to a new bank, the local tax office, the electric utility, they want to see my driver’s license or social security cards .  They don’t start by asking if I have a library card, a passport, a shopper’s club card. Those are not ubiquitous enough.  The situation is the same for the web.  As soon as people know that everyone has a “foo”-card or a “foo”-id, that is what they will ask for.  If Infocard relinquishes the “little sites” and the little sites adopt, say OpenID, then the banks are likely to follow.  As soon as my password database has 95% of its passwords replaced by either OpenId or Infocard, the other will fade into obscurity.  Why would a banks ask for a super secure but not ubiquitous library card when they know everyone has a reasonably secure driver’s license?

Phishing.  Who has the money?  Fishing attacks are mostly against banks.  That is where the money is.  But this might not be the right question. But where are the passwords?  They are mostly in rinky-dink blogs, forums and other little websites.  Users can’t remember 50 passwords, so they use the same password for all of them.  Phishing a forum may be just as effective at getting banking passwords and ID’s as phishing an actual bank.  Now if the banks use infocard, then a password obtained at a little site might be commercially useless.  Or maybe not….

Spam. Malware. The little sites are being crushed by ever more creative forms of spam.  My referral logs are mostly spam.  My comments are mostly spam.  Blogger is mostly splogs.  Usenet is all spam.  Email is almost entirely spam. Forums, more spam.  Spam, spam, spam.  Sites with no passwords (because it’s too much to ask of someone trying to leave a comment) are entirely open to spam.  All of this spam is driven by the fact that you can make money by exploiting defects in the identity system of small websites.

Without a function system of identity small web sites can’t interact with the world because they can’t tell who is a the same malicious user you banned last week and who is a potential legit user.  I doubt OpenId or Infocard will solve all the spam problems, but it will make it easier for small websites to demand registration instead of putting up with anonymous users.

Infocard-OpenID Hybrids  is interesting.  It is an OpenID site, but when a user is redirected to the authentication page, the user has the option of using a password or an InfoCard.  I’ve signed up for my account as successfully authenticated to a site using an Infocard+OpenId process.  From the website owner’s standpoint, this hybrid solution will have the same pros and cons as OpenId, as the interface to the claims will be the OpenID interface, not the InfoCard interface. 

In sum, I hope Microsoft doesn’t abandon the little sites.

SSL, I just don’t get it

So I’m buying an SSL certificate. To prevent getting a MSIE7 error, it needs only be unexpired, match the URL and come from a ‘trusted authority’.

A trusted authority, like will give an SSL certificate to anyone who “controls their domain”

Why don’t we just call a spade a spade and tell people that an SSL certificate is a means of encryption on the wire amongst unauthenticated parties?

I got a magazine subscription from an online company that did everything possible to hide their identity (anonymous domain, no physical address)– and they used SSL. I did get my magazine subscription, so it appears that I was buying from a company that want to stay anonymous, maybe for tax reasons. The transaction size was small and the website was plausible, so I wasn’t exactly sending a check to Nigeria. All I really need for this transaction is *correlation* I can now correlate my experience with the first time I interacted with this anonymous company with the second time I interact with them and form a sense of their reputation. In fact, if a reputation server was what stood behind the URL & SSL cert instead of a picture of a guy with a bag over his head, ecommerce would be a lot safer.

I really don’t see the value in the expensive SSL certs either. To get the additional trust from that cert, users have to:

1. Understand that you $1000 cert underwent a rigorous audit, unlike the vast majority of certs.

2. Know how to click through to see the subject on the cert

3. etc.

Imho, SSL is not authentication at all. It’s more like meeting a stranger on the street and agreeing to speak in Esperanto so that the other strangers on the street can’t understand you.

The URL is not an identity either. OpenId is proposing that if you control an URL, you are that URL. But URL’s lapse all the time. Even excluding the rather rare, but technically possible hijacking of DNS servers and domain names, if my URL lapses, someone could pick it up and pretend that they were Matthew Martin. They wouldn’t be as stylish and suave, but an average web browser would be hard pressed to know the difference.

OpenID Adventures

Someone wrote an OpenId logon control for ASP.NET–very handy, since communicating with an OpenId server is an nontrivial tasks. But, the control was written in the .NET language Boo. This would be all fine and good, but the implementation is buggy (or some OpenID servers are buggy.) and I can’t fix bugs written in Boo. Currently, I’m dealing with the issue where the OpenID client and server can’t decide if Http:// is the same as Presumably it work work if I was using the SSL port, but I haven’t spent money on a certificate yet.

ClaimId’s profile management is buggy, but at least ClaimId thinks is the same as whereas thinks they are different.

I can forecast that OpenId will go the same way as HTTP, potentially very successful, but writing the logon control will become increasingly complicated to compensate for the millions of different ways that servers implement the OpenId specs. And servers will likely become extremely difficult to implement to deal with the large number of ways clients implement the spec.

Sigh. It’s enough to make me look at CardSpace again. One of the key benefits I saw in OpenId was that it didn’t require SSL to be working–so I thought. Now it seems that both technologies really are intended to be heavily dependent on a fully functioning layer of SSL.

You want your site to support password-less logon, you’re going to have to buy an SSL certificate. What is really depressing about that, is that the web 2.0 model for authentication will be stuck in the business model for web 1.0, where we all give money to Verisign and get in return certificates that website users don’t understand very well. And with the large number of sites with SSL certs that are legitimate companies but have expired SSL certs and slightly mismatched URLs, or self signed certificates, what few people do pay attention to the little lock icon now know to ignore it entirely.

So Microsoft, where is the HTTP solution for authentication? I’m not about to buy an SSL certificate for managing comments to my blog.

OpenId vs CardSpace Smackdown

CardSpace means your site needs:

* to be running ssl, with a confirmed location and organization name to prevent warnings.

* to be running with an account that can access the ssl certifications (ASPNET account, NETWORK SERVICES, etc)

* to decipher the claims, you need to decrypt the certificate and the associated claims, hence the need for access to the machine’s ssl certs (It appears to be POST and rather hard)

* you have to use cobbled together controls from the internet

* Optionally a third party. The user can act as their own certificate issuer.

* The server can be any OS, but the client has to be XP2 or Vista

OpenId means your site needs

* a third party website to process the passwords

* ideally the users will want to get their own URL (so that their identity is as strong as the domain name sales process, woo hoo!)

* The user claims are posted back in the URL (REST is easy)

* you have to use cobbled together login controls from the internet

* The server and the client can be anything

I have an OpenID logon almost working, I got close to a working CardSpace logon control, but ran into the SSL cert issues.

Integrated Security and Kiddie DOS Attacks

This morning my PC says my account is locked out.  Apparently, when I connect to my office by VPN, something on my computer was repeatedly trying to log into my computer using my name, Matthew Martin.  The password and domain were wrong, so Windows XP helpfully locked out my account, which I admit was the behavior I told to have.  I set a limit of something like 1000 failed logins before lockout.  On the “Welcome Screen”, there is no obvious way to log in as administrator.  Guess what feature I plan to start turning off on all the XP machines I come across?  That’s right.  Someday I’m going to need to tell someone in my family how to log on as administrator and they are going to be at a “Welcome Screen” without administrator on the list.  I managed to log on by using remote desktop.  I unlocked my account and found out that MYWORKDOMAIN\Matthew Martin had been attempting to log on about every minute or so all night.

The failed logon continue.  Where could it be coming from?  If VPN is turned off, the logons stop.  Currently, I think the culprit is SQL Server Management Studio, which will send at ‘Are you alive’ connection attempt to every server on your list. It could also have been remote desktop or filesharing, I can’t really prove anything.

If the remote server is a WORKGROUP and not a domain machine and the user names are the same, then a polling app can easily lock out an account just by repeatedly attempting to log into a remote machine.  As long as the logon type =3, there doesn’t appear to be any limits on the remote machine.