- From: Chris Drake <christopher@pobox.com>
- Date: Sat, 28 Jun 2008 00:15:20 +1000
- To: "Doyle, Bill" <wdoyle@mitre.org>
- CC: "Dan Connolly" <connolly@w3.org>, "www-tag" <www-tag@w3.org>, public-usable-authentication@w3.org
Hi Bill, I think we've got some crossed wires. The statement was not about applications, nor tools. It pertained to "Every scenario that involves possibly transmitting passwords in the clear" - but more to the point - this whole topic is relating to web/internet technologies. You do not have the luxury of being able to design "both ends". You can either code on the serverside, if you develop sites, or code on the client site, if you develop browsers. Excluding SSL - it is NOT trivially possible to avoid transmitting cleartext (or dictionary-attackable equivalent) passwords in "Every scenario" - nor even in the overwhelming majority of any likely real-life scenario you can imagine. I'm objecting strongly to that statement because in its context, it's horribly misleading, and is likely to encourage the uninitiated or amateurs into homebrew "solutions", while none of them probably grasp the concepts of rainbow tables, hash weaknesses, dictionaries and average users, or the subtleties of session key negotiations etc; all because someone said it was possible (without explanation I must point out!), and someone else is too tight to spend $38 on a SSL cert. If you still support the statement - please answer my original question: pick a likely real scenario that someone reading this statement might be facing, explain it, then tell us how you would propose to redesign this to solve the problem. Kind Regards, Chris Drake p.s. - for the record, and since the contrary was insinuated - I'm *not* supporting cleartext passwords. Friday, June 27, 2008, 10:37:14 PM, you wrote: DB> Good Morning Chris, DB> I am an information security engineer for the Department of Defense. DB> Tasking includes being an Information Assurance (IA) engineer for Joint DB> and Tactical systems and ensuring that application design follows DB> Global Information Grid IA guidance. DB> I agree with the statement that applications can be redesigned to DB> support IA because I believe it to be true, many security tools are DB> available to support different applications requirements. I did not DB> state that supporting IA is as easy as writing a non-secure DB> application. DB> Regards DB> Bill Doyle DB> -----Original Message----- DB> From: Chris Drake [mailto:christopher@pobox.com] DB> Sent: Thursday, June 26, 2008 10:21 PM DB> To: Doyle, Bill DB> Cc: Dan Connolly; www-tag; public-usable-authentication@w3.org DB> Subject: Re[2]: delegation and passwordsInTheClear-52 DB> Hi Bill, DB> What's your cryptography background? Would you care to explain *why* DB> you're "seconding" Dan, and how you'd propose to implement such a DB> redesign? DB> Kind Regards, DB> Chris Drake DB> Thursday, June 26, 2008, 11:42:42 PM, you wrote: DB>> Chris, DB>> I will second Dan's comment "Can be redesigned for the desired DB>> functionality without a cleartext password transmission" DB>> Just because it is easier to use cleartext transmission of DB> passwords DB>> does not mean that it is the correct way to secure the application. DB> I DB>> will also add the statement that the use of cleartext transmission DB> of DB>> passwords without other security mechanisms to enforce Information DB>> Assurance (IA) provides no additional protection to the DB> application. An DB>> application design with no IA can be OK if the user has no risk, DB> one DB>> example of this is where data is considered public. DB>> Kind Regards DB>> Bill Doyle DB>> wdoyle@mitre.org DB>> -----Original Message----- DB>> From: public-usable-authentication-request@w3.org DB>> [mailto:public-usable-authentication-request@w3.org] On Behalf Of DB> Chris DB>> Drake DB>> Sent: Wednesday, June 25, 2008 10:12 PM DB>> To: Dan Connolly DB>> Cc: www-tag; public-usable-authentication@w3.org DB>> Subject: Re: delegation and passwordsInTheClear-52 DB>> Hi Dan, DB>> It is not trivially possible to redesign functionality to protect DB>> passwords. DB>> That statement both wrong and misleading: DC>>> "Every scenario that involves possibly transmitting passwords in DB>> the DC>>> clear can be redesigned for the desired functionality without a DC>>> cleartext password transmission." DB>> You can't use hashing because of dictionary attack risks, so the DB> only DB>> possible "redesign" requires some kind of two-way secure session DB>> initiation to be negotiated. That's obviously never possible in DB>> "Every scenario". DB>> A more accurate statement would be:- DB>> "Preventing cleartext or equivalent password transmission DB> requires DB>> SSL or custom server/client components designed to negotiate DB> secure DB>> sessions." DB>> Kind Regards, DB>> Chris Drake DB>> Thursday, June 26, 2008, 12:30:20 AM, you wrote: DC>>> I wonder about this: DC>>> "Every scenario that involves possibly transmitting passwords in DB>> 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 DB>> 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 Friday, 27 June 2008 14:16:24 UTC