Am Di., 8. Juni 2021 um 15:46 Uhr schrieb Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl>: > > 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 > > <rjo...@redhat.com>: > > > > > > 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
