image provider

Password Eliminator








Passwords are a crude mechanism for giving you access on the web. First let me enumerate all the problems with passwords: There are several ways someone might guess a password: Most of the time something is password protected that does not really need protection at all, e. g. your free account that lets you view some website in return for telling them your email so they can spam you.

Every site has its own rules for composing a password.

This does not work! Why?

We need some sort of universal password scheme.

There are several ways it could work. In the simplest, I convince my password manager that I am me and it deals with convincing the rest of the world I am me.

The catch is passwords are currently designed solely for humans. Browsers make a brave stab at noticing and remembering passwords for you but they don’t do that good a job. Further, they don’t back up the list, or capture passwords on first use. You still need a paper list somewhere. Cookies are another half-assed attempt. Cookies are fragile and easily lost.

We need to properly automate:

This is not rocket science. The technology has been around since the 60s to do this with ordinary automated passwords. What is needed is the political will to come up with something universal. vCard is a start.

Handling that problem with conventional passwords, with a standard password login interface would just be a minor extension of the password protector student project. The real problem is political, persuading sites and browsers to start using it.

The proper way to do this is with digital ids that have an RSA public and private key. Digital ids have the following advantages:

We will need three classes of digital ID:
  1. first class

    full id: proves you really are a real person at a real address and phone number. These require considerable fuss to verify identification before issuing, much like getting a passport.
  2. second class

    email id: proves you at least in the last 3 months had given email address. These can be generated by a mailbot at the certificate company, usually free.
  3. third class

    anonymous: proves nothing other than you are the person who came before with this same id/password. passwords are replaced by public/private key pairs. Your effective password, the private key, is never actually transmitted over the net. You might use a fresh id for every site, or every visit, depending on how serious you were about being anonymous. These can be generated on the fly freely as needed.

Your code has to run both as a servlet on a server to manage logins and as a browser plug-into do the login handshake and reveal the agreed information. To persuade sites to use it, it needs to be free or almost free. You might consider an ad-supported version so you get paid to use it.

Thawte and Verisign could increase sales by many orders of magnitude if this caught on. Perhaps they are the ones to prod to implement it.

These digital ids could have many other uses, e.g. electronically signing email to help filter spam,

Eventually the scheme might be broadened to download your private/public key into a smart card. That becomes an unforgeable electronic id to use for all manner of things such as credit card purchases etc. That gets more complex because you can lose the card or someone can steal it. You would thus want a digital photo, retinal scan and fingerprint in there and a way of electronically revoking the card.

The basic authentication mechanism very roughly is for the site to send out a random challenge phrase for the client to digitally sign and return (i.e. encrypt with the private key) along with the corresponding public key digitally signed by a certicate authority. Using only a root certificate containing the certificate authority’s public key, the site can verify the client’s public key and with the public key can decrypt the returned challenge phase. Only the holder of the corresponding client private key could have successfully encrypted the challenge phase that way. The site never gets to peek at the client’s private key (his password so to speak). The client’s public key is, well, public. It does not matter who sees it.

The neat thing about this process is it can happen very quickly, fully automated without you having to remember or look up anything. Never do your keys get sent out over the net or displayed on your screen.

The other way to get rid of passwords at ATMs (Automated Teller Machines), entry locks etc, is to scan a fingerprint or retina and see if they match the image on file.

There have been many solutions to this problem and the related Password Protector problem such as such as Microsoft account (aka .NET Passport, Microsoft Passport Network, Windows Live ID), Apple Keychain, Kerberos and PGP. Why have these schemes failed to catch on. I think there are three reasons:

  1. The schemes are perceived as too proprietary, to tied to one-platform.
  2. The instructions are too geekish. Encryption folk tend to be more interested in impressing you with their brilliance and explaining how it all works inside, than helping you get your job done.
  3. The user interfaces are still too geekish and clumsy. They need to be duck simple, requiring zero understanding of encryption theory. Encryption is usually an afterthought. It needs to be seamlessly built-in and transparent.
The blocks are political, not technical. To succeed you much figure out how to sell your solution to the world.
digital signatures

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products

Your face IP:[]
You are visitor number