Code

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#1534 closed enhancement (wontfix)

[patch] Client-side encoding of admin logins

Reported by: SmileyChris Owned by: adrian
Component: contrib.admin Version: 0.91
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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 (1)

secure_login.diff (13.9 KB) - added by SmileyChris 8 years ago.

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by SmileyChris

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:3 Changed 8 years ago 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 :|

comment:4 Changed 8 years ago by 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 :)

comment:5 Changed 8 years ago by boxed@…

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

comment:6 Changed 8 years ago 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.

comment:7 Changed 8 years ago 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.

comment:8 Changed 7 years ago by adrian

  • milestone Version 0.92 deleted

Milestone Version 0.92 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.