On Nov 13, 2007, at 3:04 PM, Dodger wrote:
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...
Yes, you're right , as is your example.
However, the difference / security flaw with my system is that its
doing a sessionless (on the server) seed.
The more correct way to do this is to do a 'one time pad' / nonce on
the seed via a socket connection (ie. smtp servers), a cookie system,
or even a local expiry.
Philippe was talking about Digest Access Authentication, which is a
more secure version of CRAM ;
My friend Rob @ Mozilla actually did a recent rewrite of that last
year for their browser ( http://franklinmint.fm/2006/03/03/draft-
sayre-http-hmac-digest-00.html )- he's on vacation now, but I'm gonna
try and drag him into this.
On Nov 13, 2007, at 2:23 PM, Philippe M. Chiasson 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.
That is correct. However I've never needed a better way of storing
user passwords other than
DIGEST( user_password )
or
DIGEST( user_password . public seed )
And a scary number of applications still store passwords as
plaintext. If the database is compromised, the users can be
impersonated, but their password is not compromised.
I'm eager to hear any suggestions on password storage that can
improve what I'm already doing -- which is at the more-secure end of
the status quo.
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.
the challenges are usable for 30seconds by default, and require
hacking the server itself to find learn the server's secret key that
is used to generate the challenges (which are tested for validity
based both on time and a referential checksum). if someone knows the
server secret, then their ability to impersonate a user to the system
is of little concern - they already must have assumed control.
That being said -
i. i'd like to explore Digest Access more, as a replacement for CRAM-
MD5
ii. i need to support this sessionless/not-time-based system,
however I'll work on a way to make recording/expiring of challenges
as a nonce possible
iii. i'd love to hear advanced strategies on stories user-passwords
for webapps.
