F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_fo...

== Summary ==
Make the yescrypt hashing method the default method used for new user
passwords stored in <code>/etc/shadow</code>.

== Owner ==
* Name: [[User:besser82| Björn Esser]]
* Email: [e-mail]

== Detailed Description ==
yescrypt is a password-based key derivation function (KDF) and
password hashing scheme.  It builds upon Colin Percival's scrypt, and
is based on NIST-approved primitives.

Cryptographic security of yescrypt (collision resistance, preimage and
second preimage resistance) is based on that
of SHA-256, HMAC, and PBKDF2.  Even a catastrophic failure of
yescrypt’s computational layers to maintain entropy would not affect
yescrypt’s cryptographic properties as long as SHA-256, HMAC, and
PBKDF2 remain unbroken.  That said, in case SHA-256 is ever broken,
yescrypt’s additional processing is likely to neutralize the effect of
any such break.

By the time of this writing, sha256crypt and sha512crypt, as used
commonly today for hashing passwords, remain unbroken, but have some
flaws by design:

* Both hashing methods effectively only use about 90 bits of salt,
although the NIST-recommendation for salt length is >= 128 bits.
* Long passwords can create a denial-of-service on the CPU.
* Passive observation of execution times can predict password length.
* No use of a crytographic key derivation function (KDF).

In conclusion we should move to a stronger hashing method for
computing the entries in the UNIX shadow file.  So why not Argon2?

* yescrypt has a dependency not only on RAM, but also on fast on-die
local memory, which provides bcrypt-like anti-GPU properties even at
very low per-hash RAM sizes (where Argon2 might even lose to bcrypt in
terms of GPU attack speed).
* yescrypt currently has less low-level parallelism within processing
of a block, yet allows for tuning it later, whereas Argon2 has a fixed
and currently commonly excessive amount of such parallelism, which may
be extracted to speed up e.g. GPU attacks through use of more
computing resources per the same total memory size due to each hash
computation's memory needs being split between 32 threads (yescrypt
currently has four 16-byte lanes that can be processed in parallel
within a 64-byte sub-block before running into a likely data
dependency for the next sub-block, whereas Argon2 allows for parallel
processing of eight 128-byte chunks within a 1 KiB block with only two
synchronization points for the entire block, as well as of four
32-byte parts of the 128-byte chunks with only two more
synchronization points for the entire 1 KiB block).
* yescrypt's cryptographic security is provided by SHA-256, HMAC, and
PBKDF2, which are NIST-approved and time-tested (the rest of
yescrypt's processing, while most crucial for its offline attack
resistance properties, provably does not affect its basic
cryptographic hash properties), whereas Argon2 relies on the newer
BLAKE2 (either choice is just fine for security, but use of approved
algorithms may sometimes be required for compliance)

Also see [https://www.openwall.com/yescrypt/ yescrypt - scalable KDF
and password hashing scheme], the
[https://www.password-hashing.net/submissions/specs/yescrypt-v2.pdf
PHC submission paper],
[https://lists.openwall.net/phc-discussions/2018/03/13/10 PHC yescrypt
vs. Argon2], and
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978553 the
discussion on the Debian bugtracker].

== Feedback ==
No feedback, yet.

== Benefit to Fedora ==
yescrypt is the default password hashing scheme on recent ALT Linux,
Debian testing, and Kali Linux 2021.1+, so we should adopt it as the
default, too.  Also, it is already the recommended hashing method in
the [https://docs.fedoraproject.org/en-US/fedora-coreos/authentication/#_using_pa...
Fedora CoreOS documentation].

== Scope ==
* Proposal owners: Help with integration for yescrypt support in some
packages.  See Dependencies.
* Other developers: Integrate yescrypt support in some packages.  See
Dependencies.
* Release engineering: [https://pagure.io/releng/issue/10150 #10150]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
No impact, as password hashes, that have been computed using the
former default sha512crypt, will continue to work.

== How To Test ==
* Existing installations: Change your user password and check whether
the computed password hash in <code>/etc/shadow</code> starts with
<code>$y$</code>, like <code>root:$y$j9T$JEFtZ/…</code>.
* Fresh installations: Check whether the password hash(es) for the
user(s) created by anaconda in <code>/etc/shadow</code> start(s) with
<code>$y$</code>, like <code>root:$y$j9T$JEFtZ/…</code>.

== User Experience ==
No user visible changes, but they can rely on safer hashing for their
user passwords.

== Dependencies ==
* anaconda: https://github.com/rhinstaller/anaconda/pull/3431
* authselect: https://github.com/authselect/authselect/pull/253
* libuser: WIP ongoing
* shadow-utils: https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10

* pam: Is already capable to use yescrypt.
* libxcrypt: Is already capable for computing yescrypt hashes.

== Contingency Plan ==
* Blocks release? Yes

Partially revert the changes, that have been applied to anaconda,
authselect and shadow-utils, and rebuild those packages.

== Documentation ==
Fedora now uses the yescrypt hashing method for new passwords.  There
are no visible changes nor impacts to the end-user.  Users are
recommended to change their existing passwords after upgrading.

== Release Notes ==
Fedora now uses the yescrypt hashing method for new passwords.  There
are no visible changes nor impacts to the end-user.  Users are
recommended to change their existing passwords after upgrading.