perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Vanasco <jvana...@2xlp.com>
Subject Re: OffTopic (slightly) - Module Feedback Wanted - Authen::Ticketless
Date Tue, 13 Nov 2007 21:22:43 GMT

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.


Mime
View raw message