Re[2]: delegation and passwordsInTheClear-52

Hi Bill,

What's your cryptography background?  Would you care to explain *why*
you're "seconding" Dan, and how you'd propose to implement such a
redesign?

Kind Regards,
Chris Drake


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 passwords
DB> does not mean that it is the correct way to secure the application. I
DB> will also add the statement that the use of cleartext transmission of
DB> passwords without other security mechanisms to enforce Information
DB> Assurance (IA) provides no additional protection to the application. An
DB> application design with no IA can be OK if the user has no risk, 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 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 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 requires
DB>    SSL or custom server/client components designed to negotiate 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 02:21:52 UTC