From 2e70e5e9f05362230980f2e1acf0cb76332c241e Mon Sep 17 00:00:00 2001 From: peter Date: Thu, 28 Dec 2000 11:23:01 +0000 Subject: Hindsight is wonderful, but I got cold feet over the crypt(3) default so I am backing it out for now. The problem is that some random program calling crypt() could be passing a DES salt and the crypt(3) library would encrypt it in md5 mode and there would be a password mismatch as a result. I wrote a validater function for the DES code to verify that a salt is valid for DES, but I realized there were too many strange things to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default for /etc/master.passwd, so this is almost academic. It is a big deal for things that have their own crypt(3)-ed password strings (.htaccess, etc etc). Those are the things I do not want to break. My DES salt recognizer basically checked if the salt was either 2 or 13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it would have worked but I have seen way too much crypt() mishandling in the past. --- lib/libcrypt/crypt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'lib/libcrypt') diff --git a/lib/libcrypt/crypt.c b/lib/libcrypt/crypt.c index 989d745..6f2846d 100644 --- a/lib/libcrypt/crypt.c +++ b/lib/libcrypt/crypt.c @@ -42,11 +42,6 @@ static const struct { char *(*const func)(const char *, const char *); const char *const magic; } crypt_types[] = { - { - "md5", - crypt_md5, - "$1$" - }, #ifdef HAS_DES { "des", @@ -55,6 +50,11 @@ static const struct { }, #endif { + "md5", + crypt_md5, + "$1$" + }, + { NULL, NULL } -- cgit v1.1