RE: Passwords in the Clear

Hi Paul,

I accept that the reference to the WS-I document provides useful
balance, and that allowance is given to the TLS approach. 

Looking at this in more detail, I have a related comment on the TAG
document.

Your cited message [1] contains a statement:

"Given the work of the W3C on web services, can Section 2.1 [1] point at
the use of WS-Security [3] for securing SOAP messages including any
passwords that might be supplied in clear text? [my emph: AG]"

which is then reflected in the TAG text as follows:

"2.2 SOAP Based transmissions

SOAP communicates over HTTP and is subject to similar password security
concerns. While SSL/TSL can be used to secure SOAP-based messages point
to point, the issue can be more complex if SOAP intermediaries are used.
The TAG's position on SOAP remains consistent: that passwords and
sensitive information MUST be transmitted in a secure manner and not as
clear text. [my emph: AG] If confidential information is to be sent as
part of the SOAP package, publishers SHOULD either use SSL/TLS or XML
Encryption for sensitive data elements [my emph: AG]. Further
information on security for SOAP messages can be found in Security
Challenges, Threats and Countermeasures Version 1.0 [WSI] or on the
OASIS Web Services Security TC home page[WSS]."

But, WS-Security Username Token provides a means (PasswordDigest: SHA-1
hash) of securely concealing a password during transit. It is not clear
why TLS or XML Encryption would be needed to achieve password
concealment.

Equally, and directly related, I do not understand the following
statement in the Username Token Profile spec (Section 3.1, ll 159 -162):

"Passwords of type PasswordDigest are defined as being the Base64
[XML-Schema] encoded, SHA-1 hash value, of the UTF8 encoded password (or
equivalent). However, unless this digested password is sent on a secured
channel or the token is encrypted, the digest offers no real additional
security over use of wsse:PasswordText."

But SHA-1 one-way digest is significantly more secure than plaintext.
This is not a mere encoding (in the manner of base64 encoding in Basic
Auth), but, as the name suggests, a secure hash algorithm.

Alastair




-----Original Message-----
From: Paul Cotton [mailto:Paul.Cotton@microsoft.com
<mailto:Paul.Cotton@microsoft.com> ]
Sent: 14 December 2006 00:46
To: Green, Alastair: IT (LDN); www-tag@w3.org
Cc: alastair.green@choreology.com
Subject: RE: Passwords in the Clear


> I believe that the TAG should not suggest that the use of SOAP equates
> or implies to the use of WS-Security, XML Sig or XML Encrypt. The
> evaluation of need or worth in using these technologies involves
> concrete analysis of threats in an economic context, and cannot be
> satisifed by ex-cathedra TAG-level pronouncements.

The draft TAG finding already points to a document [1] that suggests
doing just the kind of threat analysis you are asking for.  I suggested
that the TAG add this reference in my message [2].

If you review the referenced document I think you will find that it
fairly treats the tradeoff between using TLS and message level security
as alternatives to meet various threats.

/paulc

[1]
http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf
<http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf> 
[2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0023.html
<http://lists.w3.org/Archives/Public/www-tag/2006Oct/0023.html> 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329 mailto:Paul.Cotton@microsoft.com
<mailto:Paul.Cotton@microsoft.com> 





> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org
<mailto:www-tag-request@w3.org> ] On Behalf
> Of Alastair.Green@barclayscapital.com
> Sent: December 12, 2006 7:29 AM
> To: www-tag@w3.org
> Cc: alastair.green@choreology.com
> Subject: Passwords in the Clear
>
>
> I have two comments on
>
> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html
<http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html> 
>
> Can I first make it clear that these opinions are personal, and in no
> way should be considered as representing or stemming from Barclays
> Capital, where I am only acting as a temporary consultant.
>
> 1. While Digest Auth and Basic Auth/HTTPS satisfy the criterion: don't
> send passwords in the clear, they are not the only authentication
> mechanisms that fulfil that criterion. Most obviously, NTLM is used
> very widely (a fact attested to by its support in Firefox). There are
> many other secure protocols for authentication (Kerberios, SRP, for
> example), and ones that may not have yet been invented, that could be
> used (or adapted for use with) HTTP.
>
> Conclusion: I think that the architectural statement should be
> something
> like:
>
> "In the [previously defined] normal case, passwords MUST be
> significantly protected from unauthorized observation. This can be
> achieved either a) by ensuring that insecure authentication protocol
> (e.g Basic Authentication) exchanges are encrypted either at the
> transport level (e.g. by use of SSL/TLS), or by message-level
> encryption, or b) by using an authentication protocol that hashes (and
> does not simply encode) the password on the wire (e.g. Digest
> Authentication, NTLM Authentication)."
>
> This approach is more realistic (reflects practice better), less
> prescriptive, and more future-proof.
>
> 2. The statement about SOAP is misguided. There is a vendor-induced
> push to get users into the world of message-level security.
> WS-Security and its many allied specs, incarnate that push. However,
> for end users it is far from clear that transport-level security
> should be disdained, or that TLS has truly run its course.
>
> There is nothing magical or unique about SOAP's relationship to HTTP.
> Any protocol that is logically layered on HTTP may involved the use of
> intermediaries. For that matter, HTTP is used with intermediaries
> (proxies, reverse-proxies/gateways) all the time. Real-world
> topologies involve multiple barrier (firewall, load-balancer,
> specialized gateway) processors in the chain from application endpoint
> A to applicaton endpoint B. It is unclear that the cost-risk balance
> of using MLS is justified in all or even most cases where traffic is
> carried from an edge endpoint (which could act as a TLS termination
> endpoint) to internal systems which serve applications. And, if that
> requirement were real, then it would apply equally to all traffic to
> web/app servers, irrespective of the super-HTTP protocol being
> employed (SOAP, bespoke app exchanges etc). If the intermediaries are
> internal to an organization then it is even less clear that they
> should not be trusted.
>
>
> I believe that the TAG should not suggest that the use of SOAP equates
> or implies to the use of WS-Security, XML Sig or XML Encrypt. The
> evaluation of need or worth in using these technologies involves
> concrete analysis of threats in an economic context, and cannot be
> satisifed by ex-cathedra TAG-level pronouncements. Any mention of
> WS-Security and its friends should simultaneously invite consideration
> of the use of TLS, and the notion of message-level security should not
> be tied to SOAP (perhaps not even to XML).
>
> Contrariwise,  a ukase against passwords in the clear seems
> appropriate because a) it's a gross and inarguable security violation,
> and b) everyone has the equipment to implement the solution, even when
> using free software. Cost = 0, benefit > 0 => no-brainer.
>
> Alastair Green
> ----------------------------------------------------------------------
> --
> For more information about Barclays Capital, please visit our web site
at
> http://www.barcap.com <http://www.barcap.com> .
>
> Internet communications are not secure and therefore the Barclays
> Group does not accept legal responsibility for the contents of this
> message. Although the Barclays Group operates anti-virus programmes,
> it does not accept responsibility for any damage whatsoever that is
> caused by viruses being passed.  Any views or opinions presented are
> solely those of the author and do not necessarily represent those of
> the Barclays Group. Replies to this email may be monitored by the
> Barclays Group for operational or business reasons.
> ----------------------------------------------------------------------
> --
>