On Tue, 21 May 2019 at 23:26, Christian Heimes <christ...@python.org> wrote:
> On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > > > > On Tue, 21 May 2019 at 21:13, Christian Heimes <christ...@python.org > <mailto:christ...@python.org>> wrote: > > > > crypt > > ~~~~~ > > > > The `crypt <https://docs.python.org/3/library/crypt.html>`_ module > implements > > password hashing based on ``crypt(3)`` function from ``libcrypt`` or > > ``libxcrypt`` on Unix-like platform. The algorithms are mostly old, > of poor > > quality and insecure. Users are discouraged to use them. > > > > * The module is not available on Windows. Cross-platform application > need > > an alternative implementation any way. > > * Only DES encryption is guarenteed to be available. DES has an > extremely > > limited key space of 2**56. > > * MD5, salted SHA256, salted SHA512, and Blowfish are optional > extension. > > SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the > only > > algorithm that is still secure. However it's in glibc and > therefore not > > commonly available on Linux. > > * Depending on the platform, the ``crypt`` module is not thread > safe. Only > > implementations with ``crypt_r(3)`` are thread safe. > > * The module was never useful to interact with system user and > password > > databases. > > > > > > This is actually not true. Their main use case is to compare passwords > against the shadowed password db: > > > https://github.com/giampaolo/pyftpdlib/blob/ee7b36c701b78b2d36e938c42d08dbfbad55a34f/pyftpdlib/authorizers.py#L413 > > A quick search on searchcode.com <http://searchcode.com> shows both > spwd and crypt modules are used. I am no security expert (and I wasn’t > aware they are insecure until now, since the doc doesn’t mention it) but I > would prefer seeing these 2 fixed or improved rather than bluntly removed. > > No, the statement is correct. I may have to explain this even further. > > The approach in pyftpdlib is the wrong and IMO deserves a CVE. The crypt() > + spwd() approach is flawed on multiple levels. For example it bypasses > account restriction, access control, and login session. It also requires > you to run the service as root and with SELinux disabled or an unconfined > context -- a bad combination. There is only one correct way to perform a > credential check: use PAM. > > spwd can't be fixed. It could only be replaced with a completely different > API that wraps PAM and Windows's authentication API. > > Christian > > PS: Authentication, authorization, and identity management are part of my > day job at Red Hat. > Got it. I had no idea. Since you mentioned the CVE it looks like spwd/crypt doc deserve a warning. This is probably out of the scope of the PEP, but I wonder if the 3 third-party alternatives mentioned in the PEP are mature enough and could be evaluated for stdlib inclusion (the part re. PAM / password-checking at least). Perhaps spwd/crypt could be deprecated in 3.8 and the alternative added in 3.9 before the 3.10 removal. -- Giampaolo - http://grodola.blogspot.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com