[Zope] Zope security management

[John Morton]

On Mon, 19 Mar 2001 19:37:11 -0000 Phil Harris <phil.harris@zope.co.uk> wro=
te:

> Bill,
>=20
> There is another answer to part 2, use javascript to create an md5 hash o=
f
> the user,somesecret,password.
>=20
> 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.
>=20
> 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.=20

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