SASL w/ Encrypted SQL Password Security (Comment, Suggestion and Possible Solution)

Raymond T. Sundland raymond at
Tue Jan 25 13:52:42 EST 2011

Thanks for the explanation.  Though, I would prefer something better
than MD5 since it has been broken for years.

As for my "hack", it doesn't work because I mis-read what %p was,
thinking it was the password, not the column to look for... so back to
the drawing board.  I will look at using something like kerberos, but it
seems like an awful lot of work given my installation requirements.  I'm
up for the challenge, nonetheless.

Thanks again.

On 1/25/2011 1:08 PM, Dan White wrote:
> On 25/01/11 12:48 -0500, Raymond T. Sundland wrote:
>>    So given that it's been at least 6 years since it's been common
>>    security practice to not store cleartext passwords in a database, why
>>    does SASL still require it?  Can't SASL be modified to accept
>>    some token from the SQL query that basically says, "yes the password
>>    you gave me matches" ??
> SASL provides saslauthd for simple password verification against hashes,
> which you could use along with a SQL PAM module to authenticate against
> Postgres (sasl_pwcheck_method: saslauthd, with a '-a pam' passed to
> saslauthd).
> Access to passwords stored in the clear (using an auxprop module) is
> really only necessary if you're using shared secret authentication
> mechanisms, such as DIGEST-MD5.
> With that said, there appears to be a patch within 2.1.24rc1 which would
> allow you to store your passwords md5 hashed, and configure
> 'sasl_pwcheck_method: auxprop-hashed' to do what you want (but without
> shared secret functionality).

More information about the Info-cyrus mailing list