[Python-Dev] PEP 594: update 1
On Tue, 21 May 2019 at 23:26, Christian Heimes <christian at python.org> wrote:
> On 21/05/2019 18.08, Giampaolo Rodola' wrote:
> > On Tue, 21 May 2019 at 21:13, Christian Heimes <christian at python.org
> <mailto:christian at python.org>> wrote:
> > crypt
> > ~~~~~
> > The `crypt <https://docs.python.org/3/library/crypt.html>`_ module
> > 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
> > an alternative implementation any way.
> > * Only DES encryption is guarenteed to be available. DES has an
> > limited key space of 2**56.
> > * MD5, salted SHA256, salted SHA512, and Blowfish are optional
> > SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the
> > 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
> > databases.
> > This is actually not true. Their main use case is to compare passwords
> against the shadowed password db:
> > 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...