From Fedora Project Wiki
(Be a bit more verbose about changes needed in dependencies.)
(Update status of guestfs-tools.)
 
(29 intermediate revisions by 2 users not shown)
Line 12: Line 12:


== Current status ==
== Current status ==
[[Category:ChangeAnnounced]]
[[Category:ChangeAcceptedF35]]
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]


* Targeted release: [[Releases/35 | Fedora Linux 35 ]]  
* Targeted release: [[Releases/35 | Fedora Linux 35 ]]  
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2623 #2623]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1975402 #1975402]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/706 #706]
 


== Detailed Description ==
== Detailed Description ==
Line 45: Line 44:


== Feedback ==
== Feedback ==
No feedback, yet.
Feedback so far:
 
* 2 times: +1 from users on the Fedora-devel-list.
* Some people see possible problems, if one copies the shadow-file between different distributions and/or systems, and/or uses some distributed user/pw management service like LDAP.
* It is agreed upon, we shouldn't force users to change their login password; rehashing the current password silently is no problem for them, though.




Line 66: Line 69:


== How To Test ==
== 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>.
* Existing installations: Change your user password (on cli or with your preferred GUI-based tool / control center of your desktop environment) and check whether the computed password hash for your user 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>.
* Fresh installations: Check whether the password hash(es) for the user(s) created by anaconda or gnome-initial-setup in <code>/etc/shadow</code> start(s) with <code>$y$</code>, like <code>root:$y$j9T$JEFtZ/…</code>.
 


== User Experience ==
== User Experience ==
Line 74: Line 78:


== Dependencies ==
== Dependencies ==
* anaconda: upstream: https://github.com/rhinstaller/anaconda/pull/3431
* authselect: upstream: https://github.com/authselect/authselect/pull/253, downstream [https://koji.fedoraproject.org/koji/buildinfo?buildID=1774682 patch is in Rawhide].
* authselect: upstream: https://github.com/authselect/authselect/pull/253
* libuser: upstream: https://pagure.io/libuser/pull-request/49, downstream: https://src.fedoraproject.org/rpms/libuser/pull-request/9
* pam: Is already capable to use yescrypt, but needs a small change in the config: https://src.fedoraproject.org/rpms/pam/pull-request/17
* shadow-utils: upstream: support is added to development branch, downstream: https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10


* libxcrypt: Is already capable for computing yescrypt hashes.
* accountsservice: Will support yescrypt in the [https://gitlab.freedesktop.org/accountsservice/accountsservice/-/commit/c4048b11d205762c9cb61ead4c81ba5f49640520 next release].  We carry [https://src.fedoraproject.org/rpms/accountsservice/pull-request/4 the patch downstream] until then.
* anaconda: yescrypt will be used as default for created password hashes with [https://github.com/rhinstaller/anaconda/pull/3431 anaconda >= 35.18].
* guestfs-tools: Support for yescrypt is in [https://github.com/rwmjones/guestfs-tools/commit/ba6d4cb7d394c1b5d14ef8103e3f64a8bcb35d77 v1.47.2 or later].  That's what we already [https://koji.fedoraproject.org/koji/buildinfo?buildID=1772490 have in Rawhide].
* libuser: Will support yescrypt in the [https://pagure.io/libuser/pull-request/49 next release].  We carry [https://src.fedoraproject.org/rpms/libuser/pull-request/9 the patches downstream] until then.
* libxcrypt: Is already capable for computing yescrypt hashes since v4.3.
* pam: Support for yescrypt is [https://github.com/linux-pam/linux-pam/pull/74 in v1.4.0 or later].  The downstream configuration files [https://src.fedoraproject.org/rpms/pam/pull-request/17 have been changed to make use of yescrypt by default].
* shadow-utils: Will support yescrypt in the [https://github.com/shadow-maint/shadow/pull/303 next release].  We carry [https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10 the patches downstream] until then.
* systemd: Defaults to yescrypt already.
* systemd: Defaults to yescrypt already.


== Contingency Plan ==
== Contingency Plan ==
* Blocks release? Yes
* Blocks release? Yes


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


== Documentation ==
== 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.
Fedora now uses the yescrypt hash 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 ==
== 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.
Fedora now uses the yescrypt hash 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.

Latest revision as of 15:02, 2 July 2021

Use yescrypt as default hashing method for shadow passwords

Summary

Make the yescrypt hashing method the default method used for new user passwords stored in /etc/shadow.


Owner


Current status

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 yescrypt - scalable KDF and password hashing scheme, the PHC submission paper, PHC yescrypt vs. Argon2, and the discussion on the Debian bugtracker.


Feedback

Feedback so far:

  • 2 times: +1 from users on the Fedora-devel-list.
  • Some people see possible problems, if one copies the shadow-file between different distributions and/or systems, and/or uses some distributed user/pw management service like LDAP.
  • It is agreed upon, we shouldn't force users to change their login password; rehashing the current password silently is no problem for them, though.


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 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: #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 (on cli or with your preferred GUI-based tool / control center of your desktop environment) and check whether the computed password hash for your user in /etc/shadow starts with $y$, like root:$y$j9T$JEFtZ/….
  • Fresh installations: Check whether the password hash(es) for the user(s) created by anaconda or gnome-initial-setup in /etc/shadow start(s) with $y$, like root:$y$j9T$JEFtZ/….


User Experience

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


Dependencies


Contingency Plan

  • Blocks release? Yes

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


Documentation

Fedora now uses the yescrypt hash 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 hash 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.