Justin Heesemann writes:

> i don't now if you are using php or anything like that, but most 
> languages support some kind of crypt() call.

It is debatable what level of entropy is required for the salt when
generating a password for vpopmail use.

If you want maximum security, and already require the use of only
the SSL forms of POP, IMAP and webmail access, and are completely
paranoid that some rogue system user might just somehow find a loophole
that allows access to the MySQL database, then you probably want 
high-entropy salt.  But don't forget to switch off the "plain text
password" feature.

If you have the "plain text password" feature enabled, then you
probably don't run a server belonging to the US military, the CIA
or the NSA.  You probably trust all your system users sufficiently
and/or you are not too worried about passwords being stolen because
you know your users will choose incredibly stupid passwords that
crack can find in a couple of minutes.  Basically, if you have plain
text passwords enabled the entropy of the salt is irrelevant and you
might as well use the same DES-style salt for each password.

Nevertheless, there is a simple way of generating crypted passwords
which just happens to have reasonably high-entropy salt (assuming the
people who wrote certain portions of your flavour of Unix were competent)
which is appropriate in either situation.  Create a system user without 
shell access.  Use passwd to set that user's password.  Copy the crypted
password in /etc/shadow into your MySQL table.  It's relatively painless
to do and guarantees good entropy on the salt if you happen to need it.
You could even automate it with a little perl if you're feeling lazy.

Which reminds me.  I haven't got around to playing with the newer
vpopmails with password generation (the release I'm using does everything
I must have while later releases have bugs in areas that affect the
must-have stuff).  Does it use /dev/random or /dev/urandom if available?
Does it use a sensible method of reducing the 0-255 range that
/dev/random or /dev/urandom or rand() (spit) return into the salt
range or does it do something silly that biases the results?  If Knuth's
descriptions of his algorithms for mapping random bytes to a reduced range
leave you with brain-ache (they do me) then simply discarding any byte
outside the range and getting another one is a reasonable approach with
/dev/random and /dev/urandom.

Paul Allen
Softflare Support

Reply via email to