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...