I have a morning ritual. After getting up and making strange grunting sounds at my wife and daughter I typically sit down in front of my laptop. I’ve made a habit of either suspending or locking my laptop when I go to bed so as a result I have to type in my 30–odd character paraphrase password. Given my impared vision at that time of the morning it typically takes two or three attempts but eventually I get it right.

After I’ve logged in I open up Outlook and check my Readify e-mail that is up on Exchange. I then go and pull down my personal e-mails via POP3 to see if there is anything that I need to deal with.

In the past there has usually been a mountain of blog comment spam which would requirement to log into the .TEXT administration tool and delete the offending messages (fortunately RDOS seems to be doing the trick).

I’m actually doing quite a bit of work for Microsoft at the moment which means that I have a Microsoft user account and e-mail address so I use the Outlook Web Access front-end to my mailbox which requires a different username and password again.

Once I’ve deleted any e-mails I am not interested in and flagged any important ones for follow-up I’ll typically head out the door (preceeded by more grunting).

So far this year I haven’t been catching the bus but I resumed this part of my morning ritual today (and am typing this blog post while enroute to my stop). In order to board the bus I either need to pay a fair or produce a small paper card with a magnetic strip which proves that I have already paid.

Even though I am doing some work for Microsoft, they have me working with one of their clients on a project so when I get to the client-site I am going to need to log in again using another username and password.

My tale of authentications and authorisations isn’t quite over then either because once I have access to the standard corporate desktop I need to make a remote desktop connection to the machine that I am actually doing development on. I log on using a local user account and password, launch Visual Studio and then have to log into a seperate source code control system – with you guessed it, another username and password.

Why do we have so many usernames and passwords?

Looking at my morning ritual I can count seven different occurances where I was asked to authenticate myself or prove that I had sufficient authority to do something.

While I think authentication and authorisation are good things I am essentially forced to manage seven different identities just to start doing some work each day and that doesn’t even include the usernames and passwords that I have to use to gain access to various sites on the Internet.

I’ve already posted about the issue of there being too many usernames and passwords before and I think that as our use of computer systems increases the problem will only become more pronounced.

Usernames and passwords are a mental tax on computer users and ultimately, because they are handled by people who are not security professionals (who I also doubt follow their own rules) are going to be the weakness in your computer network security.

Usernames and Passwords on the Internet

So, why do we have so many usernames and passwords? Perhaps the more interesting question is why don’t we just have one username and password. Certainly attempts have been made to create global authentication scheme, just look at Microsoft Passport and the plans for an identify federation being made by the Liberty Alliance.

I think its fair to say that most people either have or have entertained having a Microsoft Passport identity. For me it is a critical business tool allowing me to access all the Microsoft Interenet properties with a single username and password.

The problem for non-Microsoft properties however is that Passport is too hard to get into with the first stumbling block being just finding out how much it costs! Alas I don’t see that many more sites adopting Passport in its current form.

I will be the first to admit that I don’t know much about Liberty Alliance, although I have skimmed through some of their architectural documentation. They seem to look like a more distributed form Microsoft Passport where there are multiple identity stores and communities of service providers which service that identity store.

Fundamentally however, they all suffer from the same problems which can be summarised as follows:

• End-users don’t trust company X to manage their identity.
• Web-sites don’t trust company X to manage their users identites.
• The identity management scheme provided by company X is not pervasive.
• • I can’t use the scheme to login to my corporate user account.
  • I can’t use the scheme to login to my completely disconnected device.

This lack of trust and pervasiveness essentially ensures that we will never have a central directory service that contains all the worlds identity information, and as a result we have a proliferation of username and password authentication systems for each and every web-site (or family of web-sites) that get created.

Usernames and Passwords in the Enterprise

In the enterprise tools like Active Directory and eDirectory are doing a good job of moving us towards single sign-on. Its really only systems that can’t get access to the security context created by these tools that result in users having multilpe usernames and passwords to do their jobs.

The problem here is that as our use of computing in business has increased so has the likely hood that we need to work with other organisations. This leads to a situation where we either accept that for every organisation with work with, we are going to have to have a seperate username and password, or we need to try and do some identity federation.

My gut feel is that while identity federation solutions cure the symptoms of the identity management problem, the fact that we need to create these hard links between organisations to support is still the problem to be solved.

Authority Matters, Identity Doesn’t

Well, kind of. The act of authenticating someones identity is certainly important, but when it boils down to it is the specific authority granted to an individual that counts. In fact a resource doesn’t even really need to track the authority levels of individuals.

Imagine a scenario where when trying to access a resource that you are challenged to provide evidence that you have the delegated authority to perform the operation requested. Rather than providing some authentication token, you (initially) provide a blob of XML which shows the delegation hierarchy from the resource to the system administrator to the business owner, to the mid-level manager and eventually down to you.

The only thing that the resource would need to know is who it delegated complete authority to in the first place (typically the installer). Then that person can sub-delegate as necessary without even informing the resource.

Once you take this step the need for a central directory service for storing authentication and authorisation information is greatly diminished.

Getting Authority in the First Place

Whatever mechanism is used to get authority to act (in-band or out-of-band), the way it needs to work is by evaluating a network of trusts. For example, lets say I want authority to act on my savings account. Today, my financial institution would ask me for my 100 points ID. This might include my drivers license, my passport and some other form of identification such as a Medicare card.

Essentially what they are doing here is evaluating whether they trust a list of organisations that you have provided that know you. The passport, drivers license and Medicare card is just proof of association.

We we had a distributed security model it could actually be used to replace drivers licenses, passports - everything! The key ingredient in making this work is that we would have a standard card (or rather interface) which allowed an organisation to query which other organisations had verified your identity.

Evidence would be provided in the form of a data exchange of signed XML or something like that. The resource (bank in this case) would simply see if it also trusted anyone who had verified my identity. If they did then they could actually grant me the authority but also add to the list of organisations that have verified my identity. Once again – this could be completely decentralised.

Moving Forward

This post has taken a long time to write, and there is more that I want to bash out on this subject, but its really something that can get quite sensitive. Here in Australia we are currently having a debate about whether we should have this thing called an “Australia Card” which is essentially a piece of plastic which identifies us.

I don’t really have a problem with the idea, but once again its a central directory with the card just being a lookup key. I think a decentralised security system is something that would need to be jointly developed by individuals, governments and corporations and phased in over time with an emphasis on security and privacy.