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