[patch] auth.User admin form shouldn't require people to edit hashes

Here's a decent-looking JS MD5 implementation to use in whatever widget you create.

http://pajhome.org.uk/crypt/md5/

I don't think JavaScript? is right for this. I think simply a password field, and a password-confirm field should be added in the form when creating a new user, just like everyone else does. Then, when modifying an existing user, the form should have a click-to-reveal form and (depending on whether the user has the necessary permissions) show either 3 fields - current, new, and new-confirm - or 2 - new, and new-confirm -, for privileged users. Also, implementation of other algorithms would depend on the existance of JS implementations of them (see ticket #273).

I've tried a couple times to ask about this, and mostly failed because I never was really able to express it clearly, but here goes:

Is there a reason why this would need to be implemented in JavaScript? at all? It seems that the easiest thing to do would be to have the input work much as the set_password method of the User class does now: instead of expecting a hash, expect the raw password, and hash before storing it (e.g., with _pre_save).

This strikes me as having at least two advantages:

1. It makes password behavior more consistent. Currently, adding a user or changing a user's password behaves differently in different cases:

1. If the user is being added/modified by the AddManipulator? or ChangeManipulator? for the User class, the password is expected to be a hash.
2. If the user's password is being modified by set_password, it's expected to be the raw password.
3. If the user is being created by 'django-admin.py createsuperuser', the password is expected to be the raw password.

2. We don't have to deal with JavaScript? inconsistencies, or worry about what happens if JavaScript? isn't available.

Of course, this would be a backwards-incompatible change and thus really ought to be targeted at 1.0, but I think that the usability benefit of doing away with the need to input a hash would justify this... :)

Hashing before sending offers protection against cleartext password sniffing when the connection is not encrypted (through SSL, typically). I believe LiveJournal is among the sites that use this technique.

FWIW, I used MD5 implemented in JavaScript in one of my projects. There are several implementations available including one in Dojo (be warned: it was broken in svn some time ago). It is purely computational thing, so it is not affected by browser differences. Of course, no JavaScript? is a problem.

Actually the stored encrypted password changed the format recently, so it's no longer plain MD5 but a salted SHA1 digest in standard salt+algorithm+hash format. So if you want to do stuff in JavaScript?, you will have to look for code to do that instead of MD5. MD5 is dead. It's already starting to smell funny ;)

Why don't we just do this by:

* Marking password as non-editable so that it is not in the default admin screens. * Make a seperate "password changing" view that uses the follow argument or a custom manipulator to change the password. Stick this in the urlconf. * Make an admin/auth/users/change_form.html template that puts a link to the change password view by overriding an appropriate block. eg form-top.

The change password view could act - shock - like a normal password changing form, and then the javascript thing could be added later.

There is SHA1 (and some other crypto-related algorithms) in Dojo as well. I don't think that finding an implemented algorithm is a problem. The question is "are we willing to walk JavaScript way for the most basic tasks?". Granted, sending a digest instead of clear text password is much more secure.

Maybe we should think about providing two alternatives: with JavaScript, and without. It will suppress critics, while providing more secure way to create passwords. I think I know which one is going to be used in 99% of real life cases. :-)

rjw's solution is practical but it shifts the burden on developers. While it is flexible enough, it requires repetitive reimplementation of simple things. I think we need to provide ready-to-use implementations.

Eugene: eh?

I am suggesting that we have this built in to the admin. How does that make things repetitive etc?

I am sorry. It looks like I misunderstood you.

my thinking was that the 'password' field could handle the encrypting/decrypting internal to the formfield itself.

in order to do this it would need to override convert_post_data and 'render'

class PasswordField(TextField):
    input_type = "password"
    
    def convert_post_data(self, new_data):
        name = self.get_member_name()
        if new_data.has_key(self.field_name):
            d = new_data[self.field_name]
            .. do crypt magic here..
            new_data[self.field_name] = d
 def render(self, data):
       output [  "<.. input password field here..>"]

as for transmitting passwords over HTTP, use HTTPS. don't reinvent the wheel.

FWIW, one alternative would be to use Ajax to go back to the server for the encryption implementation, rather than doing it in-browser. I much prefer a server-side implementation for reasons of simplicity and consistency though.

Regardless of implementation, I think the usability needs to be right first and foremost. People expect to just bash in "afternoon", "afternoon's password", "afternoon@mydomain" and hit return without thinking about it too much, as they do everywhere else. Django has to go out of it's way to support that.

Also, I think this is really a 1.0 thing. It's really not very 1.0 if you have to drop to the command line to create new users.

Isn't it the same as sending password in clear text to the server?

Eugene, isn't what the same as sending the password in clear text?

I'm assuming you mean just typing the password in as Afternoon mentioned.

As far as I see this:

Let's assume you force people to enter new users' passwords in hashes so that it's not sent as clear text. now your user is created, and wants to log in. You have two options here, either force them to also enter the hash, or get them to type the actual password in, then se4ver side hash that and compare it.

If you choose the former, though, your password hash has merely replaced the password, and can be intercepted and typed directly in. If you choose the latter, then someone who really wants that login can just wait until the user logs in, and grab the password in transmission then. So either way, it seems that you're giving a malicious third party the information they need to log in as that user. I don't really see how forcing someone to enter in a hash is helping here.

So getting someone to enter a password hash feels unnatural, since people are used to just typing the password in, and doesn't give you any added security or other benefit whatsoever. In this case, aren't you better off optimising for usability, and doing what the user is used to and expects?

If security is really important for the site, then SSL should be used.

One issue with SSL is that there's no virtual hosting possible; each SSL host must have its own IP address. This is potentially cumbersome for many Django installations. Furthermore, SSL is problematic in that it inteferes with good URL design; you are no longer free to run your admin site from anything other than an entirely separate protocol/domain.

Forcing users to create a hash "by hand" violates usability principles.

django@illuminosity, the dilemma you highlight can be resolved through the use of a nonce; the server sends, along with the password request, a variable (the nonce) which should be concatenated with the hashed password by the client before rehashing (in Javascript). The server, in turn, performs the same hashing and compares the values. The nonce can be based partially on the current time, as to be pseudo-random in nature. Any value intercepted is useless for future attacks, as the nonce (and thus the transmitted secret) changes each time.

django@illuminosity.net: I wanted to confirm that I understood afternoon@uk2.net correctly. Maybe he meant something different.

Clearly secure environments should use SSL. But Tom highlighted the problem: the Real Life (tm) is not perfect. By requiring SSL for Admin we will cut off a lot of enthusiasts --- majority of hosting companies will be happy to sell you "e-commerce solution" with separate IP address and SSL certificate for cool "e-commerce" price. :-(

Sending password in clear text has a lot of security implications even for humble personal web sites.

Decisions, decisions...

tobin: your nonce+JS-hashing works for login situations - but what this is about is the admin password-setting situation. You can't encrypt the password to be set with some one-way algorithm, because the user won't be able to get the same nonce to produce the same result when entering his password :-)

Actually the switch in Django to salted hashes is the right way to go. The only problem left is how the admin is supposed to set the password. We have two options:

• the admin has to enter the password twice, it is compared and if it is given and twice the same, the password of the user is set. This sends the password over in clear
• the admin has to enter the salted hash, but some JavaScript? is used to encrypt it on the fly. This makes JS a requirement for password setting

Both situations above will pose limits - but the JS-for-Admin requirement is the hardest, as it will remove the ability to use lynx or other non-JS capable browsers (or to disable JS and still use the admin). I don't think I would like that - there should allways be a sane non-JS solution.

Same with the login process, only that's an even stronger objection in my book: we can't build a login solution that absolutely requires JavaScript? from users. This could be offered as an alternative to users, but it can never be the sole login solution.

The right answer for security issues with the Django admin or the login process would never be wild hacks with JS - it should allways be SSL. Even if that poses problems to some people with regard to what their hosting provides. An administrator can easily change providers to one who gives him a dedicated IP for SSL usage, while a blind user can't get a pair of eyes to use some JS-capable browser ...

Hi, I am jumping in the discussion late, but here are my views:

There are basically two scenarios: (S) server compromised [someone gets read access to server database] vs (N) someone able to intercept client server communication. This analysis is to prevent just these two kinds of attacks.

There are hash databases so getting hash of password is enough to reveal password for common passwords, so salt based hashing is must whenever we are thinking of hashing.

So here are the options we have:

1. sotring password in clear on server, and sending it clear from client is the worst option. Assessment: -S -N
2. storing hash of password on server adn sending hash of password using javascript is indistinguishable from the above, hash of the password becomes the hash. Assessment: -S -N
3. storing salted hash on server, and sending password in clear from client protects us when server is compromised. Assessment: +S -N.
4. Store salted hash on server. Send random string from server to client. Send (salted?) hash of random_string+salted hash of password to the server from client for auth. Assessment: -S +N.

We can not have a +S +N solution so we have to chose from 3 and 4. Choice 3 would be preferred if SSL is possible for your setup, where as 4 is preferred when its not, as its much easier to sniff passwords than to hack server.

Since its a matter of tradeoff, I think we should make support both in django, with this discussion in the documentation, a setting option, and let the developers decide what we want. With default to 4.

Note: 1., 2. are -S, but if compromise happens from 1., clear passowrds can be revealed, and given users tend to use same passowrd on more than one server 1. is worse than 2. Also there is one thing to get your account compromised on some server and another to see your password posted on the net, from PR point of view. For this reason 4. suggests to store salted hash on server.

Correction in my comment above:

For option 4., the random string I talk about is associated with user on the server. Client request server for random string by telling server about the username. Server may also put timeout on random strings for further security, and obviously it must delete the randomstring after it encounters the second request.

After further thinking, this makes the authentication two step, which may not be a problem thanks to "ajax", but if javascript is disabled, it falls on its face completely [unless ofcourse if we expect the lynx user to take the random string, create salted hash of password, concat the two and calculate the hash again, and enter that to some form].

This brings in a situation when javascript is essential for security. Interesting.

If we still want to allow non javascript users to log in, we can allow them to send the password in clear, and we can do hashing on server and match to authenticate. This is unsafe but affects only the users who has javascript off, rest can enjoy more secure option.

Ok, even though I am not a fan of the JS-idea for login, this would be a way how you could do it:

• when loading the login form, a onload javascript deactivates the login button
• the onblur event on the username field will fetch the salt for the given user via XmlHttpRequest? and store it somewhere in the current page. The salt is the part in the middle of the stored password between the $ chars.
• the callback for the salt-fetching XHR will enable the login button (because only now we can login securely)
• the onclick handler of the login button uses SHA1 to calculate the correct hash and then concatenates 'sha1', the salt and the hash delimited by '$' and puts that into the password field. Then it submits the form.
• the form handler checks the password for the sha1$<salt>$<hash> syntax and if it receives that, doesn't do it's own hash calculation but just uses the provided value and does a direct compare.

This approach would still enable JS-less login, as in those cases the login button and the XHR handling doesn't happen and the user still sends username+password in the clear.

Problem: this will only work with passwords that use the new salted hash algorithm. Passwords that still are MD5 hashes won't work, as there is no salt to send out. The algorithm above should maybe handle that in that it just reenables the login button and removes the onclick handler there, so that usernames that only have MD5 hashed passwords get the standard cleartext login, just as if they didn't have JS active.

There should be a visual feedback wether cleartext or hashed login is active, so that users know what happens.

A good page on JavaScript? and SHA1 (and MD5 and MD4 - but those two are dead and should stay dead ;) ) is at http://pajhome.org.uk/crypt/md5/instructions.html

I have set up a test page that uses MochiKit and the SHA1 library to provide a login form that produces the salted hashes so you can see how that might work (I didn't hook up any XHR stuff to the backend, of course - it's just calculating the salted hash like it's done in Django).

My test page is at http://media.rfc1437.de/testsha1.html

Please keep in mind that if you don't have JS active, it will send your password in the clear, as it's just a form with submit button. Please don't try the form with real passwords ;-)

Hugo, the problem with your method is that the password never gets used in the JS-enabled login, just the hash (from the server's point of view). What the process you described is actually doing is logging in in cleartext, using the hash as a password. It is trivial to fake a login with a packet sniffer and Curl, by just grabbing the algo$salt$hash string, resending it to the server and grabbing the cookie, because you never need the actual password. I don't think there's a simple method that does anything like this and allows you to keep only the password hash in the DB. Or at least I don't seem to be able to wrap my head around such a process o_O

Actually that's not the real problem, but we still have one - the salt from the server won't change, so a sniffed answer can be reused. As soon as a challenge-response method doesn't change the challenge, it degrades to clear-text password. And to have a new salt, we need the unencrypted password on the server.

This could be solved by sending out _two_ salts - the one from the stored password and a real random one. The client will have to do two rounds of hashing - one to produce the same hashed password that's on the server and another one using that hashed password with the random salt. This double-hashed password is sent over the wire and recalculated there, but on the server only one round is needed (as the password is already hashed).

This would give us a random salt for the transmission, while still allowing to keep the hashed passwords in the database. The first (non-random) salt still will only change on password-change - and the one-round hashed password (or the cleartext password) needs to be sent over the wire for changing. And I am quite sure that we don't have a chance to solve that problem without some kind of real encryption. Is there a Blowfish implementation for JavaScript?? ;-)

Oh, and of course you need to make login stateful - challenge-response only works in stateful environments, in stateless environments you are prone to fall for replay-attacks. You need to know what random salt you sent out and only accept that from the client back - often it's good enough to kee sent-out salts in a database and delete them on successful login or on login-timeout. This leaves you to some flooding problems (clients requesting new login forms and so new random salts, enlarging your list of open logins in the database), but that's a basic problem of every HTTP solution (not only the login process), it's cheap for clients to make requests, but expensive for the server to fullfill them.

Obviously there are Blowfish implementations written in js. Example: http://aam.ugpl.de/node/1060. I know for a fact that Dojo adds one soon (not in SVN at this moment).

Hugo, the problem I described persists. Your new version is the equivalent of storing hased passwords and sending them in cleartext (whereas the old version was both sending them and storing them in cleartext): you only need the first hash (which is stored in the database) to login.

If anyone doesn't get my idea, just imagine that the password is not the real password, but the string "algo$salt$hash" which we generate. In the 1st version, it is stored in the database in cleartext. In order to login, you have to send this exact string over the wire. You can just a) packet sniff or b) get access to the DB, where you can read the string, in order to forge a login. In the 2nd version, with the same method of thought, you are using challenge response with the requisite it has: that the password is stored in cleartext (remember, our password is the "algo$salt$hash" string). If you can access the database, you can read this string directly, and then hash it only once (with the challenge salt provided by the server) to login to the site.

So these methods really leave us exactly where we were from a security standpoint, but with an additional layer of complexity, and the small benefit that the actual "normal" password is never known by an attacker or the system (so a person can still use the same password on other sites). But from our point of view, remember that you never need this password to login to the site, just the "algo$salt$hash" string. And this is the real flaw with the methods you propose, hugo.

Actually any password based algorithms have this problem that you either need to transfer them in clear or need to store them in clear. The above scenario just leaves the choice which risk to take - using the JS version, it's the stored-on-server risk, using the non-JS version, it's the sent-in-clear risk. To get around both, you would need stuff like client certificates. Only asynchronous encryption allows to completely get rid of the password on both sides.

Oh, and none of that will solve the named problem of changing the password - we shouldn't forget the topic of this ticket ;-)

In the end - and that was my point in the IRC discussion, as you might remember ;-) - it's better to just use SSL. Some things should just be left to those tools that know how to do it.

http://evolt.org/node/60505 discusses one possible solution using AJAX and salted hash.

While the above solution is secure for logging in existing users, it doesn't solve the problem of password creation nor password change. Nevertheless it is useful by itself --- usually logging in is more frequent operation.

Hi all..

I added the following code to the User class:

def _pre_save(self):
    import re
    if not re.match(r"(^[a-z0-9]+\$[a-z0-9]+\$[a-z0-9]+$)", self.password):
        self.set_password(self.password

since the password is stored in format algo$salt$checksum, the regexp checks that is it in the given format... but this solution doesn't solve the case, when the password is changed to one which contains three (or more) $ -signs...

and ofcourse there is a closing parenthesis missing in the code -block, so it should be like:

def _pre_save(self):
    import re
    if not re.match(r"(^[a-z0-9]+\$[a-z0-9]+\$[a-z0-9]+$)", self.password):
        self.set_password(self.password)

While striving to be superior, Django has ended up being miserable for an extended period (wrt changing passwords). Why not simply match the "competing" projects, point out security concerns clearly, and provide nice hooks for users who want to use SSL, JS, quantum computers or what not.

From what I can tell reading at http://code.djangoproject.com/ticket/273 it seems it would be fairly trivial to add support for a new type of "hash" which actually is clear text. So one could, in the admin, write: raw$password and it would be automatically upgraded to sha1 when the user logs in.

Check out the patch at #1534 for client-side encrypted logins.

People, please. You're discussing two different things.

The correct and obvious solution for this ticket is to do what everyone else does: display two PasswordFields?'s, "password" and "confirm", and transmit the password in plaintext. Conversion to a hash should be done in the manipulator. This is consistent with Django's existing "change password" form.

If you want to create a spiffy new login system that doesn't ever transfer cleartext passwords, then maybe you should open another ticket, or even a subproject. There's a lot that needs to be affected by such a project, not only the admin interface for users which is what this ticket is about, but also the "change password" form and the login itself. If anyone wants to pursue this, please don't reinvent the wheel, and use a simple challenge system. Myself, I don't think I care enough. I just want the content department manager to be able to create users without having to ask me for help.

I'll be working on a patch on the next few days...

A Firefox Greasemonkey user script which does client-side SHA-1 generating is available in the Django Cookbook. No changes needed in Django and it works instantly on all Django sites.

I agree with lalo.martins. We shouldn't be discussing fancy js-based hash generation techniques. It's useless if the login itself is done in plain text! Let's to things the easiest way. For now, if developers want to make their website secure, they use HTTPS. Let's just make the password field use type="password" form fields and override User's save method to set the hash there. I'll attach my proposed patch tomorrow.

#2329 was a duplicate.

Reverted properties.

Reverted spam.

Oops, spaces instead of tabs in documentation this time :(

I got sick of waiting so here you go: finally, a complete working PasswordField? patch!

Ticket #2071 also contains documentation of the existing password form field if we decide to split out the presentation and functionality parts of this patch.

All db.backends creation data types updated to work with PasswordField?

(In [3520]) Fixed #61 -- No more editing hashes when creating users via the admin. Created a special-case 'Add user' admin view. The change form still displays the hash, for the moment.

The latest changeset seems to have something strange error:

Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py" in get_response

74. response = callback(request, *callback_args, **callback_kwargs)

File "/usr/local/lib/python2.4/site-packages/django/contrib/admin/views/auth.py" in user_add_stage

39. }, context_instance=template.RequestContext?(request))

File "/usr/local/lib/python2.4/site-packages/django/shortcuts/init.py" in render_to_response

1. return HttpResponse(loader.render_to_string(*args, **kwargs))

File "/usr/local/lib/python2.4/site-packages/django/template/loader.py" in render_to_string

99. t = get_template(template_name)

File "/usr/local/lib/python2.4/site-packages/django/template/loader.py" in get_template

79. return get_template_from_string(*find_template_source(template_name))

File "/usr/local/lib/python2.4/site-packages/django/template/loader.py" in find_template_source

72. raise TemplateDoesNotExist?, name

TemplateDoesNotExist? at /admin/auth/user/add/ admin/auth/user/add_form.html

That template's definitally there (http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/auth/user/add_form.html?rev=3520); you probably need to update the rest of your tree.

this fix the template packing for admin/auth/user/*.html

yes, the template is there, but it won't be packed by setup.py

(In [3524]) Fixed #61 -- Added admin/auth/user/*.html to setup.py

i'm trying to use the proposed patches but it wont work for me with show_raw=False. the error message is:

Django version 0.96-pre, using settings 'mytest.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Validating models...
userauth.authenticateduser: "passwd": CharFields require a "maxlength" attribute.
1 error found.

if I change show_raw to True, then the error message will disappear but it will produce a javascript validation error. I havent tried with encrypt_func yet.

If you're on current SVN, or any rev later than 3524, you shouldn't have to do any patching; a special-case "create user" view was added which doesn't require you to enter a hash.

Sorry i forgot to tell that this is not related to adding a user for the django.contrib.auth.User model. The problem still happens with custom models (models.Model) defined like so:

class GenericUser(models.Model):
      ...
      passwd = models.PasswordField(_('password'), show_raw=False, maxlength=128, blank=False)
      ...

The result is two password fields but then when I try to save them it says that some (passwd) fields are still missing ?? whats wrong ?

erob@cpan.org: The PasswordField patch in this ticket is not supported and probably won't be added to Django. The *real* issue of this ticket (improving the auth.User admin form not to use hashes) has been fixed.

Curious as to why this was marked as fixed because when you edit a user you still have to enter encrypted text. Nice job on the add user fix but it needs to be taken a step further and support editing users without having to enter encrypted text.

Agreed, the fix is incomplete, I was really surprised when I realized I still had to enter the encrypted text when changing a user's password. Why not have a "change password" button available for all users when the logged user is an admin?

This ticket has gone through the wars, maybe a new more specific one should be opened. :)

Superceded by #3166.

Milestone Version 1.0 deleted