RE: [wss] Current user-name password construction requires plain textpassw ord at server

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At 04:32 AM 02/13/2003, De Boer, Martijn wrote:
>Hi all,
>
>I think Hal made a good point here, as quite some systems offer interfaces 
>to 3rd party products for authentication, i.e. for verify the passwords. 
>Storage and verification of passwords is typically considered to be an 
>internal issue of a server. Now the UsernameToken makes assumptions about the
>storage of these passwords, to prevent sending an plain text password.
>
>Preventing ws clients from sending plain text passwords is something, 
>which definitely needs to be addressed by WSS, but I'm not sure if the 
>approach of rehashing (i.e. password_digest= SHA1[nonce + created + 
>SHA1[password]]) will lead to a interoperable solution. When rehashing, 
>different choices
>will be needed:
>a choice of:
>  - hash algorithms (md5, SHA1)
>  - system specific salts and other (i.e. user specific) constants that 
> may be included in the hashed value
>These will probably produce a huge set of interoperability problems. To 
>prevent these, we should limit the username/password to the simple digest 
>case.
>
>When the password is not available in plain text, the password should be 
>encrypted using a public key of the (ultimate) receiver. This could either 
>be done using XML encryption, or we could extend the UsernameToken to 
>directly support this.


I think the latter choice (XML encryption) is more consistent with 
WS-Security than any extension to UsernameToken.

I understand that people are worried about endorsing plaintext passwords, 
but I think the endorsement issue can be addressed by a "SHOULD" which says 
that if you use a form with plaintext password it SHOULD be encrypted.

>Specifying which public key should be used for encrypting
>needs to be part of WS SecurityPolicy.

As is true for any use of a public key in a <Security> element.


>Martijn de Boer
>
>Ps: See also http://lists.oasis-open.org/archives/wss/200212/msg00065.html
>
>
>
>-----Original Message-----
>From: Hal Lockhart [mailto:hlockhar@bea.com]
>Sent: Dienstag, 11. Februar 2003 20:51
>To: 'ronald monzillo'
>Cc: 'Gene Thurston'; 'Mishra, Prateek'; 'Web Services Security'
>Subject: RE: [wss] Current user-name password construction requires
>plain text passw ord at server
>
>
>
> > good point. let's call the inner hash the shared secret.
> > given that are we assuming that the authentication interfaces
> > provide access to the shared secret for the purpose of computing
> > and thus verifying the keyed mac?
>
>This is a good point I had forgotten. The use of a keyed MAC presumes a
>shared secret.
>
>What I have seen in various LDAP products is that there is a password
>attribute which is part of the standard schema. It is intended for
>authentication of access to LDAP, but many organizations use it for
>authentication to other systems, such as web servers. Some products store
>the clear password, most store a hash, but different algorithms are used.
>Some provide a choice of clear or one or more hash schemes. A few products
>do not permit any value to be retrieved, even by a privileged user. They
>only thingthey will do is check if a presented password is correct and log
>the user into LDAP.
>
>In general, environments that only permit checking and not retrieval will be
>unable to use a hashed MAC. I don't really see what the WSS TC can do about
>this, as a keyed MAC is an attractively efficient alternative to a PK
>signature.
>
>Hal
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>