Re[6]: delegation and passwordsInTheClear-52

Hi Bill,

As this is the 2nd time you've avoided explaining how - I read this to
mean that you don't know how.  Bill - if you don't know how to do the
redesign - do not support statements you don't understand.  There's a
lot of people selling security in the world - almost everything they
say is not what you think.  If nobody told you "how" - the *reason*
is because it does not work.  If you don't *understand* the "how",
it's probably because fake claims are trying to be supported (assuming
you understand cryptography, and took time to think about the steps).

Most "scenarios" are request-response (eg: HTTP or SMTP etc).  You
cannot trivially engineer password protection over this architecture.
Ask one of your cryptographers to explain "why" to you.

Kind Regards,
Chris Drake


Saturday, June 28, 2008, 12:39:26 AM, you wrote:



DB> No wires crossed, every scenario that uses clear text passwords can
DB> have proper IA in place - it may require a redesign of the application
DB> to incorporate IA.

DB> $38 dollar cert? No excuse generate a self signed cert. 

DB> Any application scenario that uses ID / PW in the clear is subject to
DB> compromise of both system and user data. How? Simple, just capture the
DB> data packets, no need to deal with hash tables or any hack tool readily
DB> available on the web.

DB> Cheers
DB> Bill D.


DB> -----Original Message-----
DB> From: Chris Drake [mailto:christopher@pobox.com] 
DB> Sent: Friday, June 27, 2008 10:15 AM
DB> To: Doyle, Bill
DB> Cc: Dan Connolly; www-tag; public-usable-authentication@w3.org
DB> Subject: Re[4]: delegation and passwordsInTheClear-52

DB> Hi Bill,

DB> I think we've got some crossed wires.  The statement was not about
DB> applications, nor tools.  It pertained to "Every scenario that
DB> involves possibly transmitting passwords in the clear" - but more to
DB> the point - this whole topic is relating to web/internet technologies.

DB> You do not have the luxury of being able to design "both ends".  You
DB> can either code on the serverside, if you develop sites, or code on
DB> the client site, if you develop browsers.

DB> Excluding SSL - it is NOT trivially possible to avoid transmitting
DB> cleartext (or dictionary-attackable equivalent) passwords in "Every
DB> scenario" - nor even in the overwhelming majority of any likely
DB> real-life scenario you can imagine.

DB> I'm objecting strongly to that statement because in its context, it's
DB> horribly misleading, and is likely to encourage the uninitiated or
DB> amateurs into homebrew "solutions", while none of them probably grasp
DB> the concepts of rainbow tables, hash weaknesses, dictionaries and
DB> average users, or the subtleties of session key negotiations etc; all
DB> because someone said it was possible (without explanation I must point
DB> out!), and someone else is too tight to spend $38 on a SSL cert.

DB> If you still support the statement - please answer my original
DB> question:  pick a likely real scenario that someone reading this
DB> statement might be facing, explain it, then tell us how you would
DB> propose to redesign this to solve the problem.

DB> Kind Regards,
DB> Chris Drake

DB> p.s. - for the record, and since the contrary was insinuated - I'm
DB>        *not* supporting cleartext passwords.



DB> 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
DB> Defense.
DB>> Tasking includes being an Information Assurance (IA) engineer for
DB> 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
DB> *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
DB> 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 Saturday, 28 June 2008 10:47:04 UTC