W3C home > Mailing lists > Public > www-tag@w3.org > June 2008

RE: Re[2]: delegation and passwordsInTheClear-52

From: Doyle, Bill <wdoyle@mitre.org>
Date: Fri, 27 Jun 2008 08:37:14 -0400
Message-ID: <4DE292A150B5CA48BDDA9658300E753878CDDD@IMCSRV8.MITRE.ORG>
To: "Chris Drake" <christopher@pobox.com>
Cc: "Dan Connolly" <connolly@w3.org>, "www-tag" <www-tag@w3.org>, <public-usable-authentication@w3.org>

Good Morning Chris,

I am an information security engineer for the Department of Defense.
Tasking includes being an Information Assurance (IA) engineer for Joint
and Tactical systems and ensuring that application design follows
Global Information Grid IA guidance. 

I agree with the statement that applications can be redesigned to
support IA because I believe it to be true, many security tools are
available to support different applications requirements. I did not
state that supporting IA is as easy as writing a non-secure
application.  

Regards
Bill Doyle




-----Original Message-----
From: Chris Drake [mailto:christopher@pobox.com] 
Sent: Thursday, June 26, 2008 10:21 PM
To: Doyle, Bill
Cc: Dan Connolly; www-tag; public-usable-authentication@w3.org
Subject: 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 12:38:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:58 GMT