- From: John Kemp <john.kemp@nokia.com>
- Date: Tue, 14 Oct 2008 16:15:42 -0400
- To: "ext noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
- CC: elharo@metalab.unc.edu, Jonathan Rees <jar@creativecommons.org>, ext David Orchard <orchard@pacificspirit.com>, "Ray Denenberg, Library of Congress" <rden@loc.gov>, www-tag@w3.org
ext noah_mendelsohn@us.ibm.com wrote: > It's probably time to wrap this up, since in some ways we're agreeing on > the pros and cons, and just not landing in the same place on whether the > circumstance justifies a MUST or a SHOULD. I'm not sure I agree with that. Personally, I think this discussion is revealing that there is more to the idea of recommending or requiring we do not "send passwords in the clear" than is expressed in the current document. The question that I have at least is whether we leave the document vague enough to cover all cases, or whether we attempt to go into more specific recommendations or discussion. Simply saying SHOULD certainly covers the bases, but it doesn't seem to me that it clearly-enough expresses the situation. It seems the use-cases for sending a password in the clear are mostly related to situations where you don't actually want to use a password, but where you don't know the alternatives to limit access in the way you want. So perhaps there should be a section in the document that talks about how to *limit* the use of passwords in the clear? > That said, I've had a number > of cases where I've happily used weak passwords, not necessarily for > pictures of my kids, but for access to experimental Web sites or other > things of transient value where it would be a nuissance but not a disaster > if casual visitors showed up. So why not hand out a username only, and use a blank password? > Yes, in some cases the same sites have also > been blocked by robots.txt, etc., all examples of casual defenses that > don't hold up well in the long run. The fact is that in each case, I > think I've been pretty well aware of the risks (or at least nothing in > this discussion has suprprised me), and I've been comfortable using the > passwords in the clear. > > As another real world example, I just received a survey from a large hotel > chain asking me to comment on my recent stay. Sure enough, the link to > the survey page was long the lines of: > > http://bighotelsrus.com/survey?userid=noahsuserid&password=xxxxxxx > > which is about as in the clear as you can get. Now it's possible that > the people putting out this survey are so dumb that they have no clue > about the security risks. More likely, they just aren't that concerned > about people trying to make a business out of rummaging through my email, > finding the survey link, and answering the survey for me. Now, why they > bother with a password at all isn't totally clear to me, but I presume the > userid shows up in parts of their system where the password doesn't. > Anyway, I don't see any reason they shouldn't do this sort of thing if it > meets their needs. Again, then if you are them, perhaps you assign a username and a blank password? - johnk
Received on Tuesday, 14 October 2008 20:18:17 UTC