On Mon, Jun 7, 2021 at 3:00 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow > > == 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: besser82@xxxxxxxxxxxxxxxxx > > > == 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_password_authentication > 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. > If this gets done (I hope it does!), someone needs to update the Security Matrix page: https://fedoraproject.org/wiki/Security_Features_Matrix -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
