Store duress password in unix crypt format

[rechner]

https://github.com/nuvious/pam-duress/blob/30d7065e173d6062384387af10e74e8c1c138d48/src/duress.c#L193

Using the modular crypt(3) format from glibc instead of specifying a hash, will make this a bit more future-proof, storing passwords the same way as standard password authentication.

[Artoria2e5]

The thing about the crypt format is that it’s not exactly open to having a salt that long — in this case the whole script. I guess storing the hash of the script there instead is an option; explicitly listing it will allow for knowing whether it’s the password or the script that’s wrong (related to #20, maybe?).

[nuvious]

The thing about the crypt format is that it’s not exactly open to having a salt that long — in this case the whole script. I guess storing the hash of the script there instead is an option; explicitly listing it will allow for knowing whether it’s the password or the script that’s wrong (related to #20, maybe?).

Yup, for the use of crypt I would likely use the hash of the file as the salt as you described. The main interest in using crypt instead of digital signing is it allows me to associate passwords directly with scripts. Permission controls that only allows scripts to run if they have 500, 540, and 550 permissions are the next layer of reasonable protection. I am planning on either implementing group controls to limit what accounts can execute ~/.duress scripts and/or implementing conventional RSA signatures to ensure validation of scripts. However that's a low priority due to existing permission controls required for the module to execute scripts as well as the validity checking involved with the script being incorporated into the salt of the password (so you need a valid script and proper password for the script to be executed).

[nuvious]

One implementation discussion point; to maintain compatibility with MacOS, the current implementation may be preferable. From what I can see crypt() has mixed support for algorithms across BSD and Mac with only DES and BSDi being available in MacOS's implementation (their man page for crypt apparently hasn't been updated since the 1994 version they got from BSD and explicitly point to DES as the encryption standard). FreeBSD/NetBSD/OpenBSD also have no support for SHA 256/512. Given that I think it would be better to stick to the current implementation since openssl libraries are commonly available for all flavors of unix agnostic to their crypt implementation.

https://en.wikipedia.org/wiki/Crypt_(C)

[Artoria2e5]

From what I can see crypt() has mixed support for algorithms across BSD and Mac

Yeah. I think the argument for using MCF would be the ability to switch to other hash algos without breaking the format. The actual implementation will be likely independent of the libc with things like libxcrypt being used on some platforms.

[nuvious]

From what I can see crypt() has mixed support for algorithms across BSD and Mac

Yeah. I think the argument for using MCF would be the ability to switch to other hash algos without breaking the format. The actual implementation will be likely independent of the libc with things like libxcrypt being used on some platforms.

That sounds like the right path then. Definitely would like to leverage a common standard and this looks more appropriate than openssl and proprietary storage mechanisms at least at first glance.