id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
20593	"Disagreement between User.set_password("""") and User.check_password("""")"	Jonas Kölker	Tim Graham <timograham@…>	"At https://docs.djangoproject.com/en/1.4/topics/auth/, under `set_unusable_password`, it says ""Marks the user as having no password set. This isn’t the same as having a blank string for a password"", which suggests that the latter is possible.  Also, `set_password` doesn't say anything about blank passwords not being allowed.  Yet, when I run
{{{
    user.set_password(form.cleaned_data['new0'])
    assert user.check_password(form.cleaned_data['new1'])
}}}

with both new passwords being empty, I get an assertion failure.  According to at least two core developers*, allowing a blank password is not a bug---which would indicate that `set_password` does the wrong thing.

(*)
one: https://code.djangoproject.com/ticket/4170
two: https://code.djangoproject.com/ticket/14354 plus https://groups.google.com/forum/#!msg/django-developers/NtpFFdYh-3g/erB1Qhd6m2UJ

Looking at hashers.py, I see
{{{
def make_password(password, salt=None, hasher='default'):
    """"""[... If password is None or blank then UNUSABLE_PASSWORD will be returned ...]""""""
    if not password:
        return UNUSABLE_PASSWORD
}}}

That looks rather deliberate.  If that's so I think the documentation should be updated, reflecting the fact that `User.set_password("""")` does something rather anti-intuitive, and that there even more anti-intuitively exists a string `s` such that if you do `set_password(s)`, then `check_password(s)` fails.

Also, I think '''silently''' forbidding blank passwords is really bad.  If `set_password` were to throw a `ValueError` with an explanation of why you rather than I should decide whether to allow blank passwords, I would dislike it but at least its anti-intuitiveness would be '''explicit'''.

As things are at present, given the silent transition (or did I look in all the wrong places for the deprecation warnings?) users of Django applications could lock themselves out when they intend to have a blank password---the 180 degrees opposite effect of what they want.

-----

I've set version=1.4 on this ticket, because that's the one I use in my production environment, i.e. the one where I have exhibited this behavior.  Version 1.3 did something different, see https://github.com/django/django/blob/1.3/django/contrib/auth/models.py#L251

I've set easy=true, because I think the fix is a one-line patch and a four-line addition to/of a test case---which I'll be happy to write---or some documentation rewriting (which I'll leave to someone else).  I think the best next step is for the group of core devs to agree on what the right thing for `set_password("""")` to do is, then add that information to this ticket."	Bug	closed	contrib.auth	dev	Normal	fixed	blank password	bmispelon@… eromijn@… Jonas Kölker	Accepted	1	0	0	0	1	0