[147458] in cryptography@c2.net mail archive
Re: [Cryptography] Why is emailing me my password?
daemon@ATHENA.MIT.EDU (Greg)
Wed Oct 2 11:00:55 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
In-Reply-To: <524BD216.3090102@bluegap.ch>
Date: Wed, 2 Oct 2013 10:32:25 -0400
To: Markus Wanner <markus@bluegap.ch>
Cc: Nick <cryptography-list@njw.me.uk>, John Ioannidis <ji@tla.org>,
=?iso-8859-1?Q?Lodewijk_andr=E9_de_la_porte?= <l@odewijk.nl>,
"cryptography@metzdowd.com List" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7531336891786243836==
Content-Type: multipart/signed; boundary="Apple-Mail=_7E9B992B-B7A5-4C8E-A320-BD530B4D90FA"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_7E9B992B-B7A5-4C8E-A320-BD530B4D90FA
Content-Type: multipart/alternative;
boundary="Apple-Mail=_200544A9-AEF1-4823-82C5-8EE5A63483D8"
--Apple-Mail=_200544A9-AEF1-4823-82C5-8EE5A63483D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
> While I agree in principle, I don't quite like the tone here.
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).
> But I liked your password, though. ;-)
Thanks! ^_^
> For that to be as secure as you make it sound, you still need a =
password
> or token. Hopefully a one-time, randomly generated one, but it's still =
a
> password. And it still crosses the wires unencrypted and can thus be
> intercepted by a MITM.
>=20
> The gain of that approach really is that there's no danger of a user
> inadvertently revealing a valuable password.
>=20
> The limited life time of the OTP may also make it a tad harder for an
> attacker, but given the (absence of) value for an attacker, that's =
close
> to irrelevant.
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.
Somebody used the phrase "repeat after me" previously. I'll give it a =
shot too:
"Repeat after me": Sending *any* user password (no matter how =
unimportant /you/ think it is) in the clear is extremely poor practice =
and should never be done.
And, if a password is completely unnecessary, it should not be used.
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.
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
On Oct 2, 2013, at 3:58 AM, Markus Wanner <markus@bluegap.ch> wrote:
> On 10/02/2013 12:03 AM, Greg wrote:
>> Running a mailing list is not hard work. There are only so many =
things
>> one can fuck up. This is probably one of the biggest mistakes that =
can
>> be made in running a mailing list, and on a list that's about =
software
>> security. It's just ridiculous.
>=20
> While I agree in principle, I don't quite like the tone here. But I
> liked your password, though. ;-)
>=20
> And no: there certainly are bigger mistakes an admin of a mailing list
> can do. Think: members list, spam, etc..
>=20
>> A mailing list shouldn't have any passwords to begin with. There is =
no
>> need for passwords, and it shouldn't be possible for anyone to
>> unsubscribe anyone else.
>>=20
>> User: Unsubscribe [EMAIL] -> Server
>> Server: Are you sure? -> [EMAIL]
>> User@[EMAIL]: YES! -> Server.
>>=20
>> No passwords, and no fake unsubscribes.
>=20
> For that to be as secure as you make it sound, you still need a =
password
> or token. Hopefully a one-time, randomly generated one, but it's still =
a
> password. And it still crosses the wires unencrypted and can thus be
> intercepted by a MITM.
>=20
> The gain of that approach really is that there's no danger of a user
> inadvertently revealing a valuable password.
>=20
> The limited life time of the OTP may also make it a tad harder for an
> attacker, but given the (absence of) value for an attacker, that's =
close
> to irrelevant.
>=20
> Regards
>=20
> Markus Wanner
--Apple-Mail=_200544A9-AEF1-4823-82C5-8EE5A63483D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><blockquote type=3D"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=3D"cite">But I liked your =
password, though. ;-)<br></blockquote><div><br =
class=3D"webkit-block-placeholder"></div><div>Thanks! =
^_^</div><div><br></div><div><blockquote type=3D"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=3D"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=3D"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=3D"mailto:markus@bluegap.ch">markus@bluegap.ch</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On 10/02/2013 12:03 AM, Greg wrote:<br><blockquote =
type=3D"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=3D"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>=
--Apple-Mail=_200544A9-AEF1-4823-82C5-8EE5A63483D8--
--Apple-Mail=_7E9B992B-B7A5-4C8E-A320-BD530B4D90FA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBCgAGBQJSTC58AAoJEKFrDougX6FkM7oIAKP/OB6+r4x1W6mdmoOEqZow
b8o2/V68rcNWcYRu2deeVL00/VS5NIAjMtp+X60QjMRmAAmdhzz6nzua8p7i+LCs
gAU0Wvw6e7OxS9uHijPUqq498eW2oPErDxY2frCH31Ozq5uWiRNaVL8ezn+yCY+N
NUlL+Aq300CGnGUeDwqY4lE7UpBSwDfs96XzjFJSsPISA/6rexUVW+DCqJdUMmgx
RDw3XtQzxqOeyGauqYPrffE9MifE5m0Pp3XpdxiNJw17ee3bY+tfoTRTBkscSbDS
aClTPwOkRQHlFDqmCHhnWbZFAxa8e0yjyMOcpa1ygWdsKoNjPklYla67OMVafzI=
=YlQS
-----END PGP SIGNATURE-----
--Apple-Mail=_7E9B992B-B7A5-4C8E-A320-BD530B4D90FA--
--===============7531336891786243836==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7531336891786243836==--
