Dawid, thank you for checking these other implementations. I agree it's somewhat surprising and clearly something the developers of the other password libraries decided to guard against.
One question I have is - did you experience any real world issue with this? Reading back over the thread, you haven't mentioned this. As Tom says, this is the first mention he can remember. We could add type guards to many of the thousands of functions in Django to prevent potential bugs. I'm sure some would. I'm sure many would just be "academic". And they come with both the implementation and maintenance costs, plus making duck-typing harder for users. To add one here, it would go through the normal deprecation process: https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy . This means PR's for 3.1, 3.2, and 4.0, changing the code, documentation, and release notes. I'd say at this point I'm convinced this *could* be a (slightly) useful change. But you have to be aware - I don't think you'll find anyone who's willing to do this work other than yourself. There are many more interesting changes to be made to Django if you check Trac! Thanks, Adam On Sat, 14 Mar 2020 at 14:53, Dawid Czeluśniak <czelusniakda...@gmail.com> wrote: > Tom, > > The behavior of the make_password method is quite surprising to be honest >> > > I'd go even further and say that currently the behaviour of the > make_password function is *wrong* and *unsafe*. Again, let's look at > hashing functions from other libraries. None of them fails silently and > casts object to bytes using __str__(). Werkzeug and passlib are the most > notable examples how to handle things correctly: > > > *1. Werkzeug* > In [1]: from werkzeug.security import generate_password_hash > > In [2]: generate_password_hash(dict()) > TypeError: Expected bytes > > > *2. Passlib* > In [1]: from passlib.hash import pbkdf2_sha256 > > In [2]: pbkdf2_sha256.hash(dict()) > TypeError: secret must be unicode or bytes, not dict > > > *3. Django* > In [1]: from django.contrib.auth.hashers import make_password > > In [2]: make_password(dict()) > Out[2]: > 'pbkdf2_sha256$180000$dimMkJ5wvrpn$eHh6CNAY+hTagaDmsofHMlJEbVOXEeIEfcT059Me2ho=' > (seriously???) > > This is especially *wrong* because programmers who are *not* aware of > this strange behaviour can accidentally do things that they *really *don't > want to do. I can imagine scenarios in which this can have some serious > unintended consequences. > > maybe the advantages of being able to pass any object into the method is >> entirely academic because nobody passes anything but strings on purpose > > > Exactly. I'd even say that there are *no* advantages of being able to > pass any object into this function and it can have bad consequences. > > Dawid > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAHzshFuQnEUrAdk53apDWw3wnPBNq%2BYQE9bxyfOpbFfyQS04dw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAHzshFuQnEUrAdk53apDWw3wnPBNq%2BYQE9bxyfOpbFfyQS04dw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0h8aD4-vutrZ3m2kZ_CuTXoY3sYN5N83Vr_9HtEWLuYw%40mail.gmail.com.
