<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite">While I agree in principle, I don't quite like the tone here.</blockquote><div><br></div><div>I agree, I apologize for the excessively negative tone. I think RL (and unrelated) agitation affected my writing and word choice. I've taken steps to prevent that from happening again (via magic of self-censoring software).</div><br><blockquote type="cite">But I liked your password, though. ;-)<br></blockquote><div><br class="webkit-block-placeholder"></div><div>Thanks! ^_^</div><div><br></div><div><blockquote type="cite">For that to be as secure as you make it sound, you still need a password<br>or token. Hopefully a one-time, randomly generated one, but it's still a<br>password. And it still crosses the wires unencrypted and can thus be<br>intercepted by a MITM.<br><br>The gain of that approach really is that there's no danger of a user<br>inadvertently revealing a valuable password.<br><br>The limited life time of the OTP may also make it a tad harder for an<br>attacker, but given the (absence of) value for an attacker, that's close<br>to irrelevant.<br></blockquote></div><div><br class="webkit-block-placeholder"></div><div>I don't see why a one-time-password is necessary. Just check the headers to verify that the send-path was the same as it was on the original request.</div><div><br class="webkit-block-placeholder"></div><div>Somebody used the phrase "repeat after me" previously. I'll give it a shot too:</div><div><br></div><div>"Repeat after me": Sending<b> *any*</b> user password (no matter how unimportant<i> /you/ </i>think it is) in the clear is extremely poor practice and should never be done.</div><div><br></div><div>And, if a password is completely unnecessary, it should not be used.</div><div><br></div><div>On a side-note (Re: Russ's email and others), I can't believe people are talking about encryption and key distribution algorithms in reference to this topic.</div><div><br></div><div>- Greg</div><div>
<br>--<br>Please do not email me anything that you are not comfortable also sharing with the NSA.<br>
</div>
<br><div><div>On Oct 2, 2013, at 3:58 AM, Markus Wanner <<a href="mailto:markus@bluegap.ch">markus@bluegap.ch</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 10/02/2013 12:03 AM, Greg wrote:<br><blockquote type="cite">Running a mailing list is not hard work. There are only so many things<br>one can fuck up. This is probably one of the biggest mistakes that can<br>be made in running a mailing list, and on a list that's about software<br>security. It's just ridiculous.<br></blockquote><br>While I agree in principle, I don't quite like the tone here. But I<br>liked your password, though. ;-)<br><br>And no: there certainly are bigger mistakes an admin of a mailing list<br>can do. Think: members list, spam, etc..<br><br><blockquote type="cite">A mailing list shouldn't have any passwords to begin with. There is no<br>need for passwords, and it shouldn't be possible for anyone to<br>unsubscribe anyone else.<br><br>User: Unsubscribe [EMAIL] -> Server<br>Server: Are you sure? -> [EMAIL]<br>User@[EMAIL]: YES! -> Server.<br><br>No passwords, and no fake unsubscribes.<br></blockquote><br>For that to be as secure as you make it sound, you still need a password<br>or token. Hopefully a one-time, randomly generated one, but it's still a<br>password. And it still crosses the wires unencrypted and can thus be<br>intercepted by a MITM.<br><br>The gain of that approach really is that there's no danger of a user<br>inadvertently revealing a valuable password.<br><br>The limited life time of the OTP may also make it a tad harder for an<br>attacker, but given the (absence of) value for an attacker, that's close<br>to irrelevant.<br><br>Regards<br><br>Markus Wanner<br></blockquote></div><br></body></html>