- From: Jonathan Rees <jar@creativecommons.org>
- Date: Wed, 8 Oct 2008 08:56:49 -0400
- To: "David Orchard" <orchard@pacificspirit.com>
- Cc: noah_mendelsohn@us.ibm.com, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <760bcb2a0810080556pfeea926nb3063dd4007ea56f@mail.gmail.com>
Your text works for me. It fixes the grammar and is specific and definite. Run with it. -Jonathan On Wed, Oct 8, 2008 at 12:11 AM, David Orchard <orchard@pacificspirit.com>wrote: > I like where Jonathan is going on this, but I think that we aren't going to > come up with enough caveats/explanation that will satisfy those that want a > "MUST NOT transmit passwords in the clear". We can try the explaining route > without the SHOULD NOT or MUST NOT.. > > My attempt: > > "Good practice: Clear text passwords are a serious security risk. Transmit > passwords in the clear only in interactions that do not need to be secure > and do not lead to the new vulnerabilities in other interactions." > > A vulnerability may be created with clear-text passwords if the same > password in the clear text interaction is re-used in in other interactions. > Users and administrators should take appropriate steps, such as warnings, to > mitigate such a vulnerability if clear text passwords are used. > > Cheers, > Dave > > > On Tue, Oct 7, 2008 at 12:12 PM, Jonathan Rees <jar@creativecommons.org>wrote: > >> Yes, I think this is an important point, and that's why I wrote (maybe you >> didn't see this): >> >> "remind developers / site administrators that users of passwords >> transmitted in this way must (MUST?) be told in no uncertain terms that such >> passwords should be treated as public knowledge and shouldn't be used to >> protect anything that matters." >> >> This could be amplified with explicit mention of the case where someone >> might be tempted to reuse, in an in-the-clear context, a password that >> *already* protects something that matters. Just don't do it. >> >> I looked for wording like this in the draft and didn't find it, and didn't >> see it in the IRC log, so I thought is possible that there was a reason we >> shied away from it. >> >> To talk about "the risks" and "being aware of the risks" is a bit coy, I >> think. It sounds like we're choosing not to tell readers what those risks >> are, that it's a puzzle for them (or there users) to figure out. Better to >> just say: It's not secure, don't let anyone think it is, do it only when >> security doesn't matter. >> >> Jonathan >> >> >> On Oct 7, 2008, at 1:50 PM, noah_mendelsohn@us.ibm.com wrote: >> >> Jonathan Rees suggests: >>> >>> "Good practice: Clear text passwords are a serious security risk. >>>> Transmit passwords in the clear only in applications that do not >>>> require any assurance of security." >>>> >>> >>> I'm sympathetic to your attempt to come up with something, but I think >>> this misses an important nuance that is mentioned in the draft minutes of >>> our meetings. As I understand it, one concern is with the risk that >>> novices will use the same password for multiple applications. So, you >>> deploy the "birthday party registration application" for your child, and >>> decide that pwds in the clear are just fine for that. Unbeknownst to >>> you, >>> those registering for the birthday party use the same password as for >>> their bank account. Nefarious network sniffers pick up the pwd from the >>> birthday login, and use it to empty the bank account. >>> >>> I believe we were told by the security "experts" that this sort of thing >>> was an important concern for them, and one of the reasons they wanted to >>> prohibit pwds in the clear entirely. Perhaps: >>> >>> "Good practice: Clear text passwords are a serious security risk. >>> Transmit >>> passwords in the clear only in applications that do not >>> require any assurance of security, and when users are aware of the >>> risks." >>> >>> Noah >>> >>> -------------------------------------- >>> Noah Mendelsohn >>> IBM Corporation >>> One Rogers Street >>> Cambridge, MA 02142 >>> 1-617-693-4036 >>> -------------------------------------- >>> >> >> >
Received on Wednesday, 8 October 2008 12:57:24 UTC