[patch] Client-side encoding of admin logins

[Chris Beaven]

Currently, passwords are sent via plain text when logging in.
Even though HTTPS is the ultimate solution, it would still be far more secure for clients to be able to send a digest instead. This has been discussed in #61, but the ticket description doesn't cover this specifically.

The patch attached lets the client handle hashing the password first if Javascript is enabled.

Passwords will be upgraded to a new algorithm which uses a psuedo-random salt based on username. This way, the client can calculate the salt rather than require a challenge-response.

Rather than sending the database hash, the hash itself is hashed for extra security.
The server provides half a random salt in the login form and the client generates the other half.

The server checks first against this secure password, then falls back to the raw password.

[jim-django@…]

So rather than looking in the corner of their browser for the well-known padlock to know their data is safe, they now have to read through javascript sources and decide if whether or not to trust the developer?

I don't like it. Using javascript for a solved problem "because you can" is not a good plan.

[Jacob]

I agree. HTTPS exists for a very good reason, and giving developers ways of working around a truely secure solution is encouraging the wrong type of behavior.

[Chris Beaven]

While I understand and accept the "wontfix", the right way and what will get implemented are two different things.
Perhaps the login form should be made to work only if HTTPS is being used :|

[inerte@…]

There are spy|malwares that once installed intercept whatever is submitted via forms and phone home. Hashing the information before doing it so avoids them.

HTTPS is a truly secure client-server solution but the 'net has other problems :)

[boxed@…]

Hashing at the client side will add nothing to the protection of the sites admin though, just wanted to point that out.

[Chris Beaven]

Well it will help the protection of a site's admin in the sense that there is less chance of an administrator's password being sniffed (unless a keylogger is being run).

My solution wasn't supposed to be just a work-around, as inerte@ pointed out. Extra security has always been a good thing in my books.

[anonymous]

Ah, sorry boxed@, from reading your comment over at #61 I get what you mean now.
You are correct, this patch does not affect changing a password field via the administation interface. That could also be extended to do an initial client-side hash, but based on this wontfix it would be a pointless exercise.

[Adrian Holovaty]

Milestone Version 0.92 deleted