Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hejsa, On Fri, 2003-11-07 at 00:21, Tom Collins wrote: 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... Let's calculate some randomness :) (8 characters from a 128 letter pool: 56 bits) 8 characters from a 80 letter pool: 50 bits 8 characters from a 64 letter pool: 48 bits I'll say it's an acceptable loss eliminating those letters that can easily be confused... Making use of /dev/urandom and/or /dev/random will be high on our priority list for the 5.5 development series. You wan't patches? That would be a nice project for little me... /Anders
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
On Friday, November 7, 2003, at 06:54 PM, Anders Brander wrote: Making use of /dev/urandom and/or /dev/random will be high on our priority list for the 5.5 development series. You wan't patches? That would be a nice project for little me... Yep, if you can come up with a patch that checks for the device file and defines a macro in config.h in addition to adding the code. Take a look at how other things work in configure.in to get an idea of how to accomplish that. It should read enough bytes to built a salt or generate a random password (depending on which function is called). I would suggest creating a function in vpopmail to read the random bits into an array of some sort, and have all function that need random data make use of that function. This way, we can keep the random code in one place -- either /dev/[u]random or srand[om]/rand[om]. -- 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/
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
On Tuesday, November 4, 2003, at 05:40 AM, Nick Harring wrote:
Actually, this is already a right place to put this, which is in
randltr. Oddly that's what's used for generating the salt, but not
what's used for generating the password. Instead the password just
uses an ugly rand call.
I'd change vgen_pass to do this:
for (i = 0; i len; i++) {
k = randltr();
p[i] = gen_chars[k];
}
return p;
randltr selects from 64 valid salt characters. The password generator
pulls from a larger selection of possible characters.
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).
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.
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.
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.
--
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/
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Tom Collins wrote:
On Tuesday, November 4, 2003, at 05:40 AM, Nick Harring wrote:
Actually, this is already a right place to put this, which is in
randltr. Oddly that's what's used for generating the salt, but not
what's used for generating the password. Instead the password just
uses an ugly rand call.
I'd change vgen_pass to do this:
for (i = 0; i len; i++) {
k = randltr();
p[i] = gen_chars[k];
}
return p;
randltr selects from 64 valid salt characters. The password generator
pulls from a larger selection of possible characters.
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. 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.
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 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.
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.
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 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.
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'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.
--
Tom Collins - [EMAIL PROTECTED]
Note: The Tom Logic offices will be closed October 23 to November 18.
QmailAdmin: http://qmailadmin.sf.net/
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
On Friday, November 7, 2003, at 02:27 AM, Nick Harring wrote:
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,
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
On Tuesday, October 28, 2003, at 02:42 AM, Paul L. Allen wrote: 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. For generating a salt, I think we're fine with the following initialization: srandom (time(NULL)^(getpid()15)); I think it would be extremely difficult to predict the salt of a generated password, and even if it was possible, it doesn't really matter. Knowing a password's salt but not the encrypted password doesn't help you to crack it. Once you have the encrypted password, you get the salt. If you were trying to guess a randomly generated password, it might be possible to use the salt to determine the starting seed to srand and then determine the password used. If you knew a process ID range and time range for when the password was generated, you could try thousands, if not millions of seeds to find one that generates the salt. At that point, you could continue the password generating routine to determine what the random password was. -- 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/
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Tom Collins wrote: On Tuesday, October 28, 2003, at 02:42 AM, Paul L. Allen wrote: 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. For generating a salt, I think we're fine with the following initialization: srandom (time(NULL)^(getpid()15)); I think it would be extremely difficult to predict the salt of a generated password, and even if it was possible, it doesn't really matter. Knowing a password's salt but not the encrypted password doesn't help you to crack it. Once you have the encrypted password, you get the salt. If you were trying to guess a randomly generated password, it might be possible to use the salt to determine the starting seed to srand and then determine the password used. If you knew a process ID range and time range for when the password was generated, you could try thousands, if not millions of seeds to find one that generates the salt. At that point, you could continue the password generating routine to determine what the random password was. -- 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/ While I would tend to agree that that might be good enough, I would also say that if its feasible it'd be much better to check for /dev/(u)random at compile time and if present then use that. I wouldn't bother changing the existing seeding function for rand, as long as the only thing its being used for is salt generation. The salt isn't really a route to attacking the password since you don't need it to brute force the password if you can get the encrypted password string, and having it doesn't allow you to go backwards from the string. All it does is lower the brute force workload by a certain amount, which I can't remember and can't quickly find on google. I would think just wrapping the srandom seeding in #ifdef's and adding a check in configure would work, and I'm working up a patch to do the first bit, though I know zero about configure/autoconf and thus can't help there. I'll submit via sourceforge once I get it working and non-ugly. Cheers, Nick Harring Webley Systems
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
I'm going to try to answer both you and Tom at the same time. One of the few times I didn't bother checking mail at least once after finishing on Friday night and I have over 300 waiting for me on Monday morning. Nick Harring writes: Tom Collins wrote: For generating a salt, I think we're fine with the following initialization: srandom (time(NULL)^(getpid()15)); Better than what you have, but I suspect that if Larry Wall came up with the solution I quoted he'd given it a lot of thought and rejected simpler solutions for valid reasons. I think it would be extremely difficult to predict the salt of a generated password, and even if it was possible, it doesn't really matter. Not if you store cleartext passwords too, that's for sure. Knowing a password's salt but not the encrypted password doesn't help you to crack it. If you can get the password file somehow, you get both the salt and the crypted password. And you're right that if somehow you have only the salt, or can predict it, it doesn't help you crack the password. But I am thinking of the case where the password file is (somehow) stolen and does not have cleartext passwords. If the random seeding process restricts the range of salt greatly, then a precomputed attack becomes more feasible. After all, it is the relatively small salt size and the abiliity of computers of a few years ago to mount precomputed attacks that led to modern unices replacing the old DES crypt with an MD5-based one which had much larger salt.. If you were trying to guess a randomly generated password, That's the other problem. If the random password generation in vpopmail uses the same seed method, the password space may be a lot smaller than we would like to think. If you knew a process ID range and time range for when the password was generated, you could try thousands, if not millions of seeds to find one that generates the salt. At that point, you could continue the password generating routine to determine what the random password was. You don't need to compare the salt to see if it's right, you just guess the initial seed and go through the same process that vpopmail does - either you get the right password or you don't. If you have an idea of the time you may find that the current seed generation drastically limits the seed space even if you have to take random guesses at the PID. My gut feeling is that the method currently used does reduce the seed space (but I'm not mathematical enough to prove it). Remember that rand() is entirely predictable if you know the starting seed, so no matter how many characters in the randomly-generated password, the actual entropy is no larger than 32 bits (the range of the initial seed) and possibly a good deal lower if the seed generation is locked into a small subset of that. With /dev/urandom you get a good deal more entropy for password generation and for MD5 salt. While I would tend to agree that that might be good enough, I would also say that if its feasible it'd be much better to check for /dev/(u)random at compile time and if present then use that. It's extra coding. :( But I think i's worthwhile. I wouldn't bother changing the existing seeding function for rand, as long as the only thing its being used for is salt generation. If I read Tom's reply correctly, it's also used for randomly-generated passwords. The salt isn't really a route to attacking the password See above. If somebody can read the password file, the entropy of the salt is all that makes a precomputed attack infeasible. In some organizations, it is considered important to guard against that even if the fact is that if somebody can get the password file you probably have a lot more to worry about than that. If you use an off-site backup facility run by another company, how do you know that somebody there won't go through your backups and get the password files and then send a mail in one of your user's names that costs you a lot of money? All it does is lower the brute force workload by a certain amount, Brute force is not the only attack. Precomputed attacks can be very effective if the salt space is small. I would think just wrapping the srandom seeding in #ifdef's and adding a check in configure would work, I would add more #ifdefs to replace the call to rand with a read from /dev/urandom. Using /dev/urandom to seed rand() only gets you 32 bits of entropy (on most architectures). -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Paul L. Allen wrote: I'm going to try to answer both you and Tom at the same time. One of the few times I didn't bother checking mail at least once after finishing on Friday night and I have over 300 waiting for me on Monday morning. Nick Harring writes: Better than what you have, but I suspect that if Larry Wall came up with the solution I quoted he'd given it a lot of thought and rejected simpler solutions for valid reasons. I'd totally agree here. I think it would be extremely difficult to predict the salt of a generated password, and even if it was possible, it doesn't really matter. Not if you store cleartext passwords too, that's for sure. Storing cleartext passwords is generally horrible security, so this and that don't really relate to each other. Yes, I know why people do it, and I do it myself, but I'm not going to kid myself into thinking that a better salting scheme is going to help any when I keep clear passwords around. Knowing a password's salt but not the encrypted password doesn't help you to crack it. If you can get the password file somehow, you get both the salt and the crypted password. And you're right that if somehow you have only the salt, or can predict it, it doesn't help you crack the password. But I am thinking of the case where the password file is (somehow) stolen and does not have cleartext passwords. If the random seeding process restricts the range of salt greatly, then a precomputed attack becomes more feasible. After all, it is the relatively small salt size and the abiliity of computers of a few years ago to mount precomputed attacks that led to modern unices replacing the old DES crypt with an MD5-based one which had much larger salt.. This is true, and the same precomputed attacks become much more feasible (as you correctly point out) when the salt space is dramatically reduced. If you were trying to guess a randomly generated password, That's the other problem. If the random password generation in vpopmail uses the same seed method, the password space may be a lot smaller than we would like to think. I hadn't checked this, but I'm guessing you're right, and this is a hugely serious problem. If you knew a process ID range and time range for when the password was generated, you could try thousands, if not millions of seeds to find one that generates the salt. At that point, you could continue the password generating routine to determine what the random password was. You don't need to compare the salt to see if it's right, you just guess the initial seed and go through the same process that vpopmail does - either you get the right password or you don't. If you have an idea of the time you may find that the current seed generation drastically limits the seed space even if you have to take random guesses at the PID. My gut feeling is that the method currently used does reduce the seed space (but I'm not mathematical enough to prove it). Remember that rand() is entirely predictable if you know the starting seed, so no matter how many characters in the randomly-generated password, the actual entropy is no larger than 32 bits (the range of the initial seed) and possibly a good deal lower if the seed generation is locked into a small subset of that. With /dev/urandom you get a good deal more entropy for password generation and for MD5 salt. While I would tend to agree that that might be "good enough", I would also say that if its feasible it'd be much better to check for /dev/(u)random at compile time and if present then use that. It's extra coding. :( But I think i's worthwhile. I whole heartedly agree. I've been poking around with #ifdef'ing around the seeding of srandom, however I think your later suggestion of just replacing rand() with reads from /dev/urandom is the Right Way. I wouldn't bother changing the existing seeding function for rand, as long as the only thing its being used for is salt generation. If I read Tom's reply correctly, it's also used for randomly-generated passwords. The salt isn't really a route to attacking the password See above. If somebody can read the password file, the entropy of the salt is all that makes a precomputed attack infeasible. In some organizations, it is considered important to guard against that even if the fact is that if somebody can get the password file you probably have a lot more to worry about than that. If you use an off-site backup facility run by another company, how do you know that somebody there won't go through your backups and get the password files and then send a mail in one of your user's names that costs you a lot of money? All it does is lower the brute force workload by a certain amount, Brute force is not the only
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Nick Harring wrote:
This is the Right Thing imho. It might be easier though to move the
srandom()/random() and new reads from /dev/urandom into a function of
its own, rather than replacing them whereever they're sprinkled
through the code. I realize that's even more work, but its probably
more maintainable down the road.
Actually, this is already a right place to put this, which is in
randltr. Oddly that's what's used for generating the salt, but not
what's used for generating the password. Instead the password just uses
an ugly rand call.
I'd change vgen_pass to do this:
for (i = 0; i len; i++) {
k = randltr();
p[i] = gen_chars[k];
}
return p;
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.
I'd like to see a randltr similar to:
char randltr(void)
{
char rand;
char retval = 'a';
#ifdef HAS_URANDOM
int fh;
char entropy[1];
char path[] = /dev/urandom;
fh = open(path,O_RDONLY);
read(fh,*entropy,1);
rand = entropy[1];
#endif
#ifdef NO_URANDOM
srandom(time(NULL) ^ (getpid() + (getpid() 15)));
rand = random() % 64;
if (rand 26) retval = rand + 'a';
if (rand 25) retval = rand - 26 + 'A';
if (rand 51) retval = rand - 52 + '0';
if (rand == 62) retval = ';';
if (rand == 63) retval = '.';
return retval;
}
I strongly discourage using my code verbatim, however I think it conveys
the general idea. Someone who's better with C can certainly fix any
errors and clean it up to fit the general vpopmail style.
Cheers,
Nick Harring
Webley Systems
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Nick Harring writes: Storing cleartext passwords is generally horrible security, so this and that don't really relate to each other. Except to the extent that vpopmail now supports cleartext passwords (I have a vague memory they're needed for CRAM authentication) I whole heartedly agree. I've been poking around with #ifdef'ing around the seeding of srandom, however I think your later suggestion of just replacing rand() with reads from /dev/urandom is the Right Way. It's slightly more efficient not to seed rand if you're not going to use it. Brute force is not the only attack. Precomputed attacks can be very effective if the salt space is small. Precomputed attacks are brute force, I beg to differ. They are force, but not brute force. Brute force is trying random passwords until you succeed. A precomputed attack relies upon the fact that many people choose poor passwords, as does crack. Neither are brute force because they reduce the search space in a semi-intelligent fashion. In fact a precomputed attack is somewhat more intelligent than crack as the computer-intensive part is stored for re-use. Precomputation just reduces the time frame required to run said brute force attack. If you're guessing at each element, without any feedback or algorithm other than trying a list of sequential possibilities, you're brute forcing. Any algorithm that gives you an improvement on purely random guesses can no longer be considered brute force. I would add more #ifdefs to replace the call to rand with a read from /dev/urandom. Using /dev/urandom to seed rand() only gets you 32 bits of entropy (on most architectures). This is the Right Thing imho. Indeed. If you have /dev/urandom available what's the point of using rand at all? Using it to seed rand is slightly better than the seed suggested by Wall but doesn't buy you much extra entropy and never more than 32 bits (on most architectures). -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hello list, I have vpopmail -with-mysql installation. I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Regs, Oliver Etzel
RE: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
However you can just add the user to the database without needing to attach to the shell at all and have vpopmail create the user the first time the user receives an email. Makes a lot of sense when your billing system has been modified to do this for you. Shane -Original Message- From: Paul L. Allen [mailto:[EMAIL PROTECTED] Sent: Monday, 27 October 2003 10:08 PM To: [EMAIL PROTECTED] Subject: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser Why would you not want to use vadduser? BUT with just . With just what? Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Yes, I could tell you how to do that. But creating an entry in MySQL and crypting the password is only part of the process that vadduser (or any of the web admin interfaces like qmailadmin which use the vpopmail libraries) do. It really is easier to use vadduser or link to the appropriate routines in the vpopmail libraries (or use one of the webadmin tools). It is also safer, because if vpopmail changes in the future, vadduser will do whatever is necessary to accommodate that change whereas your method (whatever it is) may not. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hello John, what exactly is the learn password option? Oliver He can also enable the learn password option in vpopmail, I think this would be an easy way to deal with it myself. What do you think? -John - Original Message - From: Paul L. Allen [EMAIL PROTECTED] To: Oliver Etzel - GoodnGo.COM (R) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 6:47 AM Subject: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hello Paul, hello all, Paul: The reason why I do NOT want vadduser or any commandline tool is that I want to write a perl script which automatize user generation. Cool would would be If one could run: vadduser $variable_password or something like this in Perl or PHP code! Regs, Oliver Etzel Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
You can do with with Perl's system or exec calls, and I'm sure that PHP has equivalent calls as well. Just call the binary from your script. Why not use the product as its architected? Sheez! Hello Paul, hello all, Paul: The reason why I do NOT want vadduser or any commandline tool is that I want to write a perl script which automatize user generation. Cool would would be If one could run: vadduser $variable_password or something like this in Perl or PHP code! Regs, Oliver Etzel Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Paul L. Allen wrote:
Oliver Etzel - GoodnGo.COM \(R\) writes:
I want to create new users like [EMAIL PROTECTED] NOT with vadduser
BUT with just inserting it via mysql-insert into the vpopmail
database.
OK, you have now explained what you want to use instead. Somebody else
pointed out that the maildir will be created automatically by vdelivermail
if the user exists (I hadn't realized it did that until I read that
message and looked at the code just now) so you can get away with doing
that. What you have yet to explain is any valid or sensible reason WHY
you want to do this.
Any hints,
how I can generate the encrypted password in the column pw_passwd
(looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ???
Not without breaking out of MySQL and returning to the shell. The
hard way is to get a shell prompt, use passwd to set the password of a
dummy system user then copy the crypted password into the MySQL command.
This isn't actually true. Mysql provides an encrypt() function, which
takes two strings, the password and the salt. 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 performed. This is what I got
on my linux system:
mysql select encrypt("foo", "$1$foo");
+---+
| encrypt("foo", "$1$foo") |
+---+
| $1$foo$cicfbsODeQjKhATDU7z4p. |
+---+
The harder way is to write a perl script that generates some good random
salt, calls crypt to crypt the password then uses the DBD modules to
insert the user into MySQL.
This is, imho, a less than stellar idea, particularly in light of MySQL
providing crypt functions that will work the same as what vpopmail uses
(crypt() btw). For "full" vpopmail compatability the salt must be 8
characters, the first three being $1$ if you're using MD5 passwords,
and ended with 0. The middle 5 are random letters.
An easy way to do it is to add the
user with MySQL giving garbage for the crypted password then use vmoduser
to set a valid crypted password. The very easy way to do it is to run
vadduser.
This all assumes you've got, and wish to use, shell access on the
vpopmail system.
You CANNOT do it all from MySQL. You CAN do it all with vadduser.
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 integration reasons why only DB
queries can be performed, instead of invoking a cgi or doing an ssh and
executing a script.
Hope that helps,
Nick Harring
Webley Systems, Inc.
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
When you run ./configure for vpopmail add this option --enable-learn-passwords=y Vpopmail with learn the passwords when the user pops for mail and that way you will not have to enter a password. -John - Original Message - From: Oliver Etzel - GoodnGo.COM (R) [EMAIL PROTECTED] To: John Johnson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 27, 2003 7:13 AM Subject: Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Hello John, what exactly is the learn password option? Oliver He can also enable the learn password option in vpopmail, I think this would be an easy way to deal with it myself. What do you think? -John - Original Message - From: Paul L. Allen [EMAIL PROTECTED] To: Oliver Etzel - GoodnGo.COM (R) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 6:47 AM Subject: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Well maybe there is another answer to this. maybew he didn't get the reply last time for some reason so he doesn't even know he was given the answer. Sometimes we must have faith that not all people are stupid :) -John - Original Message - From: Paul L. Allen [EMAIL PROTECTED] To: John Johnson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 7:14 AM Subject: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database John Johnson writes: He can also enable the learn password option in vpopmail, I think this would be an easy way to deal with it myself. It's hard to tell since he didn't say why he wanted to do it in the first place. The problems with the learn password option are that there is a window of vulnerability (unlikely to be exploited) and that he may not wish users to choose their own passwords. He may wish to force strong passwords on his users, in which case learn password would be totally unsuitable. As somebody else reminded us, this guy has asked questions avout the password hashing before and received rather comprehensive answers which he apparently either ignored or could not understand. So I have my doubts that any sensible, rational, logical solution will suit him. He appears to be like the guy who locked his keys in his car and spent an hour using a bent coat-hanger inserted down the window seal to jimmy the lock so he could let his family out of the car... -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hello Paul, hello all, Oh my god, that is what I was looking for! Thank you very much. I thought I couldn´t write it all in one commandline, like you Paul showed us. Now I write my perl-script for automation. Thank you ALL. vadduser has always allowed the plaintext password to be specified on the command line as: vadduser email_address password Newer versions can generate a random password with: vadduser -r email_address Both forms can be run from perl using backticks. The random password from the second form can be collected from the backticks in perl. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM (R) writes: Hello Paul, hello all, Oh my god, that is what I was looking for! Also, there is also a PERL-module for vpopmail ! It exposes almost all commands via an API. And if that isn't enought, you can compile PHP with vpopmail-support. cheers, Rainer
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hello John, thank you very much. Now I understand. Phps. this is slightly insecure. But I will internalize that into my perl scripting. Thanx Oliver When you run ./configure for vpopmail add this option --enable-learn-passwords=y Vpopmail with learn the passwords when the user pops for mail and that way you will not have to enter a password. -John - Original Message - From: Oliver Etzel - GoodnGo.COM (R) [EMAIL PROTECTED] To: John Johnson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 27, 2003 7:13 AM Subject: Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Hello John, what exactly is the learn password option? Oliver He can also enable the learn password option in vpopmail, I think this would be an easy way to deal with it myself. What do you think? -John - Original Message - From: Paul L. Allen [EMAIL PROTECTED] To: Oliver Etzel - GoodnGo.COM (R) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 6:47 AM Subject: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Oliver Etzel - GoodnGo.COM \(R\) writes: I want to create new users like [EMAIL PROTECTED] NOT with vadduser BUT with just inserting it via mysql-insert into the vpopmail database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. Any hints, how I can generate the encrypted password in the column pw_passwd (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hello Rainer, a perl-module for vpopmail. YES. Is it in CPAN? How is it called? Oliver Also, there is also a PERL-module for vpopmail ! It exposes almost all commands via an API. And if that isn't enought, you can compile PHP with vpopmail-support. cheers, Rainer
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
It's in CPAN. Just do a search for vpopmail in CPAN and you will find it. -John - Original Message - From: Oliver Etzel - GoodnGo.COM (R) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 7:36 AM Subject: Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database Hello Rainer, a perl-module for vpopmail. YES. Is it in CPAN? How is it called? Oliver Also, there is also a PERL-module for vpopmail ! It exposes almost all commands via an API. And if that isn't enought, you can compile PHP with vpopmail-support. cheers, Rainer
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
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 performed. 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. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM \(R\) writes: Oh my god, that is what I was looking for! There is a lesson to be learned. Next time, tell us where your immediate problem stands in the overall scheme of things. Something like I'm trying to add a user from perl by inserting them into the MySQL database but cannot figure out how to crypt the password would have allowed us to skip straight to the real problem. -- Paul Allen Softflare Support
