diff options
author | peter <peter@FreeBSD.org> | 2000-12-28 11:23:01 +0000 |
---|---|---|
committer | peter <peter@FreeBSD.org> | 2000-12-28 11:23:01 +0000 |
commit | 2e70e5e9f05362230980f2e1acf0cb76332c241e (patch) | |
tree | 315074f6e51340bed8f7e625e9b6b5dc1c60e6b3 /lib/libcrypt | |
parent | 117ae0dab37bc1cc35a0315ff2df8e77e35977e1 (diff) | |
download | FreeBSD-src-2e70e5e9f05362230980f2e1acf0cb76332c241e.zip FreeBSD-src-2e70e5e9f05362230980f2e1acf0cb76332c241e.tar.gz |
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.
Diffstat (limited to 'lib/libcrypt')
-rw-r--r-- | lib/libcrypt/crypt.c | 10 |
1 files changed, 5 insertions, 5 deletions
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 } |