Re: [wss-comment] Password Digest

[Pete Wenzel <pete@seebeyond.com>]

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