[Python-Dev] PEP 594: update 1
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:
> 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:
> 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.