SASL w/ Encrypted SQL Password Security (Comment, Suggestion and Possible Solution)
Raymond T. Sundland
raymond at sundland.com
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.
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
> 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