[Dovecot] sha-512 ... shadow blended with database
The cryptic subject is the outcome of my looking into how to do a particular thing. I wonder if anyone else has solved this problem in a way that hasn't occurred to me.
I'm using dovecot 1.1.11 on Ubuntu Server 9.10. I could consider upgrading to my own install of a newer dovecot if it made a difference to this problem.
I have two populations of dovecot users. Some users have Unix accounts
(with logins disabled), and so their password hashes are stored in
/etc/shadow. These days, the default configuration for that is salted
SHA-512. It's easy for me to change that scheme to something else if I
want to, but the important fact is that I already have some users with
passwords in salted SHA-512. The other population of users is purely
virtual, and their password hashes are stored in a MySQL database in
SHA-1 format (unsalted, but moving to salted wouldn't be a big deal).
The database also has a column identifying the hash scheme, so SHA-1
isn't some assumption.
I know that I have have multiple passdb in my dovecot config, but I'm looking to unify my two user populations and put them all in the MySQL database. As far as I can tell from the wiki, there is no SHA-512 in any version of dovecot. MySQL also doesn't have SHA-512. So, I don't see a way of reworking my password checking to accomodate the salted SHA-512 values currently in /etc/shadow. I'd prefer to not ask the SHA-512 users to update their passwords for this administrative reason if I can avoid it (but so far, that looks like the only answer).
Any ideas?
On 30.1.2010, at 22.39, WJCarpenter wrote:
I have two populations of dovecot users. Some users have Unix accounts (with logins disabled), and so their password hashes are stored in /etc/shadow. These days, the default configuration for that is salted SHA-512. It's easy for me to change that scheme to something else if I want to, but the important fact is that I already have some users with passwords in salted SHA-512. The other population of users is purely virtual, and their password hashes are stored in a MySQL database in SHA-1 format (unsalted, but moving to salted wouldn't be a big deal). The database also has a column identifying the hash scheme, so SHA-1 isn't some assumption.
By salted SHA-512 do you mean the $6$salt$sha format that glibc uses? If so, you can use CRYPT scheme, which causes Dovecot to use crypt() function. Then assuming you're using new enough glibc, it understands it.
I have two populations of dovecot users. Some users have Unix accounts (with logins disabled), and so their password hashes are stored in /etc/shadow. These days, the default configuration for that is salted SHA-512. It's easy for me to change that scheme to something else if I want to, but the important fact is that I already have some users with passwords in salted SHA-512. The other population of users is purely virtual, and their password hashes are stored in a MySQL database in SHA-1 format (unsalted, but moving to salted wouldn't be a big deal). The database also has a column identifying the hash scheme, so SHA-1 isn't some assumption.
By salted SHA-512 do you mean the $6$salt$sha format that glibc uses? If so, you can use CRYPT scheme, which causes Dovecot to use crypt() function. Then assuming you're using new enough glibc, it understands it.
Ah, I didn't realize that. Yes, that's exactly what I meant, and the glibc will be on an identically-configured system to the one where the $6$ shadow entries were created. Thanks for the info.
participants (3)
-
Spyros Tsiolis
-
Timo Sirainen
-
WJCarpenter