This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.
This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.
Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.
Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.
You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.
Please do not email me about this project without reading the disclaimer above.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:
|recommend book⇒20,001 Names For Baby|
|by||Carol McD. Wallace||978-0-380-78047-1||paperback|
|Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.|
Every site has its own rules for composing a password.
This does not work! Why?
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:
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:
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:
This page is posted
Optional Replicator mirror
Your face IP:[184.108.40.206]
You are visitor number|