Hi Gilles,
Thanks for the reply. I’m finding this discussion quite interesting (as you can tell by the length of my replies 
).
On 08/07/2008, at 4:00 AM, Gilles Vincent wrote:
2008/7/7 Thomas Sutton <thomas@bouncingorange.com>:
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.
This has changed since : now (with the svn) it’s a quite standard 2-field form (look at the screencast)
Yeah, someone else (Fil?) mentioned this. I think that it’s a change for the better. I’m looking forward to the new release for this and other changes. All of the differences that I’ve noticed so far in the back-end of spip-svn are excellent.
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
I don’t think so :
If you can capture the password, you can capture the login two. And you don’t have to hijack the session because you just have to login to the admin area. How did you manage to hijack the session of SPIP ?
During login, SPIP sets two cookies called spip_admin and spip_session. You can manually set these in many browsers and all tools that a hacker could use to script automatic attacks (curl, wget, etc.). spip_admin has a value like « %40thomas » and spip_session has a value like « 1_700a05cfa77b8eaae0f7b3ea9be7598d ». If a client program has those cookies set and accesses /ecrire/ of one of our sites before I’ve logged out or the session has expired, then they are me. They don’t need to know my password.
I used Firefox with the Firebug and Firecookie extensions. Just login to your site as normal in some other browser (I used both Safari and Camino). Then view the cookies for your website. In Firefox, visit the front-end of your web-site. Use the Cookie tab that Firecookie adds to Firebug to create spip_admin and spip_session cookies using the values in your other browser. Navigate to /ecrire/ and you’re logged in without using the password. If you have multiple computers, you can login on one and hijack on the other, even if they are on different networks.
There are several tools around that can be quickly scripted to watch for SPIP sessions on the network, capture these cookies and, using them, create a new author, or change the password of the current user, or whatever.
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.
Do you think that the actual protection is not enough secure ?
The md5 use a salt factor wich is changed randomly at each call. What is the risk of such method, and do you have a better solution (double-hash ?) ?
I think that the login form is too secure, if that makes any sense. It protects one thing (the password) very, very well, but other almost as import factors are not protected. As it stands, the password encryption technique that SPIP uses is very good, but it is wasted to some degree because the rest of the system is not equally secure. We have an enormous gate 2m thick, 10m tall, made from reinforced steel with fingerprint scanners and automatic machine guns, but our fence is 1m tall and is made from wood.
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).
Ok, I agree for the ssl and Kerberos
What are « nonces » ?
A nonce in computer security, cryptography, etc. (it has other meanings in other contexts) is a small random value attached to each request <http://en.wikipedia.org/wiki/Cryptographic_nonce>. They are usually used to prevent attacks where an attacker captures tokens (the session cookie, the encrypted password, etc.) and reuses them. The random salts, for example, are nonces: even if I can capture an author’s encrypted password, the random value incorporated with it means that it is already invalid by the time I’ve captured it.
If SPIP used a similar random value for each session and changed it every request, or every action, it’d make it more difficult to exploit captured sessions: the attacker would need to use the session and nonce they captured before the user.
Logging the IP address that logged in for a session and checking that each request came from the same address would also help (again, making it harder, though not impossible, to hijack a session). It’d also be a much smaller change.
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.
We can’t impose SSL because a lot of users can’t install such system (especially for shared hosting)
But working on a better secure login + restriction is certainly a good challenge, because the actual protection is quite old and hacking methods have evolved since…
I think that extending SPIP so that site owners can, if they need to, require SSL for /ecrire/ would be easier than adding any of the other techniques I mentioned. I’ll see if I can come up with some code, but I still get lost trying to find my way around the SPIP code so it might take a while.
Finally, I want to repeat that I don’t think that SPIP is any less secure than any other open-source web-application and is probably more secure than Drupal, WordPress, TextPattern, etc. which don’t bother with hashing passwords in transit. I don’t believe that it’s much more secure, but certainly isn’t less.
Regards,
Thomas Sutton
Web Developer
bouncingorange
graphic + web design