Authentication is a critical part a Web Applications and it’s nearly present in all of them. Basically authenticating a user means verify if he is really who he says he is.

There are many ways to verify an identity, for example, when a driver get pulled over the officer will ask for the drivers license. He will check if the document looks original, if you look like the person in the picture, if the document is expired or not and even verify it’s number using some kind of database. If everything looks good he will grant or deny you access to the road.

On Internet it’s not very different. The most common way of identity verification in the Web it’s password check. In this case the user choose a secret word (or phrase) during the registration process and everytime he wants to access the application he needs to tell the website what is his secret. If it matches you will be granted access.

Bringing it back to the road example, it would be something like instead of having a drivers license document (paper or card) you just had to write down a secret word after passing the drivers exams and once you get pulled over the officer just ask you: “What is your secret?”. Does it feel safe to you? Well, that what happens when most of people access their email address everyday.

Worse than that, if your email (or application) provider doesn’t use HTTPS, if would be something like the officer asking you your password from the other side of the road and you having to shoult it with a crowd of people arround you. I’m pretty sure you would change your hypothetical drivers password after that (unless you don’t care if someone is driving using your identity).

So, what are the alternatives? After all we don’t want to turn the Web in an annoying bureaucratic place. Well, unfortunately, currently there are not a lot of user friendly alternatives but follow some of them:

  • Time-based: Relies on if you should be accessing this resource at an specific time. That’s not safe by itself but it can be useful when combined with other authentication methods.
  • Federated Identity: That’s roughly an outsourcing. Instead of trying to check the identity of the user the Web site will ask to someone else to check it. This identity verifiers are usually called IdP. That’s getting traction in the last years and among the most used IdPs we have Facebook, Google and Twitter. There is also OpenID and Mozilla Persona. This option is safer than password but in other hands it allows the IdP to know everything you are accessing (creepy!).
  • Two-factor: After using the password (first-factor) the system prompts a for a second code which varies in time (the code usually is valid for few seconds or minutes). This code can be generated by an specialized hardware, by an smartphone app or even be sent by SMS to pre-registered mobile number.
  • Pre-Shared Key (PSK): Probably the safest but hardest option. The application have to generate two files called public and private keys. The private key (also called certificate) is sent to the user who will have to install it on it’s browser. From now one no password would be asked anymore (unless the certificate is protected by password).
  • WebID: A variation of the PSK strategy. Basically instead of asking for the application to generated the pair of keys the client does it and send the public key to the servers. This way the user use the same pair to access all websites that implements the WebID pattern. Currently WebID is a W3C draft specification that can be found here: http://www.w3.org/2005/Incubator/webid/spec/.

There are many other strategies and the list above only represents a subset of them. We currently have technologies that can make identity verification in an accepted level of safety but most the Web Developers don’t know or simply don’t care about it. The number of passwords we are asked everyday makes humanly impossible to keep it so most users reuse their passwords in many different places. So if you are a Web Developer please try to avoid storing user’s passwords in your local database whenever it’s possible for the Internet’s sake.

Author: @seocam

Revisor: @marianamioto