Hi Jesse,
and anyone else who is interested...
JN> So - by linking libcrypto instead of libcrypt, that function
reverse - lcrypt instead of lcrypto
Only lcrypt supports automatic salt recognition so to say and can
handle md5 hashes. This way you can always mix different types of
passwords, because if you feed the crypt function a MD5 salt it makes
a MD5 hash and if you feed it with a crypt salt it will output a DES
encrypted string. Explanation comes later, first I should say that I
think I have already used both crypt and md5 hashes in one table
without any problem due to the automatic recognition of the salt. So
in my patch md5 is mostly used for clearness in my own tables so I can
always find easy where I have old unsecure crypt passwords. I am quite
certain that if you use crypt in your table and the source is compiled
with lcrypt it will work with md5 hashes. Not sure if the current code
support it in the way it is written, but I will check it later.
For the adduser and Postgre - yes, it can be done quite easy I
suppose. I am not familiar with PGSQL but there should be no problem.
As for the dbmail-adduser - i use it only for fast checks when I am on
the console and use php scripts to insert users in the dbmail
database. There I also use the crypt() php function.
So here is the explanation...
This is from the crypt manual:
With DES salt is a two-character string chosen from the set [a-zA-Z0-9./].
This string is used to perturb the algorithm in one of 4096 different
ways.
So you see that the DES encypted password in fact contains the
password so it can be reversed. With the MD5 things are different:
GNU EXTENSION
The glibc2 version of this function has the following additional
features. If salt is a character string
starting with the three characters "$1$" followed by at most eight
characters, and optionally terminated
by "$", then instead of using the DES machine, the glibc crypt function
uses an MD5-based algorithm, and
outputs up to 34 bytes, namely "$1$<string>$", where "<string>" stands
for the up to 8 characters follow-
ing "$1$" in the salt, followed by 22 bytes chosen from the set
[a-zA-Z0-9./]. The entire key is signif-
icant here (instead of only the first 8 bytes).
Programs using this function must be linked with -lcrypt.
And the MD5 manual states:
MD2, MD4, and MD5 are recommended only for compatibility with existing
applications. In new applications,
SHA-1 or RIPEMD-160 should be preferred.
RFC1321 says:
The MD5 algorithm is intended for digital signature applications, where a
large file must be "compressed" in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem
such as RSA.
Passwords are not even mentioned here. So if you want to have
compatibility and use md5 for passwords, use crypt. This also applies
for php, where you can check the crypt() function which is an analog
for the glibc2 function.
Best regards,
Bobby
[EMAIL PROTECTED]
on Monday, February 24, 2003, 10:16:43 PM, Jesse Norell wrote:
JN> Hello Boyan,
JN> Right off, let me assure you I'm not terribly familiar with
JN> cryptography, especially from programming api's, etc., so after
JN> looking over your patch, I need an explanation. :) I agree
JN> with you about choosing sensible and IC&S-approved values for
JN> encryption_type, and will be happy to re-write our stuff if it
JN> needs done. Now for my explanation: it looks like your patch
JN> still uses crypt(passwd,salt) for the authentication, in:
JN> strcpy(cryptres, (char *) crypt(password, cryptpass));
JN> So - by linking libcrypto instead of libcrypt, that function
JN> automagically handles md5 hashes? If that is the case, does
JN> that make using mixed 'md5' and 'crypt' encryption_type's
JN> impossible on the same system, or does the new crypt() know
JN> how to handle both (eg. because the former's salts always start
JN> with $1$)? And if the latter true, is there any real difference
JN> using your patch vs. the distributed code with 'crypt' as the
JN> encryption_type and just save an md5 hash in the passwd, other than
JN> the trace messages (ie. link libcrypto instead of libcrypt)?
JN> Would you want to make your changes to dbauthpgsql.c and add
JN> support for dbmail-adduser to use/create those encryption hashes?
JN> Also, of curiosity, do you know why an md5 checksum would
JN> not be recommended for a password? Aside from dictionary lookup
JN> attacks if you get the hash, is it any less secure than an md5
JN> "hash"? (rfc 1321 says "It is conjectured that it is computationally
JN> infeasible to produce two messages having the same message digest, or
JN> to produce any message having a given prespecified target message
JN> digest.") I was just wondering, because I (erroneously?) thought
JN> we were doing the Right Thing(tm) by using md5 digests to save
JN> password hashes (not to mention that's what you get by calling md5()
JN> in php, perl, mysql and postgres).
JN> Thanks,
JN> Jesse
JN> ---- Original Message ----
JN> From: Boyan Alexiev <dbmail@dbmail.org>
JN> To: Blake <dbmail@dbmail.org>
JN> Subject: [Dbmail] [Dbmail 1.0] MD5 salted hashes patch
JN> Sent: Sat, 22 Feb 2003 02:03:29 +0200
>> Hi Blake,
>>
>> here is the md5 hash patch (hope the diff works :)
>> Let me know if any of you have suggestions/remarks.
>>
>> Best regards,
>> Bobby
>> [EMAIL PROTECTED]
>>
>> on Saturday, February 22, 2003, 1:47:01 AM, Blake wrote:
>> B> Please do post diffs/patches!
>>
>> B> Boyan Alexiev wrote:
>> >> ...
>> >> Just let me know and I will post the code right away.
>> >>
>> >> Best regards,
>> >> Bobby
>> >> [EMAIL PROTECTED]
>> >>
>>
>> B> _______________________________________________
>> B> Dbmail mailing list
>> B> Dbmail@dbmail.org
>> B> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>
JN> -- End Original Message --
JN> --
JN> Jesse Norell
JN> [EMAIL PROTECTED]
JN> _______________________________________________
JN> Dbmail mailing list
JN> Dbmail@dbmail.org
JN> https://mailman.fastxs.nl/mailman/listinfo/dbmail
