Re: [wss-comment] Password Digest

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

At 09:02 AM 10/7/2003, Scott Lewis wrote:
>I mixed up terms in my message. Sorry for the confusion. My concern is
>that Base64 buys you nothing as I can decode base64 to get the SHA-1
>hash back. At that point you can replay the SHA-1 password to
>impersonate the user. Subsequent discussion has covered the storage vs.
>on the wire issues.
>
>Scott
>
> >>> eclogue chang <e1bridge@yahoo.com> 10/6/2003 9:29:08 PM >>>
>Pete,
>
>Thanks for your clarification. However, I still have a
>question on this password digest issue. This is not
>thing to do with trust of the Provider or not, but
>just an implementation issue. For example, an
>enterprise that has the policy for no cleartext
>password can be stored in the database, and already
>stored all passwords in hashed format. Now, with this
>new WSS standard, what should it do?

Put the password in clear into the UsernameToken and then encrypt the 
UsernameToken. And no, WS-Security doesn't tell you how to distribute the 
public key to all the clients.



>Using case #1 of Password_Digest = Base64(SHA-1(nonce
>+ created + password)), I have to store the cleartext
>password on the Provider side. This will not only
>violate my company's policy, but also impossible to
>implement to the existing applications.
>
>Can you tell me how can I convert thousands user's
>stored password from SHA-1 hashed value back to
>cleartext?
>
>
>Eclogue Chang
>
>
>--- Pete Wenzel <pete@seebeyond.com> wrote:
> > Thus spoke eclogue chang (e1bridge@yahoo.com) on
> > Mon, Oct 06, 2003 at 04:52:59PM -0700:
> > >
> > > Pete, Ronald and Scott,
> > >
> > > You missed my point. The issue is not stealing the
> > > content; instead it is the safety of the cleartext
> > > password.
> > >
> > > We are talking Web Services interoperation here.
> > In a
> > > large distributed network, which one is more
> > secure?
> > >
> > > 1. A services consumer has to give the cleartext
> > > password to the Services Provider and trust the
> > > Provider, who will store the password very secure.
> > > 2. Or, the Services Consumer just gives the hashed
> > > password to the Provider. The Provider will not be
> > > able to get the cleartext password from the hashed
> > > value.
> >
> > As Ronald and I tried to point out, the second
> > method is no more
> > secure than the first.  For #2, in which you are
> > suggesting that
> >   Password_Digest = Base64(SHA-1(nonce + created +
> > SHA-1(password))),
> > an attacker does not need the plaintext password in
> > order to
> > impersonate the consumer.  All that is needed is
> > SHA-1(password), and
> > that is exactly what you are trusting the Provider
> > to keep secure.
> > That's why I said the hash of the password is
> > equivalent to the
> > password itself, when used in this manner.
> >
> > For a restatement of the problem, this is what the
> > Introduction of
> > RFC 2945 says:
> >
> >   Many existing mechanisms also require the password
> > database on the
> >   host to be kept secret because the password P or
> > some private hash
> >   h(P) is stored there and would compromise security
> > if revealed.
> >   That approach often degenerates into "security
> > through obscurity"
> >   and goes against the UNIX convention of keeping a
> > "public" password
> >   file whose contents can be revealed without
> > destroying system
> >   security.
> >
> > There are existing technologies that eliminate this
> > particular risk,
> > but they do not involve shared secrets, whether the
> > secret is a
> > password or the hash of the password.
> >
> > --Pete
> >
> > > Form the current standard, it will not be possible
> > to
> > > store the hashed password and use Nonce plus
> > Creation
> > > Time. Form the implementation point of view, if
> > you
> > > use None and Creation Time, then you have to store
> > the
> > > cleartext password at the Service Provider end.
> > This
> > > will violate the security policy for most of the
> > > enterprise.
> > >
> > > Again, why the standard enforce the implementation
> > of
> > > storing cleartext password is the real issue that
> > I am
> > > asking about.
> > >
> > >
> > > Eclouge Chang
> > >
> > >
> > >
> > > --- Pete Wenzel <pete@seebeyond.com> wrote:
> > > > Correct.  This is known as "plaintext
> > equivalence"
> > > > in the literature.
> > > > In your case #2, an attacker need not have the
> > > > actual password;
> > > > obtaining the hash of the password will allow
> > > > spoofing ability
> > > > equivalent to the intended user.  This is often
> > the
> > > > case in simple
> > > > shared-secret schemes like this, and the reason
> > that
> > > > other
> > > > technologies like one-time passwords, public key
> > > > crypto and SRP (see
> > > > RFC 2945) are used when the authentication
> > database
> > > > is at risk of
> > > > being compromised.
> > > >
> > > > --Pete
> > > > Pete Wenzel <pete@seebeyond.com>
> > > > Senior Architect, SeeBeyond
> > > > Standards & Product Strategy
> > > > +1-626-471-6311 (US-Pacific)
> > > >
> > > > Thus spoke Ronald van Kuijk (rvkuijk@abz.nl) on
> > Tue,
> > > > Oct 07, 2003 at 01:20:01AM +0200:
> > > > > I'm no real security expert but as you
> > describe
> > > > it, aren't the security
> > > > > risks the same with both?
> > > > > 1.  Base64(SHA-1(nonce + created + password))
> > > > > 2.  Base64(SHA-1(nonce + created +
> > > > SHA-1(password)))
> > > > > In case 1 you store it cleartext on the server
> > and
> > > > and use it cleartext
> > > > > on the client side
> > > > > In case 2 you store it sha-1 on the server and
> > use
> > > > it sha-1 on the
> > > > > client side
> > > > >
> > > > > In both cases you could steal the content of
> > e.g.
> > > > the ldap server and
> > > > > get into the system. The issue, imho, IS what
> > is
> > > > send over the network
> > > > > and not (mainly) what is stored. You own the
> > > > machine it is stored on (in
> > > > > most cases) you do not however own the
> > network.
> > > > >
> > > > > Ronald
> > > > >
> > > > > > -----Oorspronkelijk bericht-----
> > > > > > Van: eclogue chang
> > [mailto:e1bridge@yahoo.com]
> > > > > > Verzonden: dinsdag 7 oktober 2003 0:24
> > > > > > Aan: wss-comment@lists.oasis-open.org
> > > > > > Onderwerp: [wss-comment] Password Digest
> > > > > >
> > > > > >
> > > > > > UsernameToken Profile, working draft 4,
> > > > 11/08/2003,
> > > > > > Line 106-108 talks about digested password
> > > > offers no
> > > > > > additional security. Did I miss something
> > here?
> > > > The
> > > > > > issue is not what is sent over the network;
> > > > instead it
> > > > > > is how the services side compares the
> > password.
> > > > If the
> > > > > > clear text password is used, then the
> > Services
> > > > > > Provider has to store the clear text
> > password
> > > > for
> > > > > > password validation. This is a security
> > issue.
> > > > > >
> > > > > > Also, Line 119 Password_Digest =
> > > > Base64(SHA-1(nonce +
> > > > > > created + password))  has the same problem.
> > In
> > > > this
> > > > > > case, the Service Provider unable to store
> > > > hashed
> > > > > > password, instead it has to store the clear
> > text
> > > > > > password in its database. This will create a
> > big
> > > > > > security issue.
> > > > > >
> > > > > > If the password digest change to the follow,
> > > > then this
> > > > > > issue goes away.
> > > > > >
> > > > > > Password_Digest = Base64(SHA-1(nonce +
> > created +
> > > > > > SHA-1(password)))
> > > > > >
> > > > > > Can this suggestion be considered?
> > > > > >
> > > > > >
> > > > > > Eclouge  Chang
> >
> >
>=== message truncated ===
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Shopping - with improved product search
>http://shopping.yahoo.com
>
>To unsubscribe from this list, send a post to 
>wss-comment-unsubscribe@lists.oasis-open.org, or visit 
>http://www.oasis-open.org/mlmanage/.