[courier-users] password hashing with courier + mysql

[Joseph C. Lininger]

Hello all,
This topic may have been discussed before, but I can't find a solution
via google or by searching through list archives. Perhaps one of you can
help me.

I'm using Courier MTA with mysql as the authentication back-end. As of
now, the passwords are hashed using the older DES based algorithm.
However, my crypt (3) implementation supports md5, as well as sha256 or
sha512 hashes. I'd like the passwords to be hashed using one of these
methods. In particular, if a user sets his password via sqwebmail I'd
like one of these newer hashing methods to be used. Is there a way to
make this happen? If not, can someone suggest alternatives such as
pointing me to where in the source code I'd need to look to modify this
behavior? Thank you in advance for your help.
- --
Those of you who think they know everything are very annoying to those
of us who actually do.
Joseph C. Lininger, <***@pcdesk.net>

[Sam Varshavchik]

Post by Joseph C. Lininger
I'm using Courier MTA with mysql as the authentication back-end. As of
now, the passwords are hashed using the older DES based algorithm.
However, my crypt (3) implementation supports md5, as well as sha256 or
sha512 hashes. I'd like the passwords to be hashed using one of these
methods.

You'll need to manually set a password encoded using one of the supported
hash function. When changing a password, Courier will use the same hash
function as the existing password.

[Joseph C. Lininger]

Sam,

You'll need to manually set a password encoded using one of the supported hash function.
When changing a password, Courier will use the same hash function as the existing
password.

I got it to work with the MD5 hashing method by manually setting a
password. However, if I try using the SHA512 hash, the one I'd really
prefer to use, it will authenticate fine with the password. However, if
I change it in sqwebmail, then it reverts to the DES based algorithm. I
get a hash string in the form {CRYPT}<DES hash>. Is this a Courier
thing, something with my setup, or a me thing?

To let you know what I did, I first used the encrypt function in mysql
to set the password on an account. I passed $6$ followed by 8 random
characters and the $ character as the salt argument to that function.
Then I checked the string in the table. Fine so far.

Then I set the password in sqwebmail and then checked it again in mysql.
Now is when the reverting back to DES based algorithm happened.

If I must use the MD5 based algorithm I will. But I'd really prefer
SHA256 or SHA512 if it can be done. Please advise?
- --
Those of you who think they know everything are very annoying to those
of us who actually do.
Joseph C. Lininger, <***@pcdesk.net>

[Sam Varshavchik]

Post by Joseph C. Lininger
I got it to work with the MD5 hashing method by manually setting a
password. However, if I try using the SHA512 hash, the one I'd really
prefer to use, it will authenticate fine with the password. However, if
I change it in sqwebmail, then it reverts to the DES based algorithm. I
get a hash string in the form {CRYPT}<DES hash>. Is this a Courier
thing, something with my setup, or a me thing?
To let you know what I did, I first used the encrypt function in mysql
to set the password on an account. I passed $6$ followed by 8 random
characters and the $ character as the salt argument to that function.
Then I checked the string in the table. Fine so far.

Courier does not support this particular password encryption function. I'm
not sure're how you're even able to validate such a password. The only way
this might work is if you're using PAM to authenticate, with your PAM
library implementing support for this encryption method. However were this
to be the case, you should also be using PAM to set the password, via a
scripted expect session:
http://www.courier-mta.org/authlib/README_authlib.html#pwchange

This would also use your system PAM library to actually update your
password, which presumably would implement your encryption function.

So, I can't give you any more pointers since you did not adequately
described your configuration. All I can tell you is that Courier recognizes
$1${salt}$password, an MD5-based salted hashing (not a straight MD5 hash,
btw); {MD5}password, a base64-encoded straight MD5 hash; {MD5RAW}password, a
hexadecimal-encoded straight MD5 hash, {SHA}password, {SHA256}password and
{SHA512}password, a base64-encoded straight SHAx hash, {SSHA}password, a
base64-encoded salted SSHA1 hash method, and the legacy DES-based passwords.

[Joseph C. Lininger]

Sam,

Post by Sam Varshavchik
Courier does not support this particular password encryption function.

I'm not sure're

Post by Sam Varshavchik
how you're even able to validate such a password. The only way this

might work is

Post by Sam Varshavchik
if you're using PAM to authenticate, with your PAM library

implementing support

Post by Sam Varshavchik
for this encryption method. However were this to be the case, you

should also be
I am not using pam for authentication in Courier. I'm using authmysql.
Probably the reason authentication works was pure luck, the way Courier
makes the crypt (3) call. The SHA512 based password hashing in my
implementation is compatible to an extent with the MD5 based algorithm
in wider circulation. Depending on exactly how Courier reads the
password string and processes it through crypt (3) it could likely work
without you ever intending for it to have done. Having it carry over to
password changes, now, that requires some handling. I'd be willing to
make the modifications and submit a patch if you'd be willing to point
me to a starting point in the code. I could find it myself, but as the
author if you told me where to look you'd shave a lot of time off the
analysis and modification time. I'll probably go ahead and make the
modifications and at least make the capability available through a
private patch even if you aren't interested in having it in the mainline
Courier distribution because I and some people I work with have a use
for it. If you want to use it though, I'll do the work to add it and
give it to you in the form of a patch.
- --
Those of you who think they know everything are very annoying to those
of us who actually do.
Joseph C. Lininger, <***@pcdesk.net>

[Sam Varshavchik]

Post by Joseph C. Lininger
I am not using pam for authentication in Courier. I'm using authmysql.
Probably the reason authentication works was pure luck, the way Courier
makes the crypt (3) call. The SHA512 based password hashing in my
implementation is compatible to an extent with the MD5 based algorithm
in wider circulation. Depending on exactly how Courier reads the
password string and processes it through crypt (3) it could likely work
without you ever intending for it to have done. Having it carry over to
password changes, now, that requires some handling. I'd be willing to
make the modifications and submit a patch if you'd be willing to point
me to a starting point in the code. I could find it myself, but as the
author if you told me where to look you'd shave a lot of time off the
analysis and modification time. I'll probably go ahead and make the
modifications and at least make the capability available through a
private patch even if you aren't interested in having it in the mainline
Courier distribution because I and some people I work with have a use
for it. If you want to use it though, I'll do the work to add it and
give it to you in the form of a patch.

The problem is that Courier does not use crypt() to validate "$1$" formatted
passwords. It essentially reimplements the entire algorithm that computes
this hash. Except for the original crypt passwords, all hash functions are
implemented natively in Courier. At the time of the original implementation,
crypt() only did the crypt method, the new salted md5 passwords were