Passwords in the Clear

I have two comments on 

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.

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.
------------------------------------------------------------------------

Received on Wednesday, 13 December 2006 07:33:04 UTC