Password hashes from mkpasswd result in unusable passwords

[antifuchs]

Describe the bug

The nixos manual suggests:

Passwords may still be assigned by setting the user's hashedPassword option. A hashed password can be generated using mkpasswd -m sha-512.

Unfortunately, this outputs password hashes that do not let the user in when using the password being set. Another method of getting a salted password hash from stackoverflow results in a password hash that does work.

Steps To Reproduce

Steps to reproduce the behavior:

1. Run mkpasswd -m sha-512 and enter a randomly-generated password (I set a 27-character password consisting of lowercase letters and digits).
2. Set users.users.root.hashedPassword = "<the emitted hash>"; in system config
3. nixos-rebuild switch
4. su and enter the randomly-generated password above
5. su: Authentication failure
6. Use nix-shell -p python3 --run "python -c 'import crypt,getpass; print(crypt.crypt(getpass.getpass(), crypt.mksalt(crypt.METHOD_SHA512)))'" to get a password hash; set that and rebuild
7. su and enter the randomly-generated password
8. root login shell opens.

Expected behavior

su should accept the password in step 5.

Additional context

I have many suspicions on why mkpasswd-emitted hashes don't work, but haven't yet evaluated any of them:

• input too long
• broken hash algorithm
• broken salt?

Notify maintainers

@fpletz

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.57, NixOS, 21.11 (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210802_47e96bb`
 - nixpkgs: `/nix/store/npgpi8bip0qsh860rr3z6qrq5iwr04sd-source`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: [mkpasswd]
# a list of nixos modules affected by the problem
module: []

[Artturin]

works for me
nixos-21.11pre311431.88226ea038e

uuW5gV3WqFcLBL6hAQvGawaqGCn

$6$zKKK62lCr5pxmowD$QgVJrmyH9RSLpaHOT340kHih5HQJJckpQtc4Dxrys3o7un/N7DhuDoeyUwoyL/siuVoWwY2oZnIeYaMjjGmyR.

[rnhmjoj]

I've always used this method and never had any trouble. Can you post a specific hash that breaks the login?

[antifuchs]

Hah. Took me a little while to reset the password I had tried to set so that I can publish it here. I used teeny3vassar2stipple2bereft. The salt that mkpasswd generated was WWnJtJKELmoUU, resulting in the following hash:

:;    mkpasswd -m sha-512
Password:
$6$WWnJtJKELmoUU$DWBEmWnGIeAYCUFFhqrCT1DIkBI1NxRSuO2./FfMrmSRjEwJSFLp44J.RqSYHDn2qf13YLEJbe1RO7OxdfGYk1

You can repro that on other systems with mkpasswd -S WWnJtJKELmoUU -m sha-512

Generating the same password hash with the python command line above (using the pre-set salt) results in a different hash though:

:;    nix-shell -p python3 --run "python -c 'import crypt,getpass; print(crypt.crypt(\"teeny3vassar2stipple2bereft\", \"\$6\$WWnJtJKELmoUU\"))'"
$6$WWnJtJKELmoUU$tnVT0Vl.oMEN.dhp/vlmy5clJOwj3k0G36Qu0OcYO0OpB00SiZRjBoJH7/DSYy.E0klnn.maSm7eUjeA/brB7/

And given that the python script can generate a password that I can use to log in... I think something is wonky with mkpasswd.

[antifuchs]

Trying some other randomly-generated strings, I notice that I must have gotten pretty (un)lucky: mkpasswd and crypt.crypt generate the same hash given the same salt, on many passwords. Just the first one I tried causes things to go off the rails (typical!) (:

[stale]

I marked this as stale due to inactivity. → More info

[montchr]

I've run into this in the past as well and am a bit wary of mkPassword because of it (recovering from an account lockout is not fun). I'm still curious what the cause might be and if it's still an issue for others.

[AkechiShiro]

Is this issue still relevant ? I've tried generating a password using mkpasswd with a random salt from /dev/urandom but saw very weird non-printable characters, I inputted a random salt but with only printable characters, and took the result (I was in the installation minimal ISO NixOS 22.10) and set it up for the nixos user, using pkgs.lib.mkForce <value> and then a nixos-rebuild switch and it worked alright to log in and lock the installation medium using vlock.

[fadenb]

We experienced the issue described here just two weeks ago and are still in the process of rolling out fixed hashes to avoid lock-outs 🙈
@otti0815: Which versions of NixOS were in use where we encountered the issue?

[fpletz]

@fadenb can you confirm you you indeed used sha-512 and the prefix is $6$? I think this issue is invalid because people forgot to add the hashing method to the mkpasswd call. Yescrypt is the new default in mkpasswd which is not supported in nixpkgs yet: #147312

There is a draft PR #181764 and I also tried fixing this in the past but it's complicated and requires lots of rebuilds. 🙁

[AkechiShiro]

I can confirm @fpletz that I've used SHA-512 for mine, I believe you are correct, hence why I commented that I did not run into the issue.

[raboof]

@fadenb can you confirm you you indeed used sha-512 and the prefix is $6$? I think this issue is invalid because people forgot to add the hashing method to the mkpasswd call. Yescrypt is the new default in mkpasswd which is not supported in nixpkgs yet: #147312

There is a draft PR #181764 and I also tried fixing this in the past but it's complicated and requires lots of rebuilds. slightly_frowning_face

This PR is now merged, and the manual no longer suggests -m sha-512. Does that mean this issue can now be closed, or is there more left to do?

[fpletz]

This PR is now merged, and the manual no longer suggests -m sha-512. Does that mean this issue can now be closed, or is there more left to do?

We indeed now support all hashes that libxcrypt supports with 23.05 and thus this issue can be closed. Thanks.