nixos/pam: add option to control how pam_unix hashes passwords #208603
Conversation
|
|
||
| Consider switching to "yescrypt rounds=10" for | ||
| better resistance against brute force, especially if | ||
| your login password is used as a key for encrypted |
There was a problem hiding this comment.
I expect the most common case to be that the password is used to unwrap decryption keys for the very root filesystem that contains the shadow file. In that case choosing a weak hash function does not help an attacker who wishes to decrypt the filesystem, and yet this docstring suggests otherwise. I'm not sure how to phrase it in a way that is both succinct and precise, sadly.
There was a problem hiding this comment.
I believe you are talking of whole-disk-encryption. In that case, the decryption passphrase and login password are independent (and in general different, especially if there is more than one user).
ecryptfs & friends are generally used to encrypt user home directories, not /etc/shadow. For convenience the passphrase is encrypted using the login password of each user, so being able to brute force these is an issue.
There was a problem hiding this comment.
What happens when I just change this setting on my system?
There was a problem hiding this comment.
Would types.listOf types.str make more sense here?
There was a problem hiding this comment.
@SuperSandro2000, passwords in /etc/shadow will then be hashed using the methodology you selected.
There was a problem hiding this comment.
This affects the default for e.g. passwd.
| description = lib.mdDoc '' | ||
| Arguments to the pam_unix module. | ||
|
|
||
| Consider switching to "yescrypt rounds=10" for |
There was a problem hiding this comment.
I could easily find sources that recommend yescrypt over sha512 on the internet but none of those mentioned that you should use 10 rounds. I would leave that out of the recommendation for now.
There was a problem hiding this comment.
The recommendation is specific to people protecting other on-disk secrets with the same password. For this usecase, the default number of rounds (5) isn't good enough. Here's one blog post that discusses this: https://medium.com/@slimm609/cost-based-password-hashing-b383bbb355df
| @@ -1184,6 +1184,19 @@ in | |||
| }; | |||
| }; | |||
|
|
|||
| security.pam.unixAuthArgs = mkOption { | |||
| default = "sha512"; | |||
There was a problem hiding this comment.
| default = "sha512"; | |
| default = "yescrypt"; |
The actual default on unstable right now.
And somewhat plausible alternatives:
https://github.com/besser82/libxcrypt/blob/v4.4.33/lib/hashes.conf#L42-L47
Most everyone should migrate away from sha512crypt to a more recent KDF that includes additional hardness properties.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/hashing-plain-text-password-directly-in-configuration-nix/2093/27 |
wegank
added
2.status: stale
stale
bot
removed
the
2.status: stale
Description of changes
Once your computer is stolen or physically accessed, you might not care about your login password being brute-forced. Unless it is also used to encrypt your key for ecryptfs/fscrypt/or other similar home directory encryption, then you really care.
This change makes the hashing algorithm used for password encoding configurable as a NixOS module option and suggests
yescryptfor cases which need good brute-force resistance.Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes