Nick Harring writes:
> This isn't actually true. Mysql provides an encrypt() function, which
> takes two strings, the password and the salt.
You learn something every day. I'd not enountered that function before.
> On linux, and I would guess *BSD as well, when you supply $1$ as the
> start of the salt then an md5 crypt, same as in /etc/shadow, is
The problem then is providing good salt. Since MySQL's rand() appears
to call the system rand(), this is not good salt. Quite probably good
enough for many purposes, but not good enough if you want serious
security (and you wouldn't be using the MD5 crypt unless you did). OTOH,
I bet vpopmail also uses rand().
Ummm, some quick digging later and the situation is worse than I thought.
Not only does vpopmail use rand(), it initializes srand with a variant
of time(NULL) ^ getpid(). time(NULL) ^ getpid() has long been known to
not be a good way of seeding the random number generator. I think the
variant vpopmail uses is actually likely to make it quite a bit worse.
If nothing else, I'd suggest replacing the rand() % time(NULL) ^ getpid()
with time(NULL) ^ (getpid() + (getpid() << 15)) as recommended by Larry
Wall. At best, I would attempt to determine if /dev/urandom exists
(either at configuration time or at run time) and use that if possible,
reverting to the Wall function if /dev/urandom is not available.
> Wrong, and sometimes also wrong. There may be very legitimate reasons,
> technical or political, for not allowing scripts to execute shell
> commands on a mail system.
There may be technical or political reasons, but he did not say that
there were. And, in fact, it turns out that there were not.
> There may be integration reasons why only DB queries can be performed,
> instead of invoking a cgi or doing an ssh and executing a script.
There may be, but in this case there were not.