[Vmail-discuss] migrating MD5 hash used in /etc/shadow to vmail-sql
Chris Lightfoot
chris@xxxxxxxxxxxxx
Fri, 18 May 2001 10:41:15 +0100
On Fri, May 18, 2001 at 08:59:33AM +0100, Paul Warren wrote:
> On Fri, May 18, 2001 at 01:54:54AM +0100, Chris Lightfoot wrote:
> > On Thu, May 17, 2001 at 04:57:38PM -0400, Marcin Pacyna wrote:
> > > In short - does anyone know how can I migrate/convert all the hashes from
> > > /etc/shadow to something that tpop3d understands?
> >
> > 2. Modify tpop3d and vmail-sql to implement the
> > crypt-md5 algorithm.
> >
> > mysql_crypt.patch in the distribution would
> > probably serve as a starting point;
>
> Indeed, although it doesn't patch cleanly ATM.
OK. That's not surprising, though I didn't know about it
:)
> > you'll also
> > need to link against crypt_md5 from the PAM
> > distribution.
>
> Actually, later versions of glibc have "smart" crypt()s, which if salted
> with a string of the form "$1$xxxxx$" (check the info page for how many
> x's you need) will generate MD5 passwords, as used in shadow.
Yeah, but this won't be available on the non-Linux systems
on which tpop3d runs, so I think including crypt_md5 in
the distribution is probably a good bet.
> > You'll also need to implement a perl
> > version of this to make the vmail-sql admin scripts
> > work.
>
> True, but as above, you'll be able to use the crypt() function, so it's
> pretty straightforward.
Well.... I'll do a straight perl one anyway.
> > 3. Modify tpop3d to migrate the passwords (with a
> > little bit of help).
>
> I don't really see the need to migrate - there is nothing actually wrong
> with the password hashes produced by crypt(). I understand that LDAP
> users have a similar problem. The way I would like to see this fixed is
> consistent with LDAP whereby straight MD5 hex hashes are stored as:
>
> {md5}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> and anything produced by crypt() is stored as:
>
> {crypt}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
... with the proviso that on non-Linux systems we'll need
to look for {crypt}$1$...$.
> We could of course have MD5 as the default, to maintain compatibility
> with existing vmail users.
Yeah.
> I think that the above constitutes useful functionality - the ability to
> cut and paste passwords from /etc/passwd or /etc/shadow is a Good Thing.
Yes-- I agree, this is a good idea, and I will implement
it.
> I intend to implement this in the Perl scripts. To implement this in
> the C is going to requiring replacing one SELECT with two, because we
> need to some smart processing of the hash, but I don't think that two
> SELECTs is criminal...
No, you don't need two SELECTs. You do something like
SELECT domain.path, popbox.mbox_name, domain.unix_user, popbox.password
FROM popbox, domain
WHERE popbox.local_part = $local_part
AND popbox.domain_name = $domain
AND popbox.domain_name = domain.domain_name
... then you compare the passwords you've retrieved, as in
the APOP authenticator.
In fact, we could use this to remove the separate
apop_password field, which is not yet used, and replace it
with {plaintext}....
--
Chris Lightfoot -- www.ex-parrot.com/~chris/
``Unacknowledged poets are the legislators of the world.''
(quoted from New Statesman by A. Monkhouse, 1933)