Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#67393 - [shadow][pambase] Stop overriding the specified ENCRYPT_METHOD in /etc/login.defs

Attached to Project: Arch Linux
Opened by loqs (loqs) - Saturday, 25 July 2020, 17:25 GMT
Last edited by David Runge (dvzrv) - Wednesday, 18 November 2020, 09:47 GMT
Task Type Feature Request
Category Packages: Testing
Status Assigned
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No

Details

Description:
The method is currently overridden in all its uses meaning the actual value specified in /etc/login.defs has no effect.
This could cause confusion. Also synchronizing a setting in multiple locations can introduce errors.
It is used in at least:
* /etc/pam.d/chpasswd
* /etc/pam.d/newusers
* /etc/pam.d/passwd
* /etc/pam.d/system-auth

PKGBUILD.diff.shadow removed all uses of sha512. Changed dropped module pam_cracklib.so to pam_pwquality.so, man page lists parameters as being the same but I have not checked this.
PKGBUILD.diff.pambase removed use of sha512.

Additional info:
* shadow 4.8.1-3
* pambase 20190105.1-2
   PKGBUILD.diff.shadow (1.2 KiB)
   PKGBUILD.diff.pambase (1.1 KiB)
This task depends upon

Comment by Tobias Powalowski (tpowa) - Wednesday, 12 August 2020, 19:40 GMT
pambase-20200721.1-2 should fix this, shadow is pending.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 14 September 2020, 19:14 GMT
Will make the suggested changes to shadow later this week
Comment by Geert Hendrickx (ghen) - Thursday, 10 December 2020, 10:04 GMT
The direct pam config allows more choices than ENCRYPT_METHOD in /etc/login.defs though, which can only be set to DES, MD5, SHA256, SHA512 or (undocumented) BCRYPT.
pam_unix(8) supports more algorithms, like yescrypt.
Comment by Geert Hendrickx (ghen) - Thursday, 10 December 2020, 19:17 GMT
Btw, upstream is planning to handle this differently in the future, and rely on libxcrypt's crypt_preferred_method() instead of a (potentially dated) system preference:
https://github.com/linux-pam/linux-pam/pull/84
Comment by loqs (loqs) - Saturday, 05 June 2021, 22:19 GMT
The pambase-20200721.1-2 change was reverted by pambase 20210605-1: hash with sha512 by default.

Should this be closed as Won't Fix?
Comment by Geert Hendrickx (ghen) - Sunday, 06 June 2021, 19:47 GMT
The crypt(5) manpage lists sha512crypt as "acceptable" (if properly configured, not by default), but recommends yescrypt for new hashes.
Comment by loqs (loqs) - Sunday, 06 June 2021, 21:00 GMT
@ghen you want to submit a patch changing all use of sha512 in pam files to yescrypt, adding it to pam_unix password entries that do not specify an encryption method and removing it from /etc/login.defs?
You could also standardize the use of nullok. You could also consider changing physlock and kbd to using upstreams pam configs that use system-auth rather directly using pam_unix.
Edit:
man 5 crypt notes 5000 rounds is too low for modern hardware for sha512/sha256 but does not provide a recommended number of rounds.
Does the libxcrypt project have a recommendation for the number of rounds that currently could be used? That could then be set in upstream shadows login.defs.
Or patch shadow with yescrypt support [1] and add the option there?

[1] https://github.com/shadow-maint/shadow/commit/5cd04d03f94622c12220d4a6352824af081b8531

Loading...