Hi folks,
AFAIK there hasn't been much work on the authorization mechanisms in
DotGNU for the last year. With DGv1 approaching it seems to me that
it's important to have a clear view on this.
A number of approaches are possible in authorization:
* Password
* Public Key Infrastructure
* Biometric
The strongest possible authorization I can think of is a PKI with
biometric data instead of a passphrase. That's not realistic however.
First of all biometric input devices are not yet widespread. Second
biometric data can, like all data, be copied. Third dragging your
private key along everywhere you go is rather irritating.
For the third problem the middle man authorization software (the Auth
Server) can offer a solution by storing the private key on a remote
server and letting the server authorize on request of the user. That
destroys the advantage of the private key system (two data sets you
need: key + passphrase) however.
Plain old password authorization is not good either since users tend
to use really dumb passwords like 'secret' or 'sparky'.
Given these problems I'm strongly for the following approach:
* Each user has a private key he/she drags along on a floppy or a
similar physical medium.
* Each user has an account with an Auth Server. In that account
another public/private key set is stored.
* To access the Auth Server the user must use his/her 'floppy key'.
* If the user connects to the Auth Server from an IP address (and/or
some extra info like username) that's not one of the usual addresses
of the user an extra password is needed (password must be reasonably
secure (GNU/Linux login password kind of secure)).
* To access a webservice the user must use the key on the Auth server.
* Every so often the user must change his/her floppy key.
* There is also a password only access to the auth account possible,
but the user can't change the password of this one and the password is
pretty large and perfectly random (something like a 20 character
string).
* Last but not least a block command can be given by the user to the
Auth server with a reasonably secure password. The block command makes
it impossible to use the private key until the super-password (20 char
string) has been entered. The block command also automatically signals
the user. Note that the block command does not revoce the private key
stored in the account (to avoid abuse).
The advantages are that the key the user drags along is not usable for
anything but the auth account and is changed often enough to make it
pretty useless to steal. Due to the fact that an extra password is
needed to get into the auth account you can't simply take the
passphrase and key and get into the account from your own box. Trying
to do a trick with IP addresses, hostnames or stuff like that won't
work because of the extra information in the usual addresses database.
Thus it's pretty unlikely that a cracker will be able to compromise
the Auth Server account (unless the user is a moron, which
unfortunately is all too often true ;-).
Now I admit that having 4 passwords for one account seems much, but it
isn't. First of all you only need to remember three, the
super-password is one for the safe (physical safe that is). Since the
remaining three passwords will safe you a lot of other passwords
(every system that uses DotGNU public key auth doesn't need any other
passwords) it's pretty easy to do.
When authorizing at a webservice at the start of a DotGNU webservice
session this happens:
* User authorizes at Auth Server.
* User requests Auth Server to authorize him/her at the webservice.
* Auth Server authorizes user and gets session key from webservice.
* Auth Server sends session key to user over the SSL connection with
user.
* User and webservice are connected.
Some problems stay, if the user is a moron no system can secure him
and if the Auth Server is malicious you have a big problem. The first
problem can't be solved (but is no big deal), the second problem is
already addressed by existing PKI solutions (web-of-trust, trusted
third parties).
Greetings,
Peter
_______________________________________________
Developers mailing list
address@hidden
http://dotgnu.org/mailman/listinfo/developers