Date: Sun, 25 Jul 1999 03:14:52 +0930 (CST) From: Kris Kennaway <kkenn@rebel.net.au> To: security@freebsd.org Subject: New libcrypt snapshot Message-ID: <Pine.BSF.4.10.9907250308340.95389-100000@morden.rebel.net.au>
next in thread | raw e-mail | index | archive | help
After some delay, I've got another snapshot of my libcrypt code ready for comment and testing: http://www.freebsd.org/~kris/crypt-990725.tar.gz This is a complete rewrite of my previous code, based on suggestions from several people. Here is a summary of what the new crypt library does: * Plug-in crypt() modules - new hash algorithms can be compiled and installed on-the-fly without recompiling libcrypt or your applications (currently only works for shared library). * Available modules are listed in /etc/crypt.conf and hashed into /etc/crypt.db using crypt_mkdb(8). The reason for the separate database is that information internal to the module needs to be picked up (namely the algorithm's magic number) and I don't think it appropriate that the system administrator should have to know this. Besides, using a database is more efficient than parsing the config file. * Two login capabilities, localcipher and localcipherrounds are available in /etc/login.conf to specify the password hash (from /etc/crypt.conf) to use for users in that class. localcipherrounds is an algorithm-specific parameter used for specifying the number of encryption rounds to perform in generating the hash. * crypt() understands the traditional DES and MD5 password formats internally (i.e. without using external modules). This should make it fully backwards- compatible with existing password files. * The default format ("modular crypt format", MCF) for password hashes is: $Magic$Rounds$Salt$Hash "Magic" is a 24-bit base-64 encoded random number which is unique to each hash algorithm. This provides statistical collision protection against third-party vendors providing their own hash modules or developing their own algorithms. Using a magic number obfuscates the password hash somewhat, but it's much more robust than using an ordinal or string identifier (e.g. "md5"). "Rounds" specifies the number of encryption rounds to use. The meaning of the number is algorithm-dependent; e.g., blowfish passwords have rounds = log_2 #encryption rounds. For fixed-cost algorithms like the current MD5 hash, this is null. "Salt" is a random base-64 encoded salt. "Hash" is the hashed password. * A new function, char *generate_salt(char *salt, const char *cipher, long rounds); has been added to libcrypt for the purposes of generating a valid salt which can be passed to crypt(). There are at least two places in the base OS which need to generate new salts; passwd(1) and the pam_unix PAM module, and possibly others. * Currently modules for the MCF versions of MD5, and SHA-1 are provided, as well as openbsd-style Blowfish passwords. Windows NT-style hashes and Secure Remote Password (SRP) hashes are also planned. The SHA-1 hash is only provided as a proof of concept - there is probably little reason to migrate to it at this point, as the current MD5 algorithm is convoluted enough that it's likely to be secure even against (as yet unknown) serious MD5 weaknesses. This is alpha-level code and is still in need of some cleanups and added functionality (in particular, static binaries need to be able to use plug-in modules, probably by fork()ing in the library and calling an external helper binary module). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9907250308340.95389-100000>