On 1/23/07, William Allen Simpson <william.allen.simpson(a)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...