What hash algorithms can I use in preseed's passwd/user-password-crypted entry?

Question

When it comes to passwd/user-password-crypted statement in a preseed file, most examples use an MD5 hash. Example:

# Normal user's password, either in clear text
#d-i passwd/user-password password insecure
#d-i passwd/user-password-again password insecure
# or encrypted using an MD5 hash.
#d-i passwd/user-password-crypted password [MD5 hash]

^{From Debian's Appendix B. Automating the installation using preseeding.}

A few sources show that it's also possible to use SHA-512:

Try using a hashed password like this:

$ mkpasswd -m sha-512

[...]

And then in your preseed file:

d-i passwd/user-password-crypted password $6$ONf5M3F1u$bpljc9f1SPy1w4J2br[...]

^{From Can't automate user creation with preseeding on AskUbuntu.}

This is slightly better than MD5, but still doesn't resist well against brute force and rainbow tables.

What other algorithms can I use? For instance, is PBKDF2 supported, or am I limited by the algorithms used in /etc/shadow, that is MD5, Blowfish, SHA-256 and SHA-512?

Solution 1

You can use anything which is supported in the /etc/shadow file. The string given in the preseed file is just put into /etc/shadow. To create a salted password to make it more difficult just use mkpasswd with the salt option (-S):

mkpasswd -m sha-512 -S $(pwgen -ns 16 1) mypassword
$6$bLyz7jpb8S8gOpkV$FkQSm9YZt6SaMQM7LPhjJw6DFF7uXW.3HDQO.H/HxB83AnFuOCBRhgCK9EkdjtG0AWduRcnc0fI/39BjmL8Ee1

In the command above the salt is generated by pwgen.

Solution 2

Looking at the appropriate part of the debian-installer source code we can see that it simply calls usermod USER --password=CRYPTED-PASSWORD inside the target chroot.

Further usermod's manpage susggests that the --password option accepts "The encrypted password, as returned by crypt(3)." and that "The password will be written in the local /etc/passwd or /etc/shadow file.". This suggests we can only use the crypted password formats described in the crypt(3) man page.

All hope is not lost however. From the aforementioned man page we learn that crypt actually includes a salt field in the crypted password string, the format being $hash_id$salt$hash. So at least in principle it should be resistant against rainbow tables.

Apart from rainbow table attacks we still have to consider brute-force attacks. If we look at the glibc implementation of crypt we see that it actually implements password stretching using multiple rounds of SHA-512 not entirely unlike but, unfortunately, not using a standard approach such as PBKDF2.

Furthermore we see that we can actually control the number of hash rounds applied by crypt using an additional field in the crypted password ($rounds=$). Looking at the mkpasswd(1) man page we find this exposed as the -R option. Using this feature we can significantly raise the default number of rounds of 5000 (see ROUNDS_DEFAULT in the source code) which on my machine takes less than a couple of milliseconds to calculate to, say, 10 million which takes a couple of seconds instead:

> mkpasswd -R 10000000 -m sha-512 mypassword
$6$rounds=10000000$Rq30Hdd.0LzWq3x$XRXHvd5MnIi5MD2H8Jtn5W0cjvq4siGtUgWUaETc4QZyvuR4iY0Af.DoNfj1E6SvoHaVotAEjIiOPS3GvwJjM0

Comments

[Arseni Mourzenko]

The y argument should be removed: including symbols in the salt would usually lead to the error "Illegal salt character '...'." because the authorized characters are rather limited.

[Royce Williams]

A couple of symbols - . and / - are valid - see Daniel G's crypt / mkpasswd answer.