Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
I can do it, once its gets approved/included On Thu, Jun 10, 2021 at 6:21 PM Neal Gompa wrote: > On Mon, Jun 7, 2021 at 3:00 PM Ben Cotton 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 /etc/shadow. > > > > > > == 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Mon, Jun 7, 2021 at 3:00 PM Ben Cotton 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 /etc/shadow. > > > == 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 /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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Tue, 8 Jun 2021 at 12:27, Stephen Gallagher wrote: > On Tue, Jun 8, 2021 at 10:51 AM Tom Hughes wrote: > > > > On 08/06/2021 14:51, Stephen Gallagher wrote: > > > > > I was thinking about suggesting a similar PAM module to convert > > > existing hashes, but I suspect that we'd be coming up against some > > > issues with security policy and separation of actions. Right now, I > > > expect that SELinux permits PAM processes to have read-only access to > > > /etc/shadow, but such a change would necessitate read/write access, > > > which is riskier. It's also why PAM has separate activities for > > > authentication, authorization and password-change. > > > > Surely it has to allow write as well because any authentication can > > already prompt for a password change if the password is expired? > > > > It's been a while, but I *think* I remember that PAM sends back an > "expired password" message and the client application (eg. `login`) > then calls the pam_chpass() stack. > ___ > I believe it is something like that. mainly because there are many systems where a password change is a major auditable event and you only want those generated from specific systems and then pushed out. [Yes this doesn't fit well with the world of today, but the PAM stack was written for the security policies and actions of the late 1980's/early 1990's... ] -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Tue, Jun 8, 2021 at 10:51 AM Tom Hughes wrote: > > On 08/06/2021 14:51, Stephen Gallagher wrote: > > > I was thinking about suggesting a similar PAM module to convert > > existing hashes, but I suspect that we'd be coming up against some > > issues with security policy and separation of actions. Right now, I > > expect that SELinux permits PAM processes to have read-only access to > > /etc/shadow, but such a change would necessitate read/write access, > > which is riskier. It's also why PAM has separate activities for > > authentication, authorization and password-change. > > Surely it has to allow write as well because any authentication can > already prompt for a password change if the password is expired? > It's been a while, but I *think* I remember that PAM sends back an "expired password" message and the client application (eg. `login`) then calls the pam_chpass() stack. ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Dienstag, dem 08.06.2021 um 15:08 +0100 schrieb Tom Hughes via devel: > On 08/06/2021 14:51, Stephen Gallagher wrote: > > > I was thinking about suggesting a similar PAM module to convert > > existing hashes, but I suspect that we'd be coming up against some > > issues with security policy and separation of actions. Right now, I > > expect that SELinux permits PAM processes to have read-only access > > to > > /etc/shadow, but such a change would necessitate read/write access, > > which is riskier. It's also why PAM has separate activities for > > authentication, authorization and password-change. > > Surely it has to allow write as well because any authentication can > already prompt for a password change if the password is expired? Well, extending the pam_unix module in such a way, may be the best solution: * User logs in. * PAM checks password * hash is not $y$ * silently rehash plain password with yescrypt * update shadow ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Dienstag, dem 08.06.2021 um 09:22 -0500 schrieb Martin Jackson: > > On 6/8/21 9:13 AM, Ewoud Kohl van Wijngaarden wrote: > > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser > > wrote: > > > Unfortunately there is no automatic way to update the hash from > > > anything, but yescrypt, to yescrypt without knowing / entering the > > > actual user password; in the future existing yescrypt hashes can be > > > updated to new yescrypt hashes with stronger salts and/or cost > > > parameters in-place without changing the password, and without user > > > interaction. > > > > > > Has anyone some better idea? > > > > they use older distros that don't support it, it'll end up flapping > > where one system sets it to the older hashing and one to the newer. > > > > Or maybe I'm just the only person who does this. > > Indeed you are not the only one. Even in large LDAP shops, there > could > be a local "break-glass" account, so managing hashes could still be a > factor in those environments. > > One of the pain points of managing a large-scale Puppet infrastructure > is supporting different hashes for different OS's. I've seen this > done, > and the result is...not always pretty. > > What does usage of yescrypt look like in the rest of the ecosystem? > Are > other major distros moving to it, or likely to? Debian is moving to yescrypt; ALT Linux and Kali Linux have already switched. Most other distributions, that ship libxcrypt >= 4.3 have support for yescrypt and are able to deal with $y$ shadow hashes out of the box; they simply just lack the adaption of the tools (shadow-utils, pam, etc.) to use it as hash method for *creating* shadow hashes. ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Di., 8. Juni 2021 um 15:46 Uhr schrieb Zbigniew Jędrzejewski-Szmek : > > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: > > Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones > > : > > > > > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > > > == 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. > > > > > > libguestfs (virt-customize etc.) might also need changing. What > > > happens if a new user account is created with (eg) $6$ sha512. Does > > > it use that scheme forever? Attempt to upgrade it? Break? > > > > Well, yes, that needs to be updated, too, but it's written in OCAML… > > I suppose, you want to volunteer, and get a well deserved F35 change > > badge for doing so?! :P > > > > If a user account is created with a sha512crypt hash, it will keep it > > as long as the password remains unchanged. I'm currently thinking of > > a way to migrate all local users to use yescrypt hashes, but it's not > > that easy: Human users could be prompted on first login to change > > their password, if the hash in shadow is not yescrypt - there is a way > > to force that. But what about local users with older password hashes > > that get logged in by any non-human interaction, like www-cron; those > > would need to be updated manually by the system admin. Maybe I can > > write a CLI-tool for doing so. > > > > Unfortunately there is no automatic way to update the hash from > > anything, but yescrypt, to yescrypt without knowing / entering the > > actual user password; > > I think it's better to leave existing passwords in place. You can't > really force people to log in as all users, so the only realistic > scenario is to keep existing passwords if there's more than one user. > > And I don't think there's a reason to try to force immediate password > switch. As far as we know, previous defaults like sha256 are OK. > > > in the future existing yescrypt hashes can be > > updated to new yescrypt hashes with stronger salts and/or cost > > parameters in-place without changing the password, and without user > > interaction. > > Interesting. How does this work? You can find a basic description here: https://www.sjoerdlangkemper.nl/2018/01/31/client-independent-upgrade-in-hash-functions/ ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Indeed you are not the only one. Even in large LDAP shops, there could be a local "break-glass" account, so managing hashes could still be a factor in those environments. One of the pain points of managing a large-scale Puppet infrastructure is supporting different hashes for different OS's. I've seen this done, and the result is...not always pretty. What does usage of yescrypt look like in the rest of the ecosystem? Are other major distros moving to it, or likely to? Marty On 6/8/21 9:13 AM, Ewoud Kohl van Wijngaarden wrote: On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: Unfortunately there is no automatic way to update the hash from anything, but yescrypt, to yescrypt without knowing / entering the actual user password; in the future existing yescrypt hashes can be updated to new yescrypt hashes with stronger salts and/or cost parameters in-place without changing the password, and without user interaction. Has anyone some better idea? I'd advise against this. People can use a system like Puppet to sync password hashes between systems (as a cheap alternative to LDAP). If they use older distros that don't support it, it'll end up flapping where one system sets it to the older hashing and one to the newer. Or maybe I'm just the only person who does this. ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: Unfortunately there is no automatic way to update the hash from anything, but yescrypt, to yescrypt without knowing / entering the actual user password; in the future existing yescrypt hashes can be updated to new yescrypt hashes with stronger salts and/or cost parameters in-place without changing the password, and without user interaction. Has anyone some better idea? I'd advise against this. People can use a system like Puppet to sync password hashes between systems (as a cheap alternative to LDAP). If they use older distros that don't support it, it'll end up flapping where one system sets it to the older hashing and one to the newer. Or maybe I'm just the only person who does this. ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On 08/06/2021 14:51, Stephen Gallagher wrote: I was thinking about suggesting a similar PAM module to convert existing hashes, but I suspect that we'd be coming up against some issues with security policy and separation of actions. Right now, I expect that SELinux permits PAM processes to have read-only access to /etc/shadow, but such a change would necessitate read/write access, which is riskier. It's also why PAM has separate activities for authentication, authorization and password-change. Surely it has to allow write as well because any authentication can already prompt for a password change if the password is expired? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On 6/8/21 3:18 PM, Björn 'besser82' Esser wrote: I'm currently thinking of a way to migrate all local users to use yescrypt hashes, but it's not that easy: Human users could be prompted on first login to change their password, if the hash in shadow is not yescrypt - there is a way to force that. This is a very bad choice. SHA512crypt still not cracked -> no need to force users to change their passwords. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Tue, Jun 8, 2021 at 2:46 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: > > Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones > > : > > > > > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > > > == 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. > > > > > > libguestfs (virt-customize etc.) might also need changing. What > > > happens if a new user account is created with (eg) $6$ sha512. Does > > > it use that scheme forever? Attempt to upgrade it? Break? > > > > Well, yes, that needs to be updated, too, but it's written in OCAML… > > I suppose, you want to volunteer, and get a well deserved F35 change > > badge for doing so?! :P > > > > If a user account is created with a sha512crypt hash, it will keep it > > as long as the password remains unchanged. I'm currently thinking of > > a way to migrate all local users to use yescrypt hashes, but it's not > > that easy: Human users could be prompted on first login to change > > their password, if the hash in shadow is not yescrypt - there is a way > > to force that. But what about local users with older password hashes > > that get logged in by any non-human interaction, like www-cron; those > > would need to be updated manually by the system admin. Maybe I can > > write a CLI-tool for doing so. > > > > Unfortunately there is no automatic way to update the hash from > > anything, but yescrypt, to yescrypt without knowing / entering the > > actual user password; > > I think it's better to leave existing passwords in place. You can't > really force people to log in as all users, so the only realistic > scenario is to keep existing passwords if there's more than one user. > > And I don't think there's a reason to try to force immediate password > switch. As far as we know, previous defaults like sha256 are OK. > Yes, please do not force users to change their password just to use the new hash. Fedora can be used as a personal workstation distribution, so people may have their own policies/decisions on when they want to change passwords - and simply upgrading the OS may not be part of that policy. -Ian ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Tue, Jun 8, 2021 at 9:46 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: ... > > in the future existing yescrypt hashes can be > > updated to new yescrypt hashes with stronger salts and/or cost > > parameters in-place without changing the password, and without user > > interaction. > > Interesting. How does this work? My guess would be that the PAM module that performs the authentication would just re-encrypt and store that password after a successful auth against the previous salt/params. I was thinking about suggesting a similar PAM module to convert existing hashes, but I suspect that we'd be coming up against some issues with security policy and separation of actions. Right now, I expect that SELinux permits PAM processes to have read-only access to /etc/shadow, but such a change would necessitate read/write access, which is riskier. It's also why PAM has separate activities for authentication, authorization and password-change. ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: > Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones > : > > > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > > == 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. > > > > libguestfs (virt-customize etc.) might also need changing. What > > happens if a new user account is created with (eg) $6$ sha512. Does > > it use that scheme forever? Attempt to upgrade it? Break? > > Well, yes, that needs to be updated, too, but it's written in OCAML… > I suppose, you want to volunteer, and get a well deserved F35 change > badge for doing so?! :P > > If a user account is created with a sha512crypt hash, it will keep it > as long as the password remains unchanged. I'm currently thinking of > a way to migrate all local users to use yescrypt hashes, but it's not > that easy: Human users could be prompted on first login to change > their password, if the hash in shadow is not yescrypt - there is a way > to force that. But what about local users with older password hashes > that get logged in by any non-human interaction, like www-cron; those > would need to be updated manually by the system admin. Maybe I can > write a CLI-tool for doing so. > > Unfortunately there is no automatic way to update the hash from > anything, but yescrypt, to yescrypt without knowing / entering the > actual user password; I think it's better to leave existing passwords in place. You can't really force people to log in as all users, so the only realistic scenario is to keep existing passwords if there's more than one user. And I don't think there's a reason to try to force immediate password switch. As far as we know, previous defaults like sha256 are OK. > in the future existing yescrypt hashes can be > updated to new yescrypt hashes with stronger salts and/or cost > parameters in-place without changing the password, and without user > interaction. Interesting. How does this work? Zbyszek ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones : > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > == 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. > > libguestfs (virt-customize etc.) might also need changing. What > happens if a new user account is created with (eg) $6$ sha512. Does > it use that scheme forever? Attempt to upgrade it? Break? Well, yes, that needs to be updated, too, but it's written in OCAML… I suppose, you want to volunteer, and get a well deserved F35 change badge for doing so?! :P If a user account is created with a sha512crypt hash, it will keep it as long as the password remains unchanged. I'm currently thinking of a way to migrate all local users to use yescrypt hashes, but it's not that easy: Human users could be prompted on first login to change their password, if the hash in shadow is not yescrypt - there is a way to force that. But what about local users with older password hashes that get logged in by any non-human interaction, like www-cron; those would need to be updated manually by the system admin. Maybe I can write a CLI-tool for doing so. Unfortunately there is no automatic way to update the hash from anything, but yescrypt, to yescrypt without knowing / entering the actual user password; in the future existing yescrypt hashes can be updated to new yescrypt hashes with stronger salts and/or cost parameters in-place without changing the password, and without user interaction. Has anyone some better idea? Björn ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > == 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. libguestfs (virt-customize etc.) might also need changing. What happens if a new user account is created with (eg) $6$ sha512. Does it use that scheme forever? Attempt to upgrade it? Break? https://github.com/rwmjones/guestfs-tools/blob/e929ce331740d383d020e126fab8ff93663e8b2b/customize/password.ml#L124 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
+1 ...and many thanks for providing a very comprehensive rationale. On Tue, 8 Jun 2021 at 21:47, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > == Feedback == > +1 > > > == Benefit to Fedora == > > == 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. > I added systemd to the list here: systemd-sysusers supports yescrypt > as the default (through crypt_preferred_method() which also returns > yescrypt, or directly if crypt_preferred_method() is not available). > > Zbyszek > ___ > 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
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > == Feedback == +1 > == Benefit to Fedora == > == 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. I added systemd to the list here: systemd-sysusers supports yescrypt as the default (through crypt_preferred_method() which also returns yescrypt, or directly if crypt_preferred_method() is not available). Zbyszek ___ 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
