bjhess said the following on 02/15/2007 09:39 PM:
Thanks for the response, Anton.
I'm comfortable with the encrypted cookie. It's just that initial bit
of data being passed through upon login that I'm worried about. At
this point I'm not asking for any other critical data from the user.
I'd strongly suggest setting up a sniffer beside your machine and visiting
various web sites and see what they do as well. You'll be surprised how
some handle login and "basic HTTP Authentication".
By comparison the window of opportunity for that one event is much narrower.
However there are well established techniques to address your concern.
I'd still advise going though my list so you understand the boundary conditions.
The 'Right Way To Do It' is CHAP.
The user knows the password and so does the host.
pretty long. The host remembers that string.
The form uses the string as the key to encrypt the password.
(Or the other way round perhaps).
The encrypted string is sent to the host.
The host encrypts the password with its copy of the string.
Are the results the same?
Essentially this is the CHAP handshake used by PPP
and defined in RFC1994 and RFC2433
Its strength is that random string - 'nonce' - is different each time, so
seeing it once doesn't help.
Well you need the password as well.
The real downside is that this STILL doesn't protect you from dictionary
attacks. You still need a "three failures and disconnect and don't connect
again for 30 minutes" type of policy to address that.
So, back to getting the user to visit a site that downloads a key recorder
.... what then? An on screen keyboard perhaps?
Yeee! This takes me back to the 1980s when I was hacking UNIX to talk to