[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)