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 wrote:
> On 26.9.2013, at 10.01, Nicolay Vizovitin 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.
> >
> > 1) 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_t
size,
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?
> > 2) 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. :)
> > 3) 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.
>
> > 4) 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
