FS#71393 - [shadow] Use yescrypt hash for passwords for improve security

Attached to Project: Arch Linux
Opened by leazar (leazar) - Tuesday, 29 June 2021, 09:04 GMT
Last edited by David Runge (dvzrv) - Friday, 22 September 2023, 20:32 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
David Runge (dvzrv)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

SHA512 is designed to be fast (which makes it easier to brute-force), while yescrypt is designed to resist password cracking because it's computationally expensive and hard on memory & GPU. Fedora is going to use it in its next release (https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow).

Please consider changing the default hashing method for passwords to yescrypt.
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 22 September 2023, 20:32 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with 4.14.0-3
Comment by loqs (loqs) - Tuesday, 29 June 2021, 15:45 GMT
I added support for yescrypt (the current release of shadow does not support it, Fedora uses [1]) and ENCRYPT_METHOD YESCRYPT to  FS#69933  if  FS#67393  is implemented these changes would be enough otherwise the encryption method would need to be changed in the pam configs supplied by util-linux and pambase.

[1] https://src.fedoraproject.org/rpms/shadow-utils/blob/rawhide/f/shadow-4.8.1-yescrypt-support.patch
Comment by Rodolphe (br.r) - Sunday, 26 September 2021, 13:58 GMT
I would also be very interested in yescrypt being the default password hashing method. In case anyone would like additional reasons to switch from sha512crypt to yescrypt, I would like to share some resources about the danger of sha512crypt [1][2] as well as one that recommends yescrypt [3]. By the way, as stated in Fedora's rationale linked above, yescrypt is compatible with the NIST SP 800-63B.

Good news: shadow 4.9 has been released with yescrypt support [4], there is no need to patch it anymore. However, the package has not been updated yet.
Ideally, the shadow and pambase could be updated simultaneously in order to use yescrypt as the default password hashing method.

[1]: https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/
[2]: https://tches.iacr.org/index.php/TCHES/article/view/8675
[3]: https://www.mdpi.com/2410-387X/1/2/10
[4]: https://github.com/shadow-maint/shadow/releases/tag/v4.9
Comment by mark roi (markroi) - Thursday, 10 February 2022, 18:11 GMT
So we have shadow 4.11 but the pam encryption method is still overridden with sha512 (and  FS#67393  seems dead). I wonder why isn't security taken more seriously.
Comment by Andrew (drew33) - Thursday, 14 April 2022, 12:06 GMT
Hi package maintainers, I've created a patch for enabling both yescrypt & bcrypt in the current PKGBUILD.

I quickly tested locally with yescrypt & sha512, and works for login and changing passwords as expected. Let me know if there's anything I can do to help push this through?
Many thanks!

Update: I tested rolling back shadow to the official package, but with 'yescrypt' still enabled in /etc/pam.d/passwd and it seems that this patch isn't necessary - yescrypt still works without the change in the shadow PKGBUILD. Given that, it's hard for me to say how useful this change to shadow is...
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by loqs (loqs) - Wednesday, 09 August 2023, 15:27 GMT
Default password hash is currently still SHA512.
Comment by leazar (leazar) - Saturday, 26 August 2023, 08:41 GMT
I'd still like to ask devs to please consider changing the hashing method to yescrypt.
Comment by David Runge (dvzrv) - Saturday, 26 August 2023, 09:10 GMT
It's on my list when rebasing our distro customizations on top of 4.14. Just requires some dedicated/consecutive time, which I might not have before beginning of September.
Comment by loqs (loqs) - Monday, 28 August 2023, 21:12 GMT
@dvzrv I have rebased The Arch patches on top of 4.14.0 in https://gitlab.archlinux.org/loqs/shadow-maint/-/commits/Arch-4.14.0
Changes to the patches are made as fixups intended to be squashed into the four existing commits, in conjunction with
https://gitlab.archlinux.org/loqs/shadow/-/commits/shadow-4.14
https://gitlab.archlinux.org/loqs/pambase/-/commits/shadow-4.14
https://gitlab.archlinux.org/loqs/filesystem/-/commits/shadow-4.14
Implements  FS#67393   FS#71393   FS#66068 .
Not implemented  FS#33677  (See issue) and  FS#45903  (No response from those affected to proposed fix).
Edit:
I forgot to note additional changes for shadow 4.14.0:
Added --without-libbsd to avoid moving libbsd to core, shadow will use its own copy of readpassphrase [1] which does not appear to be used when pam is enabled.
Added --enable-lastlog to keep providing lastlog until util-linux provides lastlog2 [2].

[1] https://github.com/shadow-maint/shadow/issues/779
[2] https://github.com/util-linux/util-linux/pull/2164
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 10:24 GMT
@loqs: Thanks for the work on this, it is much appreciated!
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 11:08 GMT
@loqs: I think lastlog should not be reenabled. It is not Y2038 safe (and its use has been removed in pam as well, see https://github.com/linux-pam/linux-pam/releases/tag/v1.5.3)
Comment by GalaxySnail (GalaxySnail) - Monday, 18 September 2023, 11:54 GMT
IMHO yescrypt has already been supported by shadow/pam/libxcrypt, and the only thing we need to do is replace `sha512` with `yescrypt` in `/etc/pam.d/passwd`.

```
--- /etc/pam.d/passwd.bak
+++ /etc/pam.d/passwd
@@ -1,2 +1,2 @@
#%PAM-1.0
-password required pam_unix.so sha512 shadow nullok
+password required pam_unix.so yescrypt shadow nullok
```

It works well for me.
Comment by loqs (loqs) - Monday, 18 September 2023, 12:09 GMT
@dvzrv thank you for looking into the latlog issue.

@GalaxySnail did it not work for you specifying "ENCRYPT_METHOD YESCRYPT" in /etc/login.defs and not overriding that in any PAM config?
Comment by GalaxySnail (GalaxySnail) - Monday, 18 September 2023, 12:51 GMT
@loqs No, it doesn't work. AFAIK, passwd(1) doesn't follow configs in /etc/login.defs in shadow 4.13 if pam is enabled while building shadow, it just calls pam directly. [1]
chpasswd(1) follows /etc/login.defs in some cases. If `-e`, `-c`, or `-m` option is passed, it follows /etc/login.defs and set password by itself. [2] Otherwise, it calls pam directly.

[1] search `use_pam` in https://github.com/shadow-maint/shadow/blob/4.13/src/passwd.c
[2] https://github.com/shadow-maint/shadow/blob/4.13/src/chpasswd.c#L460

By the way, the manual of shadow is outdated, only the source code is reliable.

In shadow 4.14.0, a new `-P, --prefix` option was added for passwd(1). If this option is passed, passwd(1) will follow /etc/login.defs. [3]

[3] https://github.com/shadow-maint/shadow/blob/4.14.0/src/passwd.c#L747-L752
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 13:48 GMT
There is now filesystem 2023.09.18-1, pambase 20230918-1 and shadow 4.14.0-1 in [core-testing].

Please give it a thorough test and report back with any problems!
Comment by GalaxySnail (GalaxySnail) - Monday, 18 September 2023, 17:25 GMT
I made a quick test and everything looks good, the default algorithm is currently yescrypt. Thanks for your efforts!
Comment by loqs (loqs) - Monday, 18 September 2023, 17:58 GMT
@GalaxySnail you are correct chpasswd/passwd is handing off to pam and the supplied pambase uses pam_unix.so that supports ENCRYPT_METHOD from /etc/login.defs.
Comment by leazar (leazar) - Tuesday, 19 September 2023, 06:50 GMT
Seems to work fine here. Thanks dvzrv and loqs!
Comment by loqs (loqs) - Tuesday, 19 September 2023, 19:31 GMT
Just to note in relation to [1] there is an even older PR for argon2 [2] again waiting for upstream to respond.

[1] https://lists.archlinux.org/archives/users/d4ab9c9aac3740aca7fc577020f054af/
[2] https://github.com/besser82/libxcrypt/pull/113
Comment by David Runge (dvzrv) - Tuesday, 19 September 2023, 19:35 GMT
Yeah, I saw... I didn't want to make it look... that bad :S

Loading...