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

[Christian Heimes]

On 2018-02-02 21:31, Antoine Pitrou wrote:
> On Fri, 2 Feb 2018 16:23:20 +0100
> Christian Heimes <christian at python.org> wrote:
>> Hi,
>>
>> in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to
>> Python's crypt mdodule. I vetoed against addition of the APIs because
>> all these hashing algorithms are not state of the art. Their quality
>> ranges from old to horribly, horriblye broken beyond any repair.
>>
>> Shortly after the PR has landed, I was made aware that glibc has
>> deprecated crypt(3) API [2] and favor of an external library called
>> libxcrypt [3] from OpenWall Linux. I have patched Python 3.7 [4] to
>> support libxcrypt.
>>
>> In light of deprecation of crypt(3) glibc function and bad quality of
>> hashing algorithms, I'd like to raise the motion to revert 3854 and
>> deprecate the crypt module.
> 
> Those are two separate proposals.
> 
> On the topic of reverting PR #3854, I don't see the point.  Is Blowfish
> more fragile than the other algorithms?  If not, it sounds ok to add it.

Blowfish password hashing algorithms (also known as bcrypt) hasn't been
state of the art of a long time. Here is an old blog post from 2012 that
explains some of the issues with Blowfish:

http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

> On the topic of deprecating the crypt module, that doesn't sound like a
> good idea right now.  People may need to generate crypt()-compatible
> output for various reasons, such as being able to automate system
> administration tasks.

IMO legacy support is not a good argument to keep the crypt module. The
passlib [1] package provides an excellent selection of legacy and modern
password derivation and hashing algorithms. As an admin you cannot rely
on the crypt module. libc's crypt() function usually provides a subset.
For example most Linux libc do not provide blowfish based hashing.

Christian

[1] https://pythonhosted.org/passlib/