On 1/23/07, William Allen Simpson william.allen.simpson@gmail.com wrote: [snip]
Speaking to elements of the recent thread, I'd prefer SSL instead of home-grown challenge-response algorithms.
[snip]
On this subject... Wrapping the login site via SSL sounds like a dandy idea, and it sidesteps the whole mess of cert issues if with SUL we were to use a single login portal domain.
However, then we've just pushed the problem back to session cookie theft. Sure, it would still be an improvement since a passive attacker (at say Wikimania...) couldn't sit back and gather passwords, but better still might be possible.
What the current industry best-practices with respect to binding session data to a client's IP? Do web browsers switch IPs too often for this to be acceptable (AOL?)?
At some point it might make sense to talk about all logged in user sessions being SSLed... the overwhelming majority of the computational load of SSL is the RSA stuff for signatures which would need to happen once per login if we went the SUL login page behind SSL route.. After that it's just symmetric crypto which isn't astoundingly expensive.
Were we to move logged in users into SSL all sorts of threats just go away. Of course there is the little matter of plain squid not supporting SSL offloading like some of the commercial reverse proxy / acceleration solutions which would have to be resolved...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On this subject... Wrapping the login site via SSL sounds like a dandy idea, and it sidesteps the whole mess of cert issues if with SUL we were to use a single login portal domain.
However, then we've just pushed the problem back to session cookie theft. Sure, it would still be an improvement since a passive attacker (at say Wikimania...) couldn't sit back and gather passwords, but better still might be possible.
What the current industry best-practices with respect to binding session data to a client's IP? Do web browsers switch IPs too often for this to be acceptable (AOL?)?
My impression is that the most likely actual scenario for network sniffing is an open wireless network behind a NAT -- so everyone will have the same IP on the outside anyway.
Binding to IP probably protects more against cookies grabbed via XSS (but then you can probably do your nasty things in JS).
AOL is a problem, with the switching of the IPs...
At some point it might make sense to talk about all logged in user sessions being SSLed... the overwhelming majority of the computational load of SSL is the RSA stuff for signatures which would need to happen once per login if we went the SUL login page behind SSL route.. After that it's just symmetric crypto which isn't astoundingly expensive.
Were we to move logged in users into SSL all sorts of threats just go away.
That gives me warm fuzzy feelings, if we can in fact swing it cleanly. :)
Of course there is the little matter of plain squid not supporting SSL offloading like some of the commercial reverse proxy / acceleration solutions which would have to be resolved...
Details, but details to think about.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
Gregory Maxwell wrote:
Were we to move logged in users into SSL all sorts of threats just go away. Of course there is the little matter of plain squid not supporting SSL offloading like some of the commercial reverse proxy / acceleration solutions which would have to be resolved...
As I said in my post with subject "HTTPS virtual hosting", you can use LVS to redirect HTTPS requests to wherever you like. We're using apache as an HTTPS reverse proxy for secure.wikimedia.org, but there's plenty of other open source solutions to try if that doesn't prove to scale well enough.
-- Tim Starling
Gregory Maxwell wrote:
On this subject... Wrapping the login site via SSL sounds like a dandy idea, and it sidesteps the whole mess of cert issues if with SUL we were to use a single login portal domain.
However, then we've just pushed the problem back to session cookie theft. Sure, it would still be an improvement since a passive attacker (at say Wikimania...) couldn't sit back and gather passwords, but better still might be possible.
A session cookie will expire. A password probably not, would allow to change password, etc.
What the current industry best-practices with respect to binding session data to a client's IP? Do web browsers switch IPs too often for this to be acceptable (AOL?)?
It could be less acceptable to normal users if each time they switch on their computer had to type their password :S
Ideally, that sesion cookie would be a shared secret stored by the browser, used to compute the (edit) tokens. AFAIK this is unfeasible as today, unless you force a custom browser.
Another approach could be changing the session cookie too fast (e.g. each 3-4 requests), so a cookie theaft couldn't reuse an old cookie.
On 1/23/07, Platonides Platonides@gmail.com wrote:
A session cookie will expire. A password probably not, would allow to change password, etc.
Yes. Session cookies don't also let someone get into your bank account (true for many folks).. etc.
It could be less acceptable to normal users if each time they switch on their computer had to type their password :S
True.
Ideally, that sesion cookie would be a shared secret stored by the browser, used to compute the (edit) tokens. AFAIK this is unfeasible as today, unless you force a custom browser.
All we need to do is add a kerberos agent to the browser.... and.. :)
Actually, JS can read and cookies, and thereby use them as a datastore. Based on prior threads about JS based challenge response... it would actually be possible to do this.. but only with a ton of JS hackery. (I.e. client side JS computes cookie=H(uid+password) and stores it as a cookie server also stores this, server would occasionally challenge the client to compute H(cookie+counter) ... but without server authentication there is no way to prevent an active MTM attacker from using the client as an oracle).
Another approach could be changing the session cookie too fast (e.g. each 3-4 requests), so a cookie theaft couldn't reuse an old cookie.
As I said before.. SSL makes it all the issues go away. As a long term project we should probably figure out how to make SSL work for us, and not waste time with hacks. Any other path will result in us reinventing SSL poorly.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
As I said before.. SSL makes it all the issues go away. As a long term project we should probably figure out how to make SSL work for us, and not waste time with hacks. Any other path will result in us reinventing SSL poorly.
You mean like this?
:D
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On 1/23/07, Brion Vibber brion@pobox.com wrote:
You mean like this?
Dear lord. Thanks a lot for showing me this, I don't think I'm going to be able to sleep tonight.
RSA encryption on my system with the RSA implimentation they are using takes about 200ms.. Thats a lot faster than I would have expected.
Gregory Maxwell wrote:
Actually, JS can read and cookies, and thereby use them as a datastore. Based on prior threads about JS based challenge response... it would actually be possible to do this.. but only with a ton of JS hackery. (I.e. client side JS computes cookie=H(uid+password) and stores it as a cookie server also stores this, server would occasionally challenge the client to compute H(cookie+counter) ... but without server authentication there is no way to prevent an active MTM attacker from using the client as an oracle).
I alredy though on that. But if the datastore is a cookie, what do you think the brwoser will do with that cookie? *Send it to the server* Which is precisely what we try to avoid. There's a MS extension to avoid JS touch some cookies, but AFAIK there's not the opposite thing.
PS: A very interesting lib, Brion.
wikitech-l@lists.wikimedia.org