I can do it, once its gets approved/included On Thu, Jun 10, 2021 at 6:21 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Mon, Jun 7, 2021 at 3:00 PM Ben Cotton <bcot...@redhat.com> 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: besse...@fedoraproject.org > > > > > > == 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
