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

[Gene Thurston <gthurston@amberpoint.com>]

I just read the posting that Prateek pointed to, and am convinced that
we need to change the way our UsernameToken digests with nonce and/or
creation timestamp are calculated -- or at least allow for the
suggestion made by John G. de Freitas (of Netegrity), as relayed by
Prateek.

In a nutshell, our current draft suggests the digest be calculated as:

	password_digest= SHA1[nonce + created + password]

The following simple change to this allows for systems that do NOT store
clear-text passwords persistently:

	password_digest= SHA1[nonce + created + SHA1[password]]

I strongly agree with Prateek that our UsernameToken profile has to
allow for this type of digest, either as *THE* way digests get
calculated, or as a different "Type" attribute value on the
<wsse:Password> Element.

Furthermore, as Hal pointed out, there are systems that do not store
password digests as SHA1 hashes, but other hashing mechanisms -- e.g.,
MD5, or whatever.  While we can use SHA1 for the "outer" hash in the
proposal above without effecting the underlying LDAP (or other password
repostitory) systems, we *MUST* allow for the "inner" hash (the one that
hashes just the clear-text password) to specify alternative algorithms.

How do we get these issues into the UsernameToken Profile document?  Do
we need to open up issues and discuss them on the next conference call?
Or, should Prateek (or I, or anyone) propose specific wording changes
for the document and have the editor (Tony, I guess?) make those changes
and publish a new version?


- Gene Thurston -
AmberPoint, Inc.



-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com] 
Sent: Tuesday, February 11, 2003 8:14 AM
To: Web Services Security
Subject: [wss] Current user-name password construction requires plain
text passw ord at server


I had pointed this problem out in:

http://lists.oasis-open.org/archives/wss/200212/msg00063.html

The issue is not finding some nifty new password algorithm but
that standard LDAP/AD deployments typically store only hashed passwords.

Adding a new "WS password deployment" model to security systems is a
bad idea and will simply lead to plain text passwords being stored
in ad-hoc repositories. We should instead revise the 
password hashing methods so that plain text passwords are not required.

- prateek

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>