On 13/11/2007, Philippe M. Chiasson <[EMAIL PROTECTED]> wrote: > The conceptual problem with this approach is that the digest(password) > effectively becomes the user's password. > > If you steal digest(password), you can impersonnate the user, without > ever knowing password. So, somebody stealing a dump of your user database > can still impersonnate all your users.
> Then a malicious attacker that stole a bunch of digest(password) can > pre-calculate a single 'challenge' and pre-generate a single > challenge/digest(digest(password) . challenge)) > pair per account he/she stole. Then can use them to login straight at the 3 > step > of the authentication process with very little work on his/her side. Something doesn't sound right with this assessment. Stealing the digest(password) wouldn't let you in on a different connection because you'd be using a different seed on a different connection... To me it sounds like he's saying this: Server: Hi, there! Client: Hi, I'm a user Server: Okay, who are you and what would your password be if encrypted off of 1234567? Client: My username is 'foo' and my password, encrypted like you said, would be '[EMAIL PROTECTED](F HBUO' (Secretly, this is stolen by a packet sniiffer) (Server looks up foo's password and encrypts it off of 0987654 and gets '[EMAIL PROTECTED](F HBUO') Server: You're right! Welcome in! Server: Hi There! Hacker: Hi, I'm a user Server: Okay, who are you and what would your password be if encrypted off of 0987654? Hacker: My username is 'foo' and my password, encrypted like you said, would be '[EMAIL PROTECTED](F HBUO' (Server looks up foo's password and encrypts it off of 0987654 and gets '[EMAIL PROTECTED]') Server: Nope, foo's password, encrypted the way I said, does not come out to '[EMAIL PROTECTED](F HBUO.' Bugger off, wannabe leet hacksore. -- Dodger