> C'm on. The generation of the "challenge" and the way its used in qmail is > well documented on my web site http://www.fehcom.de/qmail/smtpauth.html. > > Everyone can read that and download the code to do it. > > The only free parameters are the timestamp and the pid of the current > process. > I'm obviously missing something here, though I did reread the site for the umpteenth time in the last few years. Yes using the pid and timestamp as part of the challenge is weak. Yes the implementation ought to be fixed. No it doesn't compromise security because the challenge isn't the important part. You claimed that by recording the smtp conversation, or at least the portion relating to the AUTH process, was enough to "encrypt" the password. I'm assuming you meant decrypt (which would be the wrong word here since you don't decrypt a hash since it isn't encryption in the normal sense but is much more accurately described as obfuscation). So we're at the original situation as stated by Tom Collins and myself, namely that you can't go from an MD5 hash of the password and challenge to the password itself. Its not done anywhere in the code, because it's mathematically not doable. That's the whole point of "one-way hashing" as I'm sure you're aware. Can you please provide a description of exactly how you would take such a network dump and return the password? I'd even be willing to provide such a dump and publicly declare you right if you sent me the correct password and only the correct password in one try. If you're unable to do the above, I'd really appreciate if you'd stop spreading FUD and acknowledge that while CRAM-MD5 has its weak points vulnerability to network snooping is not one of them at this point in time.
Cheers, Nick
