- From: Doyle, Bill <wdoyle@mitre.org>
- Date: Thu, 26 Jun 2008 09:42:42 -0400
- To: "Chris Drake" <christopher@pobox.com>, "Dan Connolly" <connolly@w3.org>
- Cc: "www-tag" <www-tag@w3.org>, <public-usable-authentication@w3.org>
Chris, I will second Dan's comment "Can be redesigned for the desired functionality without a cleartext password transmission" Just because it is easier to use cleartext transmission of passwords does not mean that it is the correct way to secure the application. I will also add the statement that the use of cleartext transmission of passwords without other security mechanisms to enforce Information Assurance (IA) provides no additional protection to the application. An application design with no IA can be OK if the user has no risk, one example of this is where data is considered public. Kind Regards Bill Doyle wdoyle@mitre.org -----Original Message----- From: public-usable-authentication-request@w3.org [mailto:public-usable-authentication-request@w3.org] On Behalf Of Chris Drake Sent: Wednesday, June 25, 2008 10:12 PM To: Dan Connolly Cc: www-tag; public-usable-authentication@w3.org Subject: Re: delegation and passwordsInTheClear-52 Hi Dan, It is not trivially possible to redesign functionality to protect passwords. That statement both wrong and misleading: DC> "Every scenario that involves possibly transmitting passwords in the DC> clear can be redesigned for the desired functionality without a DC> cleartext password transmission." You can't use hashing because of dictionary attack risks, so the only possible "redesign" requires some kind of two-way secure session initiation to be negotiated. That's obviously never possible in "Every scenario". A more accurate statement would be:- "Preventing cleartext or equivalent password transmission requires SSL or custom server/client components designed to negotiate secure sessions." Kind Regards, Chris Drake Thursday, June 26, 2008, 12:30:20 AM, you wrote: DC> I wonder about this: DC> "Every scenario that involves possibly transmitting passwords in the DC> clear can be redesigned for the desired functionality without a DC> cleartext password transmission." DC> -- DC> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080602 DC> W3C has tried to stamp out cleartext passwords on its own DC> web site a few times, but one of the main blockers, aside from DC> buggy support for digest in various bits of software, is delegation. DC> W3C has a few forms-based services that use DC> cleartext passwords for delegation; e.g. our XSLT service DC> http://www.w3.org/2005/08/online_xslt/#authinfo DC> If you want to use the service on password-protected pages, DC> you just put the credentials in a form and it uses them. DC> The main use case is password-protected pages inside w3.org DC> (though I'm not sure that's technically enforced) so it's DC> not really all *that* much less secure than sending credentials DC> to get the actual password-protected page. Still, yes, DC> it makes many of us uncomfortable. DC> How can these delegated services be "redesigned for the desired DC> functionality without a cleartext password transmission." DC> The W3C systems team has been looking at this for several DC> years without finding a solution.
Received on Thursday, 26 June 2008 13:43:26 UTC