[Vmail-discuss] migrating MD5 hash used in /etc/shadow to vmail-sql
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
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
True, but as above, you'll be able to use the crypt() function, so it's
> 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:
and anything produced by crypt() is stored as:
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...