The major problem with security of web applications is that the client sends the login name and password in plain text if https isn’t available. A nasty person with access to the network could use ARP poisening alongside packet sniffing to acquire the login, which wouldn’t really be desirable.
I stumbled accross a very interesting piece javascript which implements the md5 hash algorithm: http://pajhome.org.uk/crypt/md5/.
Using a hash makes it impossible to reverse engineer a password and makes authentication safer. An issue with this is that you only require the hash, not the password to get in. To prevent this the password should be salted before hashed.
Basicly a secure authentication via http would look like this:
Client sends request for login to server.
Server sends the login form which includes a login id and salt to the client.
Server stores the login id and salt it sent to the client.
Client sends the hash of the filled out password and received hash alongside the login id from the server to the server.
Server checks whether the hash of the password in the database and the received hash combined with the login id are valid.
Server sends whether authentication was a success.
Maybe I’ll implement an example application :-). In any case I hope that this will be employed.
Update, most authentication system used by webbased software are still vulnerable and would almost neglect the use of this by being able to hijack a session by just getting the session key. The client however could also implement javascript to use a similar method with a salt to protect the session key. The problem still is that it is extra overhead on the client and that not every client has got javascript enabled.
An interesting idea,
It would indeed make it harder for the application to be hijacked, it would need to be a random salt produced each time however – which would mean the initiating of a session class of some sort just for the login.
I can see some very practical uses for this method… Perhaps you could create the salt based on a few “magic” ingredients (Time, date, IP etc).
The salt would offcourse be random, and it would be quite safe when it would be a very big random string (~32 bytes). Which makes it virtualy inthinkable the same 2 salts are used ever, which makes the chance of a certain hash still being hijacked and used with the same salt neglectable.