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

Paul Warren pdw@xxxxxxxxxxxxx
Fri, 18 May 2001 11:32:31 +0100

On Fri, May 18, 2001 at 10:41:15AM +0100, Chris Lightfoot wrote:
> > 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.

Possibly.  I think that implementing a straight "use the system crypt()"
is a useful thing to do.  It just means that people who don't have smart
crypt()s won't be able to cut and paste directly from /etc/shadow
(assuming that shadow is using something other than system crypt())

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

OK.  The libc info page is the only page I have found that documents
what a valid salt is if you want MD5 passwords.

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

Why?  IMHO, if it starts {crypt} we just chuck it at crypt().

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

Excellent.  I believe this needs to go in:

cgi-bin/setpasswd (or whatever it's called)

I'll do the Perl if you don't beat me to it (I'm pretty busy this w/e)

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

Yes of course - I'm being exceptionally dense.  Excuse: I was writing
that before 9am, and nothing works right before 9am :-)

> In fact, we could use this to remove the separate
> apop_password field, which is not yet used, and replace it
> with {plaintext}....

Even better.