I just realized there are some easily exploited security problems connected to the one user account for multiple sites scheme Antville is using. Just imagine a site owner changing the login form so that its input is sent to another server which he controls. The password sniffing may even go unnoticed if the request is then redirected to the actual antville login.

Well, of course the single login for multiple sites is a very cool feature, so here's some crypto to the rescue to make antville a temper-proof application.

The basic idea is to send a secure hash algorithm (SHA) implemented in Javascript along with the login form and have it send the secure hash instead of the password itself back to the server. Now of course this is also not secure if the hash is always the same for the same password, since knowing the hash product would suffice to log in. So here's the full scheme:

When the server produces the login form, it generates a random string, stores it in the user's session cache and sends it along with the login form. On the client side, the login submit script adds the password the user entered to the random string it got from the server and calculates a secure hash on that combined string and sends it to the server. The server takes the random string it sent , adds the user's actual password from the DB and checks if it gets the same secure hash. If yes the user is logged in. As far as I understand, this should be a pretty secure, since any sniffer had to get both the random string and the password to reproduce the hash product.

Anybody eager to implement this for Antville? Shouldn't be too hard, since the SHA algorithm is already available in Javascript (see link above).

your thinking machine is running fast these days. i'll look into this.

a couple of security issues for manila sites may arise here. i know that manila always does referer checks when objects are created or edited. theoretically, it is possible to build evil websites outside antville and trick a logged-in antville (or manila) user to click on buttons.

more important: it should be possible to block certain html tags, javascript and antville macros in responses and stories (not written by the admins). i don't want to explain in public how this can be exploited, but i guess you get an idea.

so, encryption on the client-side is done by using this JavaScript-function, right? but the admin of a weblog is still able to modify every single piece of HTML which is sent to the client, so how do we prevent him from disabling this?

another (minor) issue would be that users with javascript disabled wouldn't be able to login in anymore (not that i know anybody, but i'm just thinking).

or did i get sthg. wrong?

isn't it also problematic that helma does not make any distinction between requests sent via "post" or "get" method?

it's much simpler to code, that's for sure.