Re: [vchkpw] Re: autoresponder/vacation
On Tue, 4 Nov 2003, Paul L. Allen wrote: > > > I'm finding that autorespond doesn't look like a good choice for people > > > used to a standard vacation responder > > It is a BAD choice for a vacation responder. It lacks many features > ESSENTIAL in a vacation responder. You might as well ask if sticking > your naughty bits in a mincer is a good choice for people used to real > women. It is THAT bad. Paul, don't hold back, tell me what you really think of autorespond, OK? Heh heh. > Sqwebmail's filters do this and more. You don't have to use Sqwebmail > for them to take effect, only to define them Hmmm. I hate the look of that thing, but I've been toying with installing it just for fun. Perhaps I'll see what kind of maildrop file it writes for vacation and steal that. Although the qmail-autorespond has some tempting features, including mysql support for storing the "away message" and the list of email addresses it has replied to. Plus I think I can maintain some qmailadmin compatibility. Thanks, Charles > -- > Paul Allen > Softflare Support > > >
[vchkpw] Re: testing methods
Hello Songrit, On Monday, November 3, 2003 at 4:28:40 PM you wrote (at least in part): >> Leave it in assign so vpopmail/qmailadmin will still work, but remove >> it from rcpthosts (or morercpthosts and then rebuild morercpthosts.cdb). > How to rebuild morercpthosts.cdb and /var/qmail/users/cdb Ever heard of the phrase "reading documentation"? As morercpthosts belongs to SMTPD a look in 'man qmail-smtpd' would have revealed: ,- [ ] You must run qmail-newmrh whenever morercpthosts changes. `- 'users/assign' might be eventually explained in 'man qmail-users' (a search in /var/qmail/ for available man pages would have shown you this file and a little bit of intelligence would have allowed you to draw the conclusion): ,- [ man qmail-users ] A change to /var/qmail/users/assign will have no effect until qmail-newu is run. `- ,- [ man qmail-newu ] | qmail-newu reads the assignments in | /var/qmail/users/assignandwrites them into | /var/qmail/users/cdb in a binary format suited for quick | access by qmail-lspawn. `- It really can't be THAT hard to read, couldn't it? -- Best regards Peter Palmreuther Fishing is a delusion surrounded by liars in old clothes.
Re: [vchkpw] testing methods
- Original Message - From: "Tom Collins" <[EMAIL PROTECTED]> To: "vpopmail list" <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 7:02 PM Subject: Re: [vchkpw] testing methods > > Leave it in assign so vpopmail/qmailadmin will still work, but remove > it from rcpthosts (or morercpthosts and then rebuild morercpthosts.cdb). How to rebuild morercpthosts.cdb and /var/qmail/users/cdb >>
[vchkpw] Re: autoresponder/vacation
Charles Sprickman writes:
> > I'm finding that autorespond doesn't look like a good choice for people
> > used to a standard vacation responder
It is a BAD choice for a vacation responder. It lacks many features
ESSENTIAL in a vacation responder. You might as well ask if sticking
your naughty bits in a mincer is a good choice for people used to real
women. It is THAT bad.
> > Would other programs be "plug and play" (forget qmailadmin usage for a
> > moment)?
If you use sqwevmail and maildrop then you can do a lot better. Ezcept
that there is still a dispute as to whether this stuff should be handled
in vpopmail or qmailadmin. I have a quick and dirty hack that adds what
is necessary to vpopmail (it doesn't deal with quotas but somebody sent
me a hack to my hack which is claimed. to deal with quotas).
> > Some things I'm looking at:
{...]
Sqwebmail's filters do this and more. You don't have to use Sqwebmail
for them to take effect, only to define them
--
Paul Allen
Softflare Support
Re: [vchkpw] autoresponder/vacation
And probably this one as well: http://untroubled.org/qmail-autoresponder/ On Mon, 3 Nov 2003, Charles Sprickman wrote: > Hi, > > Is anyone else using something other than the "autorespond" package to > handle vacation-style messages? > > I'm finding that autorespond doesn't look like a good choice for people > used to a standard vacation responder that keeps track of who it replies > to and tries to not autoreply to mailing lists. > > Would other programs be "plug and play" (forget qmailadmin usage for a > moment)? > > Some things I'm looking at: > > -sendmail's "vacation" > -something in maildrop > -http://frost.ath.cx/~branko/software/yaa/ > - ? > > Thanks, > > Charles > >
[vchkpw] autoresponder/vacation
Hi, Is anyone else using something other than the "autorespond" package to handle vacation-style messages? I'm finding that autorespond doesn't look like a good choice for people used to a standard vacation responder that keeps track of who it replies to and tries to not autoreply to mailing lists. Would other programs be "plug and play" (forget qmailadmin usage for a moment)? Some things I'm looking at: -sendmail's "vacation" -something in maildrop -http://frost.ath.cx/~branko/software/yaa/ - ? Thanks, Charles
[vchkpw] Re: qmail installation script 1.3.6 final release
Nick Harring writes: > That's funny, it looked a lot like signal to me. Not only did I refer you to a seminal work by Claude Shannon from the late 1940s, I gave you a summary of the salient details - yet you fail to understand. A new subscriber to this list who has not checked the archives, or somebody who does not read every message (whether through laziness or a broken mail system) will regard the first appearance of what most of us consider to be noise as being signal. > Obviously the announcements aren't that regular, since I've been > subscribed to this list for something like 8 months now, and this is the > first one I remember seeing. Congratulations. You've been here longer than I have. The only thing is that, even with my notoriously-poor memory, I remember seeing MANY announcements from him. At least more than one a month. > I have no real desire to get into some large debate about this, however > I would definitely say that I vehemently disagree with applying a term > like entropy to questionably off-topic messages to a mailing list. Then you have no understanding of information theory. The use of the term "entropy" is not some metaphor or simile: information and entropy share the same dimensional units. To understand why, you should google for "Maxwell's Demon" and then do a lot of reading from there. > If you're so thoroughly concerned with signal to noise on a list that > subscribe to, I'd recommend unsubscribing. That would be your recommendation. It has the benefit to me of losing what I consider to be noise (and the benefit to some others of reducing what they consider to be the noise of some of my posts). It has the disadvantange to me of losing the signal (and the disadvantage to some others of reducing what they consider to be the signal of some of my posts). I consider trying to improve the signal-to-noise ratio to be a better approach. As you seem to have failed to note, I have regularly pointed out that "search the archives" is a bad answer. Because after a few months, the first few hundred hits you get from Google are "this has already been answered, search the archives." This is my empirical experience and nobody has yet said their experience is different. An FAQ, antiquated as it may seem, does the job a lot better than an archive search. An FAQ that pointed to the latest version of his installation script would keep us happy and keep him happy. This is how the world used to work before Google, and how it still needs to work when dealing with mailing lists. Google is NOT a substitute for an FAQ. Anyone who thinks otherwise already has all the answers and has no empathy for anyone who does not have all the answers. > Particularly since you've demonstrated that you're quite skilled with > vpopmail, so its doubtful you derive any real benefit from the list, The benefit I gain is in spotting proposals that would be detrimental to some users of vpopmail and suggesting alternatives that would allow more people to be happy. This is not entirely altruistic, because the reason I spot stuff like that is because the proposals would also be detrimental to my usage. I figure that I'm behaving ethically if I can provide an alternative that keeps the proposer happy and keeps me and a reasonable number of others happy without significantly higher workload on the developers. Do you disagree? > other than the emotional highs you get from tearing into people. I only tear into people I believe (I may, in specific cases be wrong) to be foolish. I get far greater satisfaction from helping people. Then again, one might consider forcing people to understand when they are being foolish as helping them overcome their innate disadvantages at perceiving reality. YMMV, depending what universe you inhabit... -- Paul Allen Softflare Support
[vchkpw] Re: passwd
X-Istence writes: > He cant do MD 5 auths, or does vchkpw allow for MD5 auth logins? If my unreliable memory is not letting me down, it can do CRAM-MD5 if you have plaintext passwords set. For some versions of vpopmail. -- Paul Allen Softflare Support
[vchkpw] wierd warning in smtp logs
Hi all, had anyone got this warning in smtp logs? from log/smtp/current @40003fa6d2742cc3dc9c tcpserver: status: 1/50 @40003fa6d2742cc576c4 tcpserver: pid 28174 from 81.92.196.94 @40003fa6d2742cc71ca4 tcpserver: ok 28174 0:10.0.0.200:25 :81.92.196.94::33304 @40003fa6d275254730a4 Warning: Using English messages - error reading message file @40003fa6d2752d80c3fc tcpserver: end 28174 status 0 @40003fa6d2752d80d39c tcpserver: status: 0/50 The message is delivered but this warning bugs me. Any help on this Thanks SRosa
[vchkpw] Re: vpopmail pasw encryption change..
Reinis Rozitis writes: > To be sure in that way if dont provide previously used salt (in the user > passwords which havent been added using 'vadduser') in crypt will the > authorization through pop work? > > Theoretically salt is the first 2 symbols, but will vpopmail (vchkpsw) > understand/use that? As I already told you, it uses the same underlying system crypt routines that passwd does. If you created your passwords using crypt, and the salt consists of valid salt characters, vchkpwd will understand them whether they are old-style DES or new-style MD5. These days vadduser and vpasswd will use the new-style MD5 crypt but vchkpw will copes with either (I'm not sure if it accepts some of the even newer crypt algorithms available on some systems: it's possible to code things so it's future proof and it's possible to code things so it's not). Of course, if you don't believe me, you could always try it and see... -- Paul Allen Softflare Support
Re: [vchkpw] Old Problem Re-visited
Tom Collins wrote: On Friday, October 31, 2003, at 01:03 AM, Rick Macdougall wrote: Try 5.2.2 from Sourceforge, a lot of bug fixes have been back ported by Tom, Ken and the gang. Credit where credit is due: Michael Bowe did all of the backporting, and is entirely responsible for the 5.2.2 release. Well my apologies. Mad props to Michael Bowe then, and a virtual beer :) I really had no idea who was responsible for the 5.2.2 release. My apologies if I stepped on any toes. Regards, Rick
Re: [vchkpw] Re: vpopmail pasw encryption change..
To be sure in that way if dont provide previously used salt (in the user passwords which havent been added using 'vadduser') in crypt will the authorization through pop work? Theoretically salt is the first 2 symbols, but will vpopmail (vchkpsw) understand/use that? - Original Message - From: "Paul L. Allen" <[EMAIL PROTECTED]> To: "Roze" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 8:09 PM Subject: [vchkpw] Re: vpopmail pasw encryption change.. > > Roze writes: > > > The idea is such: There is an existing user database which I have to move > > to a mailsystem (qmail + vpopmail + mysql). All the passwords are > > encypted (no way to get plain-text) (with standart CRYPT) though there > > is also SALT provided which is 2 first symbols from username. > > Just copy the crypted passwords over to the relevant field in the MySQL > database. Vpopmail uses standard unix crypt calls. The newer versions > of vpopmail will create MD5-crypted passwords instead of DES-crypted > passwords on systems that support it. Either style of crypted password > works. > > -- > Paul Allen > Softflare Support > > > > >
Re: [vchkpw] testing methods
On Friday, October 31, 2003, at 06:36 AM, Charles Sprickman wrote: My question is this, if I do "vaddomain isp.com" so that I can test my syncing script, and I want to keep qmail in the dark about the existence of this domain, can I simply pull the "isp.com" entries out of the "rcpthosts" and "assign" files? Meaning, I don't want people using "test.isp.com" to have their mail to "isp.com" delivered locally. Would that work? Leave it in assign so vpopmail/qmailadmin will still work, but remove it from rcpthosts (or morercpthosts and then rebuild morercpthosts.cdb). It should be easy enough to test -- just telnet localhost 25 and see if it accepts mail for the domain (you might need to restart qmail-smtpd, or qmail-send after making the changes). -- 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] Enable learn passwords
On Tuesday, October 28, 2003, at 01:19 PM, John Johnson wrote: I have been working on a test system and I set enable learn password to yes but qmailadmin and vadduser will not let me Add an account with out a password. Also will vpopmail learn The password on an imap connection using courier imap? The latest qmailadmin allows for blank passwords on new accounts. I'm not what version it first appeared in, but vadduser uses the '-n' option to indicate "no password". -- 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] Old Problem Re-visited
On Friday, October 31, 2003, at 01:03 AM, Rick Macdougall wrote: Try 5.2.2 from Sourceforge, a lot of bug fixes have been back ported by Tom, Ken and the gang. Credit where credit is due: Michael Bowe did all of the backporting, and is entirely responsible for the 5.2.2 release. He also took the time to review significant parts of the code to eliminate possible buffer overflows, check error results, and more for the 5.3.26 release. -- 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/
[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
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
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 atta
[vchkpw] Re: vpopmail pasw encryption change..
Roze writes: > The idea is such: There is an existing user database which I have to move > to a mailsystem (qmail + vpopmail + mysql). All the passwords are > encypted (no way to get plain-text) (with standart CRYPT) though there > is also SALT provided which is 2 first symbols from username. Just copy the crypted passwords over to the relevant field in the MySQL database. Vpopmail uses standard unix crypt calls. The newer versions of vpopmail will create MD5-crypted passwords instead of DES-crypted passwords on systems that support it. Either style of crypted password works. -- Paul Allen Softflare Support
[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
Fw: Re: [vchkpw] vconvert
Any ideas re: this problem? I'm in bad need of some help!! Thanks, Duane > Original Message > From: "Duane Stark" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Fri, Oct-31-2003 11:34 PM > Subject: Re: [vchkpw] vconvert > > According to pkg_info, vpopmail-5.3.28. > > It's almost like vconvert cant get access to the mysql database. What connection > info is it using? Since the documentation on vconvert appears to be scarce, I can't > confirm that it's not a breakage in the vconver > mysql link. > > Thanks, > Duane > > > Original Message > > From: "Michael Bowe" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Date: Fri, Oct-31-2003 10:43 PM > > Subject: Re: [vchkpw] vconvert > > > > > > > After that, I ran vconvert -c -m and recieved the following error: > > > > > > converting demodomain.com ...domain conversion failed > > > > > > Any ideas? > > > > > > > What version of vpopmail do you have? > > > > I saw you posted previously that you had the "latest", but can you quote the > > actual version number please because it is common enough for people to think > > they have the very latest when they actually havent :-) > > > > Michael. > > > > > > > > >
[vchkpw] vpopmail pasw encryption change..
Hello. Could somebody give some instructions how to change existing vopmail vchkpw auth type, routine (where exactly it compares passwords the user has given and the one stored in MySQL database). The idea is such: There is an existing user database which I have to move to a mailsystem (qmail + vpopmail + mysql). All the passwords are encypted (no way to get plain-text) (with standart CRYPT) though there is also SALT provided which is 2 first symbols from username. With best regards. www.oto.lv
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] SMTP Auth and vpopmail-5.3.X
Hi, I just checked the most recent (available) vopopmail-5.3.27. Here, you inclued CRAM-MD5 support from Krzysztof Dabrowski. This implementation is broken; it does not confirm with Dan Bernstein's checkpassword API. Dan requires: user0password0 or - in case of C/R - user0response0challenge0. Krzysztof Dabrowski has implemented: user0challenge0response. This badly breaks the checkpassword interface. Don't promote that. More infos: http://www.fehcom.de/qmail/spamcontrol/README_spamcontrol.html I will provide a patch soon. regards. --eh. Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24
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/
