The login form

Monde en
1

Oops. I forget to reply all.

Begin forwarded message:

From: Thomas Sutton <thomas@bouncingorange.com>
Date: 7 July 2008 11:17:26 AM
To: Gilles Vincent <gilles.vincent@gmail.com>
Subject: Re: [Spip-en] The login form

Hi Gilles,

Thanks for the reply.

On 04/07/2008, at 11:25 PM, Gilles Vincent wrote:

Hi,

I don’t understand why you want to change the actual login form :
it’s a « normal » form with 2 fields : the login and the password (in the latest version in fact).
Where is the problem here ?

That’s the problem I’m having: it isn’t a two field form. It’s a one field « Login » form followed by a one field « password » form.

My aim in modifying the form was to display a generic form of two fields all the time. While I was at it, I tried to remove the bits that change the s ID field to include the username, etc. as these don’t make sense unless the form is more than one step (and even if it is, I’d argue). I’d also like to stop it from remembering the user – most of the computers used to access it are shared, and I think that that’s up to the user and the web-browser to do anyway. Finally, I tried to make the various message when the username and password are the same, to make it harder for someone to guess a valid username.

I got it to display both fields, but haven’t been able to figure-out how to do it in only one submission…

I’ve just made a screencast that explains how the login form works :

  • The action is the same url (and the form can display errors).
  • When loaded, the form contains several hidden values that will make the submit action secure.
  • When the password field keeps the focus, the form verifies that the encryption parameters are OK, and indicates it with a brown padlock.
  • Before been submitted, the password is encrypted with two md5+salt, and the non-encrypted password field is erased : Therefore the password is never sent to the server and can’t be catched by a bad guy. That makes the login form really secure !
  • After that, the server calculates the md5+salt values of the password in database. It compares these value to the encrypted values sent by the form. If both values match, the password that has been submitted is correct. Elsewhere it’s bad and SPIP returns to the login form with an error.

The screencast is here : http://screencast.com/t/eiiGjNt7

Thanks for this, it’s interesting to see it explained by someone who knows how it all works.

I still think that this security is worse than worthless: if I can capture the password, then I can also capture the session cookie and hijack the session (which I’ve done with to a few of our SPIP sites hosted locally and remotely). The only effects of the current password protection is to force attacks to happen in real time (which is even easier than doing them offline) and to give people a feeling that they are protected when, in fact, they are susceptible to exactly the same risks as without the hashing.

These sorts of risks can only be eliminated by using a secure channel (like SSL) or using a strong authentication system (like Kerberos). They could also be reduced, but not eliminated, by using nonces throughout the whole of the back-end – rather than just the login – and by checking IP addresses (though anyone who can capture traffic, can probably also spoof the originating IP address).

This is not to say that I think that no though should to be given the security of the system. I just think that adding the ability to require SSL for /ecrire/ and then moving on to real features is both more secure, and probably also a more effective use of the developers’ time. Nor do I think that this is a real security risk for SPIP. Indeed, this is far more effort toward security than almost any web-app that I can think of. I just don’t think that there is any real reason to do it.

2008/7/4 Thomas Sutton <thomas@bouncingorange.com>:

Hi folks,

I think I mentioned on the list that I’ve been working on a site with a « members only » section protected by #LOGIN_PUBLIC and <?php if ($auteur_session) { ... } ?>. It’s recently gone live, but we’ve got a few lingering problems with the login form.

I’ve tried to tear all of the JavaScript and dynamism out of formulaires/login.html but this has introduced a bug where the sites’s members must enter their username and password and click login twice before SPIP will log them in. Can anyone provide pointers (to documentation, if any exists, and) about making SPIP’s authentication system act like a normal form?

Once again, thanks for the reply, and I hope that my points make sense.

Cheers,

Thomas Sutton
Web Developer
bouncingorange
graphic + web design