OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Gene,

I think I am beginning to understand, but I have often heard
a somewhat orthogonal concern where authentication interfaces
do not allow the "password" to be obtained, only that a proposed
password value be passed in for verification.

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

In the mod you suggest (and the original), there is an assumption
that the authentication interface, allows the digets to be
obtained for recalculation of the password_digest and comparison
to the received value. Is this an issue, or are the "inner" digests
available via the authentication interface?

Perhaps we are comfortable in requiring that the inner digest be
available to the thing that processes the outer digest.

Ron

Gene Thurston wrote:
> 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>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC