While we have many interesting modern authentication methods, password authentication is still the most popular choice for network applications. It’s simple, it doesn’t require any special hardware, it doesn’t discriminate anyone in particular. It just works™.
The key requirement for maintaining security of a secret-based authentication mechanism is the secrecy of the secret (password). Therefore, it is very important for the designer of network applications regard the safety of password as essential and do their best to protect it.
In particular, the developer can affect the security of password
in three manners:
- through the security of server-side key storage,
- through the security of the secret transmission,
- through encouraging user to follow the best practices.
I will expand on each of them in order.
Continue reading “Password security in network applications”
Recently I’ve been working on implementing SSL authentication in Okupy (as you can see from the previous post). The specifics of chosen solution required the authentication to occur on a separate virtual host. Due to specifics of django, it was impossible to directly access the initial session from the dedicated vhost.
I had two possibilities. The supposedly simpler one involved passing the session identifier to the dedicated vhost so that it would be able to access the session information and store the authentication result there. But it involved hacking a fair bit of django (since the new versions no longer give access to the session identifier directly), starting the session early (it needn’t be started until the user is actually authenticated) and could introduce security issues.
The other involved passing the authentication results outside of the session framework and using dedicated tokens to claim the results. Those tokens have similar requirements to the tokens used e.g. for e-mail address verification.
First of all, the tokens must be guaranteed to be unique. Otherwise, there would be a finite probability that two users will be given same token. In case of e-mail address verification, this would mean that one user could confirm the other user’s (possibly invalid) e-mail address. In case of SSL authentication, one user would be able to claim other user’s login.
Secondly, the tokens need to be semi-random and hard to guess. The user, being able to obtain multiple valid authentication tokens in sequence (e.g. through requesting multiple valid e-mail account verifications), must not be able to predict the value of the token for another (possibly invalid) address. At least with reasonable resources.
Continue reading “Getting tokens for verification”
In this year’s GSoC, I’m co-working on identity.gentoo.org that intends to become a central place for logging in to various Gentoo sites. One of the fancy features that I’d like to implement is SSL-certificate based login.
The client certificate-based authentication is a kind of public key authentication. In order to login, you provide the server with your certificate (containing your public key) and a signature made with your private key. Your private key is never exposed to the server which greatly improves security, and you don’t have to have a store of random passwords.
Unlike many common authentication methods that are implemented in application space, client certificates are part of the SSL/TLS protocols. As a result, they’re supported quite widely by web browsers. But this also introduces a few limitations that will affect the use.
Continue reading “SSL certificate login for okupy”