Re: [wss] PasswordDigest in Username profile

[Peter Dapkus <pdapkus@bea.com>]

I wasn't involved in the design of the password hash, so I have no
knowledge of the design rationale.

However, I think there is an issue with putting the secret at the
front.  I believe the output of SHA-1 is the function's complete state
at the end of processing an input stream.  If the input stream  happens
to fit neatly into the block size of the hash function, you can extend
the input with additional blocks and generate new/unique hash values
knowing only the hash output for the original stream.   

If you put the secret at the end of the stream, then you prevent
attackers from arbitrarily extending it -- since they have to end the
input stream with the password which they don't know.

It seems like, if you put the nonce/created at the end, then an attacker
could update your nonce to be nonce+created, and add a new created time
on the end to generate a new hash.  

Another way to work around this would be to add the length of the hash
input to the front of the input, or possibly to put the password at the
beginning *and* the end of the hash input.

-Pete 

On Fri, 2003-09-05 at 10:49, Rich Salz wrote:
> > I don't understand your comment. Why would SHA-1( password + nonce + created ) be
>  > "harder for crackers" than SHA-1( nonce + created + password )?
> 
> If I were doing a brute-force attack, I'd have to do the whole SHA1 
> operation for p/n/c for each guess.  If the format is n/c/p, then I can 
> compute n/c, save the digest state, and then only "restart" the hash 
> with each password guess.
> 	/r$
-- 
Peter Dapkus <pdapkus@bea.com>