Re: Updated Passwords in the clear 52

Hello,

These look like excellent recommendations, and I'm glad to see the TAG
writing about this.

I have a couple of items of feedback:

ext David Orchard wrote:
> At http://www.w3.org/2001/tag/doc/passwordsInTheClear-52 and
> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080602.html

i) On the recommendation that:

> A server MUST NOT solicit any passwords in clear text

In order to comply, practically-speaking, there are essentially only two
things a server can do:

a) Ask for passwords protected with SSL/TLS (and thus preventing
intermediaries from being involved - which is a good thing in this case)
b) Ask for the User-agent to submit a salted and digested (or otherwise
encrypted) password as described in 2.1.1. This has as its implication
that the server should store only salted, digested (encrypted)
passwords, which is certainly a good practice, but one for which I think 
there is currently no standard mechanism.

I believe that it would be good to make the link more explicit between
the stated good practice and these - what amount to - related
requirements discussed later on in the document (2.1.1)

Should it also be pointed out that there is no standard way of
performing a salting/digesting mechanism? The User-agent and the server
will have to agree on the exact data and algorithm via some non-standard
out-of-band mechanism - which goes beyond the provisions of
HTTP Digest Auth mechanism as defined in RFC 2617.

This makes me think that if the requirement is that a user-agent MUST 
NOT transmit a password in the clear, then the server MUST NOT store 
cleartext passwords or the server MUST use SSL/TLS. Ultimately, that is 
where the Web should be headed. Tricky thing to say though ;)

ii) SOAP is covered, but how about AtomPub, which allows a form of the
Web Services Security UsernameToken profile to be used for
authentication to an AtomPub server (see [1]) - this method seems not to
even be officially documented anywhere, but is certainly in common use.
   Should we call this out as a specific item in section 2, similar to
the SOAP section?

iii) Would it be a good idea to mention somewhere that emerging
single-signon mechanisms such as SAML, OpenID and distributed
authorization protocols such as OAuth may be good ways of limiting the
transfers of passwords in the first place? Or is that what was implied in:

> Note that there are technologies other than passwords for enabling
> the transmission of secure informaton

?

iv) Editorial comments

- "client or browser" - is "user-agent" a reasonable replacement? Or if
it is intended that "client" should cover a case where a
server-to-server transaction is passing a password, it might be good to
be a bit more specific about the meaning of "client".
- the WS-I document listed seems like it may have been a precursor to
the WS-I Basic Security Profile [2], which tightens up the SOAP-based
security specifications considerably. Would it be good to also list this
document ([2]) also in the references?

Regards,

- johnk

[1] http://www.xml.com/pub/a/2003/12/17/dive.html
[2] http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

Received on Wednesday, 4 June 2008 14:28:39 UTC