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?

up vote 2 down vote accepted

I think 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 -yns 16 1) mypassword
$6$bLyz7jpb8S8gOpkV$FkQSm9YZt6SaMQM7LPhjJw6DFF7uXW.3HDQO.H/HxB83AnFuOCBRhgCK9EkdjtG0AWduRcnc0fI/39BjmL8Ee1

In the command above the salt is generated by pwgen.

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

Rainbow tables and brute forcing aren't relevant here.

The sha-512 password is salted. That means for whatever hash you have, the password begins with a salt value (ONf5M3F1u in this case). To generate a rainbow table, you have to generate a full list of sha-512 hashes for all typable strings beginning with "ONf5M3F1u".

Let's say you used the theoretical hash algorithm "CSUM-2", which simply adds up the characters and produces a 2-bit hash out of the least-significant bits. A rainbow table for CSUM-2 looks like the below:

0 d
1 a
2 b
3 c

Note that only the two LSB are relevant, so you really have four salts: d, a, b, and c.

So imagine these four hashes of the password 'b', with salts. The salt prepends, so you'd hash e.g. "db" to get just "b", or "ab" to get "c".

$-1$d$b
$-1$a$c
$-1$b$d
$-1$c$a

To use a rainbow table to crack CSUM-2, you need four separate rainbow tables of four entries each.

To crack sha-512 with a salt of nine characters as above, you need 62 full rainbow tables. A sha-512 rainbow table sufficient for up to 9 alphanumerical characters is 864GB in size; with this kind of salting, you need 62 of those, or 52TB of tables.

Note that 2^512 is a lot more than just 9-character passwords can provide. There are 1.3 x 10^154 hashes, and 1.35 x 10^19 9-character alphanumerical passwords. Longer passwords mean a larger password space, more entries, and bigger tables. That multiplies linearly by the number of salts, and exponentially by the length of the salt.

Someone has to generate and store all of those tables.

PBKDF2 simply performs the computation numerous times; however, a PBKDF2 output will always be the same, and so you're back to rainbow tables cracking PBKDF2 just like any other algorithm.

PAM can use the rounds parameter to perform key stretching as well; the default is 5,000 and the minimum is 1,000. rounds=65536 would run SHA-512 2^16 times on each log-in attempt. This would make brute forcing slower, although a precomputed rainbow table still doesn't care. Building and storing that rainbow table is, as stated above, hard.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.