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
