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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss-comment message

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


Subject: Re: [wss-comment] Password Digest


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?  

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


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