[Vmail-discuss] migrating MD5 hash used in /etc/shadow to vmail-sql

Paul Warren pdw@xxxxxxxxxxxxx
Fri, 18 May 2001 08:59:33 +0100


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.

>        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.

>        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.

>     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

We could of course have MD5 as the default, to maintain compatibility
with existing vmail users.

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.
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...

Paul