Re: AUTH security question

Thanks for the quick reply. I'll try adding an optional salt string to PEAR::AUTH and report back if and when I have something. It seems to me that a salt string is necessary, otherwise it would be pretty easy to assume a Web app uses MD5 encryption and just sniff the password from an http post add MD5 encryption and you've hacked the site no (unless your using SSL)? One more comment from a new PEAR user. It seems to me one of the greatest stregnths of PHP is the wiki-style documentation where all users can add comments.The core documentation of PEAR isn't bad but I learn best by example and examples seem to be hit and miss for PEAR packages. That being said I realize the time and effort to implement such as system isn't trivial. I hope to see it for PEAR someday. On Mon, 2003-05-12 at 15:22, Martin Jansen wrote: > On Mon May 12, 2003 at 02:0628PM -0500, Geoff Hankerson wrote: > > It seems you have to use an MD5 encrypted passwod in your DB table which > > is fine, and I want to use a static salt key like this: > > > > Users table: > > UserID > > UserName > > Password > > PassEncr > > > > > > $conn->query("SELECT * FROM Users WHERE PassEncr='" . > > md5($_POST("password") . "MyStaticSaltKey") . "'"; > > There is no easy way to do this with the current version of > PEAR::Auth. If you want to provide a patch, just go ahead. I already > have some other patches pending, which I have to take care of. > > > (Unfortunately the PEAR site is really flakey today and I can't seem to > > access the docs on AUTH - so go easy on me if I am missing something > > simple). > > We had some issues with mysqld on pear.php.net. At the time of writing > this, everything seems to be ok again. > > > Also is there any drawback security wise to having the clear text > > password and MD5 encrypted password in the same table? > > Storing passwords in plaintext in prominent places like databases is a > security risk in every situation. > > > It seems almost necessary for a site with hundreds or thousands of users. > > There are a number of mechanisms to circumvent this. One might be to > change the password, if the user has forgotten it, and email it to > him.