|
|
# Current Auth schemes
|
|
|
|
|
|
Here we will take a look at what we can do with the current authentication and encryption schemes.
|
|
|
|
|
|
Please keep in mind our [Requirements](Requirements) when reading this page.
|
|
|
|
|
|
## Encryption
|
|
|
|
|
|
For obvious reasons we won't take into consideration tunnelling solutions like VPNS or IPSEC.
|
|
|
They are all difficult to set up (from a user point of view) and this just isn't the right use-case for a VPN.
|
|
|
|
|
|
Here we are left with few choices:
|
|
|
* SSL
|
|
|
* TLS
|
|
|
* DTLS
|
|
|
|
|
|
The fun part is that all these options are not so different one from the other.
|
|
|
TLS is an evolution of SSL, and DTLS is TLS over UDP (very simplified, ok, but you got it).
|
|
|
So there actually is no choice in the matter, which is why attacks like [BEAST](http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack) or [CRIME](http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29) have suck a huge impact and made everyone so afraid.
|
|
|
|
|
|
The good news is that these protocols have been thoroughly tested and are considered secure by all the experts.
|
|
|
|
|
|
And if you need just the encryption, these are perfectly fine.
|
|
|
|
|
|
But what are the differences?
|
|
|
|
|
|
### SSL
|
|
|
|
|
|
SSL is the older one, from version 1.0, 2.0 (both unused and insecure) to 3.0 (insecure, still used).
|
|
|
|
|
|
This protocol supports encrption with a single X.509 certificate, and user identification. multiple authentication schemes are supported, so passwords or certificates are fine.
|
|
|
|
|
|
As [wikipedia](http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_3.0) puts it, TLS 1.0 is actually better, but its still widely used.
|
|
|
|
|
|
One of the main drawbacks of SSL is that it does not play nicely with virtual hosts -- that is, trying to have multiple certificates on the same listening port. Just use TLS if you can.
|
|
|
|
|
|
This protocol has recently been deprecated and is being phased out in favour of TLS
|
|
|
|
|
|
### TLS
|
|
|
|
|
|
As the evolution of SSL, it has better key-derivation functions, supports virtual hosts, and has a better general security.
|
|
|
Attacks are recently starting to target TLS, too (POODLE), but the protocol _per se_ seems secure
|
|
|
|
|
|
Still, we have 3 versions of it (1.0, 1.1 and 1.2), and the browser support for the last ones is pretty bad (getting better) :(
|
|
|
|
|
|
### DTLS
|
|
|
|
|
|
This is the version used for datagram-oriented connections (as the name implies).
|
|
|
|
|
|
The versions here are the same as in the TLS, and the security is the same.
|
|
|
|
|
|
Over the years some encryption algorithms have been found weak or broken, and it's the job of the programmer or the system administrator to know which are the good one and which are not.
|
|
|
|
|
|
### Auth problems
|
|
|
|
|
|
Note that although all these protocols can manage users, those apis are rarely left accessible by an application server to the application.
|
|
|
|
|
|
That is a possible problem with Fenrir, too: its flexibility should encourage application servers to expose the right api calls, but at the moment no naming or API convention is up for that, so we are risking API naming incompatibilities, although applications are usually written for a specific application server, or follow unspoken standards (see HTTP webservers).
|
|
|
|
|
|
### QUIC & Curvecp & MinimaLT
|
|
|
|
|
|
There area actually some protocols that deserve a page on their own, [CurveCP](CurveCP) and [QUIC](QUIC).
|
|
|
|
|
|
CurveCP is a nice alternative, but it has (IMHO) some inefficiencies. Doesn't do much for authentication (like TLS, &co) and gives the user a TCP-like stream (no messages/multiple streams like Fenrir).
|
|
|
|
|
|
The author of CurveCP also participated on an other protocol, [MinimaLT](MinimaLT). You might want to check it out, it has interesting proposals.
|
|
|
|
|
|
## Authentication
|
|
|
|
|
|
Here we group together identification, authorization, accounting and all the stuff you can do on a user.
|
|
|
|
|
|
The most common possibilities right now are:
|
|
|
* SSL/TLS
|
|
|
* [OAuth](OAuth_Hate)
|
|
|
* Kerberos
|
|
|
* OpenID
|
|
|
|
|
|
### SSL/TLS
|
|
|
|
|
|
We already discussed about this. It works, it's not really safe anymore, but the main problem is that you can only authenticate **before** the connection takes place.
|
|
|
And not all application servers then expose apis to get the user id or login.
|
|
|
|
|
|
### OAuth
|
|
|
|
|
|
Well, I'm [not a fan](OAuth Hate) of this one. Inefficient, with lots of places to screw up your implementation, totally incompatible with other implementations, useless application identification etc...
|
|
|
|
|
|
Still, it can be used. It provides both user identification and (somewhat) authorization.
|
|
|
|
|
|
### Kerberos
|
|
|
|
|
|
Most of you surely know this one, it's a safe and tested (version 5 at least...), standard and federated authentication protocol.
|
|
|
|
|
|
But it requires the client and the server to have synchronized clocks. Which is difficult or impossible on the Internet, and the protocol to synchronize clock itself is not always secure.
|
|
|
|
|
|
The good thing is that it's one of the first big token-based protocols, and it made a big and clear distinction between authentication server, service and client.
|
|
|
|
|
|
### OpenID
|
|
|
|
|
|
This one is just for user identification.
|
|
|
|
|
|
It's a nice, HTTP-based federated authentication protocol, and the only thing that you need is a url for a webpage.
|
|
|
|
|
|
There are lots of implementation, it's not very efficient, but widely used.
|
|
|
|
|
|
|
|
|
## The best combo
|
|
|
|
|
|
|
|
|
Right now the best way to do authentication for your application seems to be TLS + OAuth.
|
|
|
|
|
|
Again, I'm not a huge fan of it, but assuming you have a cryptographer near you that will explain you why your OAuth implementation is hackable, it's usable.
|
|
|
|
|
|
Of course, Fenrir is supposed to solve this mess and half-done protocols and fuse them together :) |