I'd even consider modifying the random password generator to not use letters that can be confused with each other (1/I/l and 0/O).
That'd be foolish in the extreme. If the user, or administrator, wants passwords that are "easy to remember" or "hard to confuse" then they should take the onerous burden on themselves. The random password function, by using the word random, is promising a certain functionality and what you propose doesn't deliver it.
I think that's somewhat extreme. A random password is just that -- randomly generated. No guarantees on the "randomness" of the random number generator, or on the number of characters selected from. Eliminating 5 characters from a possible 70-80 is not foolish. Having admins set up new accounts with passwords like "PASSWORD" or the user's last name is foolish.
Narrowing the possible scope for each letter to 64 from some larger group but increasing the entropy that goes into selecting each character seems like a good idea to me.
Remember that we're only selecting 8 random characters -- that's about 40-bits of random numbers. No one has shown that the current method results in a limited set of possible passwords. I'm not arguing against using /dev/[u]random, I'm just saying that it's possible to over-engineer a random password generator...
The valid salt chars for DES, with which we must maintain backwards compatability, are [a-zA-Z0-9./]. The additional characters that vgen_pass() can be using are [EMAIL PROTECTED]&*()-_=+\|]}[{"';:><, by my count that's 29 new characters. A decently larger set, but not substantially so.
This means that an 8 character password, which is what gets created when vpopmail creates a random password for you, can be one of either 6.27710173538668e+57 or 9.71334446112865e+83 combinations, depending on how many characters you allow. I personally think we should lean towards higher entropy within a smaller field rather than dramatically lower entropy within a somewhat larger field.
I'm not sure how to measure entropy, but with the small number of bits we're looking at, you reach a point where additional entropy gains you nothing, whereas additional characters to choose from does.
I do not, however, have any evidence to back this up at the moment. If you'd like me to back the above up, or withdraw it, based on an actual expert opinion I'd be more than happy to do some research this evening to see what the "pro's" say.
I'm not an encryption expert, so I'm open to professional opinions on the subject.
We could also increase the size of the MD5 salt, since we're allowed 8 characters plus the leading $1$ and an optional, terminating $. This'd be easy to do, backwards compatible, and ought to increase security to at least some extent.
The more recent versions of vpopmail use the full-size salt.
Also, randltr is relying on something else to seed srand, which is really a bad idea. One mistake and suddenly everyone's vpopmail everywhere is seeding with 1. Oops.
randltr is only used by mkpasswd3() which seeds srandom. You need to be careful to seed rand/random only once.
There's no real reason that I can determine, from either the man pages, my experience, or the experience of the people around me that says you need to be careful to seed the random pool only once. It doesn't break anything. At worst its inefficient.
If you seed it repeatedly with the same value (for example, based on time() and pid) then you reset the random number generator and get repeated results.
If you are so terribly worried you can waste 1 byte of memory with a flag indicating that srand has been called and thus not do it again. Since you've not yet done that, but instead relied on nobody calling mkpasswd3() AND vgen_pass() in a series, I'm guessing you weren't that worried.
You're right, I only use local flags for each routine. Making a global flag would be better.
I agree that we should use /dev/urandom (or /dev/random) if available. The code should read in enough bytes to generate an entire salt or random password (however the case may be). I'm willing to explore adding this to the next development cycle. Right now, I want to get a 5.3.30 release done (and maybe even call it 5.4.0-pre1) so we can have a stable release for people who've been waiting to upgrade from 5.2.2.
A stable release would be a Good Thing. I'm one of those people waiting to upgrade, however I'd consider this a fairly serious, albeit still theoretical, bug in the password generating and hashing functions.
I disagree. I made improvements on the code because I ran into an instance where vadduser could generate the same random password when called twice in a row. Adding configure options to detect the presence of /dev/random or /dev/urandom and modifying the code to use either is not a simple change.
After we release 5.4.0, we can introduce the new code into the 5.5 series, and then back-port it to 5.4 once it's been tested.
I'll still say that I think this is overkill. I find it extremely unlikely that someone could determine the random password generated by vpopmail.
People found it extremely unlikely that anyone could brute force DES crypted passwords for a long time. Then someone did it and everyone moved to MD5. Remember, the crypted password used to be kept in /etc/passwd, which was world readable, since no one worried about it.
Shrugging off easily fixable bugs as theoretical keeps getting people into trouble, and yet everyone keeps trying to shrug them off. Even worse, shrugging them off publicly seems to invite people to prove you wrong.
As far as I'm concerned, when it comes to security the line between enough and overkill is very very blurry. I usually draw it when something is "measurably" secure AND the workload to continue making it more secure begins going up dramatically. In this case I just don't see the workload going up by very much, but the level of security would seem to be going up dramatically.
It's generally better to analyze the situation instead of just going by gut instinct. For someone to guess a user's randomly generated password, he needs to know the following:
1) The time that the password was generated (about 16 bits per day, add 1 bit per day to search).
2) The pid of the process that generated it (16 bits).
3) The number of characters (not a big deal -- just try any number from 4-12).
Given that information, and the source to vpopmail, they could start brute-force guessing passwords by initializing srand() with one of the possible values. A potentially small dataset, yet still one that would require trying, on average, at least 2 billion possible passwords (if you knew the day the password was generated).
Making use of /dev/urandom and/or /dev/random will be high on our priority list for the 5.5 development series.
-- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
