[Python-Dev] Deprecate crypt module and revert PR 3854

[Christian Heimes]

On 2018-02-02 18:05, Serhiy Storchaka wrote:
> 02.02.18 18:18, Guido van Rossum пише:
>> I'm all for nudging people in the direction of xcrypt. I assume we
>> can't just switch the C-level crypt with xcrypt and leave the Python
>> API unchanged?
>>
>> However until a usable solution exist (either in the stdlib or as 3rd
>> party) I don't think we should deprecate anything (deprecating things
>> before the replacement is ready is stressful for everyone involved).
>>
>> I'm also not sure I agree with removing support for old hashes. By all
>> means put in the docs that they are unsafe. But if someone has a
>> database full of old hashes it would be nice to be able to at least
>> read/verify it, right?
>>
>> Was a release already made with blowfish, extended DES and NT-Hash?
>> (And what's so bad with blowfish? It's mentioned in the heading of the
>> xcrypt project too.)
> 
> To clarify, extended DES and NT-Hash were not added. They were removed
> from my PR after Christians request. Only the Blowfish method was added,
> and it is so strong as SHA-2 methods. It is the only method supported on
> OpenBSD.

Ah, I misinterpreted the subject of the PR. The closed PR still mentions
extended DES and NT-Hash. I'm sorry and blame my travel fatigue. The
email was written at the airport after I had a conversion with somebody
about new Python 3.7 features.

> This PR is not a single enhancement made in the crypt module recently. I
> also extended tests and added support for configuring SHA-2 methods.
> There is an open PR (not merged before 3.7b1 unfortunately) for using
> crypt_r() instead of crypt(): https://bugs.python.org/issue28503.

In general I'm all for more tests and improvements of existing modules.
However in this case Python 3.7 is sending wrong signals. For example
additional of blowfish was prominently features on the largest German
newsletter for IT. Both blowfish and SSHA (salted sha) are legacy
password hashing algorithms. Glibc has moved them out of the main
library for a good reason. (*)

> If deprecate the crypt module, should modules pwd, grp and spwd be
> deprecated too? The crypt module is needed for checking password hashes
> provided by spwd.

The pwd and grp module are fine. The modules use proper libc APIs that
are internally backed by NSS (libc's Name Service Switch, not Mozilla's
Network Security Service). APIs such getpwnam are defined and
standardized since POSIX.1-2001. The pwd and grp automatically work with
any configured user and group provider, even LDAP, IdM or Active Directory.

Fun fact: Golang programs are usually statically compiled and don't even
use libc. However Go's os/user package requires CGO and libc because it
has to interface with libc and NSS to acquire user and group information.

The spwd module is a different story. It's a direct interface to
/etc/shadown using Linux-only APIs. The shadow DB API requires root
permission. I think it even circumvents system security policies and
identity provider.

tl;dr
pwd + grp == good, required
crypt + spwd == bad

Regards,
Christian

(*) Most Linux distros never had blowfish in libc anyway.