[Dovecot] How to authenticate against SQL DB with custom-ciphered passwords?
Hello,
I'm about to start developing authentication/password-scheme module for Dovecot. So I would like to get some advice before actually committing to doing things in particular way. Hope somebody will be able to help me :)
For the record, I am currently targeting latest stable Dovecot version 2.2.5.
I have an SQL DB with mail users' authentication data. Passwords are stored either encrypted via system crypt(3) or ciphered with some custom algorithm (think something symmetrical like AES, so passwords can be decrypted into plain form). I want to use this DB as both userdb and passdb backend. The issue, of course, is with ciphered passwords support.
Is it feasible to just implement a new password scheme for ciphered passwords support and still use stock passdb driver in Dovecot for SQL DB access? So that passwords in this scheme would be treated as PLAIN (in a sense that both cleartext and shared secret authentication methods would work).
Provided I implement custom password scheme for ciphered passwords, what is the best way to be capable to perform authentication against both ciphered and encrypted passwords? Ciphered and encrypted passwords are stored in different fields of SQL table (one of them is NULL when the other one is set). a) Do I define two passdb clauses with their own default_pass_scheme (equal to my new scheme or CRYPT for encrypted passwords) and use fallback to effectively check both of them? b) Do I modify SQL query so that it prefixes existing password with correct scheme (I'm not sure this will be easy enough to do)?
Is it mandatory to provide password generation routine for custom password scheme? When it will be used?
Maybe it's better to just implement a plugin that serves as both userdb and passdb driver (in other words a kind of generic authentication module)? What are advantages and disadvantages of each method - custom password scheme + stock SQL driver VS. custom userdb and passdb driver? Fortunately, I already have all the required credentials lookup and verification code. So in any case the question is only in figuring out suitable Dovecot APIs and integrating the existing code.
I have previously implemented similar custom authentication module for Courier-IMAP (Courier-Authlib to be precise) to use the same SQL DB. And I will need to support both IMAP servers for some time. So it is only natural to expect some generic solution to be possible. I'd like to remind that I need to be able to supply either encrypted password or deciphered plain password, or just check against them. Is it possible to do so in a common way? If so, what method should I use? I would expect SASL helping me out here, but AFAIK, both Dovecot and Courier-IMAP can only serve as SASL servers (providing authentication services), not clients.
I obviously care about providing enhanced security, especially against stealing mail passwords. So any additional advice or related guidelines are welcome.
Somewhat unrelated question: what is the best way to test IMAP (and maybe POP3 as well) server performance and compare it to another server? I'm interested in both login performance (the part I will influence) and performance with many mails in mailbox. I heard imaptest is suitable for this task. Are there any recipes or example testing scenarios you might share? ;)
I would be grateful for any insight in these issues. If I chose a wrong mailing list to post to, please feel free to correct me.
Thanks for your time! :)
-- Best regards, Nick
On 26.9.2013, at 10.01, Nicolay Vizovitin vizovitin@gmail.com wrote:
I'm about to start developing authentication/password-scheme module for Dovecot. So I would like to get some advice before actually committing to doing things in particular way. Hope somebody will be able to help me :)
For the record, I am currently targeting latest stable Dovecot version 2.2.5.
I have an SQL DB with mail users' authentication data. Passwords are stored either encrypted via system crypt(3) or ciphered with some custom algorithm (think something symmetrical like AES, so passwords can be decrypted into plain form). I want to use this DB as both userdb and passdb backend. The issue, of course, is with ciphered passwords support.
- Is it feasible to just implement a new password scheme for ciphered passwords support and still use stock passdb driver in Dovecot for SQL DB access?
Plugins can implement new password schemes. http://dovecot.org/patches/password-scheme-lmpass.c is an example, although I'm not sure if it compiles with v2.2.
So that passwords in this scheme would be treated as PLAIN (in a sense that both cleartext and shared secret authentication methods would work).
You could do that in a slightly ugly way by setting password_generate=plain_generate(), so password_scheme_is_alias() returns TRUE for that.
- Provided I implement custom password scheme for ciphered passwords, what is the best way to be capable to perform authentication against both ciphered and encrypted passwords? Ciphered and encrypted passwords are stored in different fields of SQL table (one of them is NULL when the other one is set). a) Do I define two passdb clauses with their own default_pass_scheme (equal to my new scheme or CRYPT for encrypted passwords) and use fallback to effectively check both of them? b) Do I modify SQL query so that it prefixes existing password with correct scheme (I'm not sure this will be easy enough to do)?
By "ciphered" I understand you mean encrypted, and by "encrypted" you mean hashed.. Scheme prefix would work, mysql and postgresql have complex enough string manipulation functions to make this possible I think.
- Is it mandatory to provide password generation routine for custom password scheme? When it will be used?
doveadm pw command would use it for example. But as mentioned, you should set it to plain_generate.
- Maybe it's better to just implement a plugin that serves as both userdb and passdb driver (in other words a kind of generic authentication module)? What are advantages and disadvantages of each method - custom password scheme + stock SQL driver VS. custom userdb and passdb driver? Fortunately, I already have all the required credentials lookup and verification code. So in any case the question is only in figuring out suitable Dovecot APIs and integrating the existing code.
Implementing yet another sql passdb sounds like quite a lot of work.
- Somewhat unrelated question: what is the best way to test IMAP (and maybe POP3 as well) server performance and compare it to another server? I'm interested in both login performance (the part I will influence) and performance with many mails in mailbox. I heard imaptest is suitable for this task. Are there any recipes or example testing scenarios you might share? ;)
There are only bad non-realistic benchmarks available currently. With imaptest you can easily test the login performance though:
imaptest user=test%d.%d - select=0 clients=100
Thanks a lot for your answers!
Unfortunately I didn't have a chance to sit down and implement the thing yet, but after looking through the Dovecot code I have some additional questions. Please see inline below.
On Fri, Sep 27, 2013 at 10:13 PM, Timo Sirainen tss@iki.fi wrote:
On 26.9.2013, at 10.01, Nicolay Vizovitin vizovitin@gmail.com wrote:
I'm about to start developing authentication/password-scheme module for Dovecot. So I would like to get some advice before actually committing to doing things in particular way. Hope somebody will be able to help me :)
For the record, I am currently targeting latest stable Dovecot version 2.2.5.
I have an SQL DB with mail users' authentication data. Passwords are stored either encrypted via system crypt(3) or ciphered with some custom algorithm (think something symmetrical like AES, so passwords can be decrypted into plain form). I want to use this DB as both userdb and passdb backend. The issue, of course, is with ciphered passwords support.
- Is it feasible to just implement a new password scheme for ciphered passwords support and still use stock passdb driver in Dovecot for SQL DB access?
Plugins can implement new password schemes. http://dovecot.org/patches/password-scheme-lmpass.c is an example, although I'm not sure if it compiles with v2.2.
So that passwords in this scheme would be treated as PLAIN (in a sense that both cleartext and shared secret authentication methods would work).
You could do that in a slightly ugly way by setting password_generate=plain_generate(), so password_scheme_is_alias() returns TRUE for that.
OK, I figured I had to use something like that. However, after looking through the code I don't think it'll work with shared-secret authentication mechanisms. Looking at struct password_scheme definition:
int (*password_verify)(const char *plaintext, const char *user,
const unsigned char *raw_password, size_tsize, const char **error_r); void (*password_generate)(const char *plaintext, const char *user, const unsigned char **raw_password_r, size_t *size_r);
password_generate would have to be equal to plain_generate(). So I'm left with password_verify, but its signature implies that it is called only when plaintext password is available from client, which is not the case with shared-secret mechanisms.
A simple question to verify my hypothesis: would PLAIN-TRUNC password scheme work with CRAM-MD5 authentication? My understanding of CRAM-MD5 and what PLAIN-TRUNC does tells me it cannot work even in theory.
Something tells me that I rather need a new password encoding than just a password scheme. Yet there is no way to extend password encodings, as far as I can tell (at least from looking at password_decode()).
So I guess I can't use new password scheme to solve my problem without patching Dovecot, can I?
- Provided I implement custom password scheme for ciphered passwords, what is the best way to be capable to perform authentication against both ciphered and encrypted passwords? Ciphered and encrypted passwords are stored in different fields of SQL table (one of them is NULL when the other one is set). a) Do I define two passdb clauses with their own default_pass_scheme (equal to my new scheme or CRYPT for encrypted passwords) and use fallback to effectively check both of them? b) Do I modify SQL query so that it prefixes existing password with correct scheme (I'm not sure this will be easy enough to do)?
By "ciphered" I understand you mean encrypted, and by "encrypted" you mean hashed.. Scheme prefix would work, mysql and postgresql have complex enough string manipulation functions to make this possible I think.
Well, yes, I meant exactly that. :)
- Is it mandatory to provide password generation routine for custom password scheme? When it will be used?
doveadm pw command would use it for example. But as mentioned, you should set it to plain_generate.
- Maybe it's better to just implement a plugin that serves as both userdb and passdb driver (in other words a kind of generic authentication module)? What are advantages and disadvantages of each method - custom password scheme + stock SQL driver VS. custom userdb and passdb driver? Fortunately, I already have all the required credentials lookup and verification code. So in any case the question is only in figuring out suitable Dovecot APIs and integrating the existing code.
Implementing yet another sql passdb sounds like quite a lot of work.
I guess it is. But I'd rather trade more work now for more maintainability later (if implementing passdb would help). I don't really want to patch Dovecot as future changes may render the patch incompatible. I could invest some time into the patch provided there is a chance it would get merged into upstream. Otherwise I'd rather use my existing code for accessing SQL DB and password verification/lookup and integrate it into passdb code.
BTW, is there anything else passdb/userdb plugin can do other than its direct responsibilities and returning extra userdb fields? In other words, are there any (theoretical) advantages to implementing passdb instead of password scheme?
- Somewhat unrelated question: what is the best way to test IMAP (and maybe POP3 as well) server performance and compare it to another server? I'm interested in both login performance (the part I will influence) and performance with many mails in mailbox. I heard imaptest is suitable for this task. Are there any recipes or example testing scenarios you might share? ;)
There are only bad non-realistic benchmarks available currently. With imaptest you can easily test the login performance though:
imaptest user=test%d.%d - select=0 clients=100
Thanks, will try it out later.
-- Best regards, Nick
participants (2)
-
Nicolay Vizovitin
-
Timo Sirainen