[sldev] [POLICY] Development by consensus (Re: Question regarding upcoming maintenance on 11/27-

[Matthew Dowd]

>. As I discovered
> with the Fedora 8 curl bug, packet sniffing confirms the client DOES
> authenticate over SSL.

I never argued that the client doesn't use SSL. Also using MD5 Challenge/Response and using HTTPS are not mutually exclusive. You can do both.


> And it better be properly checking the server
> certificate. If so, the client will NOT send your password to a non-LL
> server.

Well, the fact that there was so much fuss when it was found that you could construct a URL which would cause the client to authenticate against a malicious server, would suggest that this isnt' the case. Actually what you propose is not desirable for the Open Grid vision.

There are a number of different levels of authenticating the server via SSL:

1) do no checking at all
2) check that the URL matches the one in the certificate but do not check the certificate itself
3) check that the certificate is signed by a recognised root certificate authority but do not check the URL against the certificate
4) check the certificate is signed by a recognised root authority, and the URL matches the one in the certificate
5) check the certificate is signed by a recognised root authority, and the URL matches the one in the certificate, and that the URL and/or certificate is from LL

(1) and (2) offer no protection at all. The phisher just self signs a certificate 

(3) and (4) will put off the wannabe phisher. They will also put off those wanting to experiment with OpenSim and running their own sim in the OpenGrid future, if they have to fork out for a certificate from verisign etc. It will not put off the determined phisher who will just use stolen credit card details to get a valid (disposable) certificate.

(5) blows the OpenGrid vision completely out of the water!

Out of these, my suspicion is that SL currently does (1), possibly (2) but hopefully others can confirm/deny this. of course, iincreasing the checks on the certificate authenticity could be done in the current authentication system.

When we do have alternative grids to LL, there is a very typical use case which MD5 challenge response solves:

I have an account A on the LL grid. I'm interested in using an alternative provider Grid G but for various reasons decide to create a new account rather than use Grid cross-authentication (perhaps Grid G is my employers grid and I want to keep my professional and personnal SL's seperate; perhaps I'm not sure how trustworth Grid G is). Both the LL and Grid G have valid Verisign verfied certificates.

So I'm using the same client logging onto LL as account A, and Grid G as account B. The chances of accidently typing in the username/password for account A when attempting to connect to Grid G are pretty high. SSL does not protect me here - under such circumstances, Grid G has received my username and password for LL Grid! If MD5 Challenge Response was also in use in addition to SSL, Grid G would not get my username and password under such circumstances.
 
> And as I've pointed out, challenge-response is NOT the most secure
> solution. It requires the server to have long term knowledge of your
> password, which leaves you vulnerable to the back end authentication
> server being hacked. Which HAS happened.


If you are using MD5 challenge response you can still store password hashes in the backend database. Basically, the user types their password into the client, the client generates the hash, and then the hash is used as if the password in the MD5 challenge response process. If the backend database is compromised, someone could use a modified client which allows them to type in the hash directly in order to log in as someones account, but if someone had get into the authentication server, that service is already pretty compromised! It would pretect you from someone attempting to use your password on other accounts (in the hope that you foolishly use the same passwords for multiple services).

Of course, hashing is of limited protection if someone has grabbed the backend database, as they are now in a position to run large scale dictionary attacks on the hashes at their leisure on their own equipment!

It would be interesting to know if the SL user database current stores passwords ot hashes (and whether passwords have to be stored in other for the wiki, jira and support logons to work), and if they do whether there are any plans to change this.

Matthew

_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk