[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:
tpop3d
VE-passwd
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.
Paul