> C'm on. The generation of the "challenge" and the way its used in
qmail is
> well documented on my web site
> 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


Reply via email to