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

["De Boer, Martijn" <martijn.de.boer@sap.com>]

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. Specifying which public key should be used for encrypting
needs to be part of WS SecurityPolicy.

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>