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


I think it would make things clearer if we called the value derived from the
password and used to construct the keyed MAC a "shared secret". This would
include using the password as is, hashing it directly, hashing it with a
salt, "folding" and hashing it as in Kerberos, etc. The important property
this value must have is it must be known to both the creater and the
verifier of the secret (hence the name).

Then we could talk about computing a hash of the message combined with the
shared secret and nobody would get confused between two kinds of hash.

Hal

> -----Original Message-----
> From: ronald monzillo [mailto:ronald.monzillo@sun.com]
> Sent: Tuesday, February 11, 2003 11:49 AM
> To: Gene Thurston
> Cc: 'Mishra, Prateek'; 'Web Services Security'
> Subject: Re: [wss] Current user-name password construction requires
> plain text passw 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>
>
>
>
> ----------------------------------------------------------------
> 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