On Mon, 19 Mar 2001 19:37:11 -0000 Phil Harris <phil.harris@zope.co.uk> wrote:
Bill,
There is another answer to part 2, use javascript to create an md5 hash of the user,somesecret,password.
This can be sent instead of the password and then validated on the server side, since the username and md5 hash is all that is sent across the wire, it should be a lot more secure than plain text.
I have a library for javascript md5 if anyone is interested (which,btw, I 'stole' from the PHPlib ;) ).
This method, as described, will not protect you from traffic sniffing at all. Where the attacker was sniffing for username and password combinations being submitted to the login page, they now sniff for an MD5 sum that will do the same job. Once in, the attack probably won't have too many problems changing the password to something they know. What it comes down to, is that any regular form based (initial) authentication scheme will involve sending authenication data using a known, and necessarily publicly accessable formulation (the login form) to a known and public URL that will decide whether to authenticate the user or not. As a result, an attacker can trivially find out what an authenication token should look like, and extract them at their leisure. You could probably transform the simple passive sniffing attack to a more complex man-in-the-middle attack by including a unique id for each login form hit and only accepting authentication tokens with a given id once. An attacker would need to intercept the authentication token and use it instead of the user in order to gain access. Coupled with short timeouts on the live ids, and a policy that users can only be logged in once, and you'll have tighter security than a plaintext password system - but it's still nowhere near as good as using SSL so that authentication tokens cannot be distinguished from any other traffic in the stream. John