Django

Code

Ticket #1534 (closed: wontfix)

Opened 3 years ago

Last modified 2 years ago

[patch] Client-side encoding of admin logins

Reported by: SmileyChris Assigned to: adrian
Milestone: Component: django.contrib.admin
Version: 0.91 Keywords:
Cc: Triage Stage: Unreviewed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

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.

Attachments

secure_login.diff (13.9 kB) - added by SmileyChris on 03/24/06 01:26:16.

Change History

03/24/06 01:26:16 changed by SmileyChris

  • attachment secure_login.diff added.

03/24/06 03:26:24 changed by jim-django@dsdd.org

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.

03/24/06 07:52:42 changed by jacob

  • status changed from new to closed.
  • resolution set to wontfix.

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.

03/24/06 16:27:14 changed by SmileyChris

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 :|

03/24/06 21:40:31 changed by inerte@gmail.com

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 :)

04/02/06 05:48:05 changed by boxed@killingar.net

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

04/04/06 02:37:19 changed by SmileyChris

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.

04/04/06 02:43:07 changed by 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.

10/24/06 15:17:23 changed by adrian

  • milestone deleted.

Milestone Version 0.92 deleted

Add/Change #1534 ([patch] Client-side encoding of admin logins)




Change Properties
Action