What is authentication?
Authentications is the act of figuring out who the person is that tries to access a system, an application or a website. Authentication is not authorization. Authorization is controlling access based on who tries to access the object. And often also at what time access is allowed and what is required to get access. Authentication is generally required for authorization.
How authentication is done today.
Most websites will store a username, password and email of every user. Everyone who has access to that mailbox or who knows the username and password is identified as a valid user. Some sites started to use email addresses as loginnames, to reduce the things a user has to remember. (Who would forget his/her own email address?)
A better way to identify people on the net
The industry standard for assuring that a website is authentic is SSL (Secure Socket Layer). It is available in almost every browser. SSL is also used to sign email and to encrypt email. SSL emails certificates are freely available from CAcert and Thawte. Both CAcert and Thawte do have an assurance program to verify the real identity of a person.
So using SSL you can prove that you're the owner of your mailbox and that your real identity is verified. It is easily possible to use the same certificate which is used to sign your mail to prove to a website that you are who you say you are. The only problem is that hardly any websites uses that information.
The old scenario
- go to example.com
- click sign-up
- enter you're email address, loginname and password
- reply the email which is send to verify your email address
- login using that loginname and password
The new scenario
- go to example.com
- click login>
- you're prompted to enter the password for your private key
There is no sing-up needed in the new scenario because with your certificate you provide an email address which is also you're username. And a password is not needed. The same certificate can also be used for other services like LDAP. You don't have to worry that some sneaky admin will read your password, because it isn't stored or send to that server.
It's obvious that the new scenario is much better than the old scenario from the user perspective. But from the server admin perspective it's also better. No need to store passwords, the only thing which is stored is the email address. No more fake identities either. If an SSL certificate is stolen or found to be fake it can be revoked, passwords can't be revoked.
There are some drawbacks.
- No Anonymity. You're not anonymous anymore. Allowing logins/passwords will solve this problem.
- People need to get an SSL certificate. It's free, but for ultimate security it the identity of a person should be verified face to face. This problem could also be solved by also providing username/password logins
- People need to carry their SSL keys with them. Smartcards could be a solution to this.
- You need to trust the CA's or be your own CA (in the latter case people do need to sign up again)
Some minor problems
Websites do have to store a list with CA's (Certificate Authorities) which they trust. The root certificate from CAcert is not yet shrink-wrapped with browsers and other software, so it has to be added manually.
Most Linux programs use their own certificate store. (cert8.db, key3.db and secmod.db) This is really bad. It can be easily solved by symlinking all those files to ~/.sslcert/key3.db and such.
user1@node1:~$ find . -name key3.db ./.gnome2/epiphany/mozilla/epiphany/key3.db ./.mozilla/default/jv480jgt.slt/key3.db ./.mozilla/firefox/default.1fm/key3.db ./.evolution/key3.db
Client authentication using SSL can really improve the situation in which someone has to remember a loginname and password for many websites, email and lots of other services. However, SSL logins won't completely replace password logins.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.