Re: WAYS OF AUTHENICATION - open discussion

From: Date: Sun, 05 Nov 2000 09:13:14 +0000
Subject: Re: WAYS OF AUTHENICATION - open discussion
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-23777@lists.php.net to get a copy of this message
>If the file that is included is not in the public portion of the server then >it can't be included from remote, thus not gaining access to the mysql >database. >for instance, if your public directory is in: >/home/theuser/www >And the include file is /home/theduke/include/connect.inc.php3 So in other words, if I have the file in /myuser instead of /myuser/public_html, the data is secured? Unless of course I have some weird server configurations. >The 'session' information stored in the db table has a timestamp on it and >the cron removes it after the specified time, the username is only stored in >there. Each user has a 2 hour window, after two hours the system will see >the timestamp has expired and tell them to re-login, so even if the cron >hasn't removed the session information, the script knows to not accept a >session after two hours. until now I just didn`t let the user to be idle more than 30 minutes, but the idea of not letting the user be in over 2h at all, sounds good as well, as the noone will probably need more time anyway (at least in my particular case. I don`t have a cron job, but well, if the 'refreshed' has expired or 2h has gone past, I guess there`s no problems (at least not big ones). And in my case, if there are undeleted old sessions, then I have this little addition that when someone logs in, the useless sessions will be deleted at the same time. (not only the logging user ones, but rather all). >Also, when I store passwords in a database I encode them using the MySQL >encode function ENCODE(str,pass_str) >(http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#Mi >scellaneous_functions) >This value is stored as a BLOB in the table so it's encoded nicely, AND I >encode the password with itself so if the password was 'jones' then I do >password = encode('jones','jones'). This way nobody but the user who knows >the password can possibly retrieve it. There is no external 'key' that >someone can find. Right now I have passwords encrypted with md5 in php and then put to a database. ah, jess, lets talk about different encryption methods as well,which are the best ones? As said, I`m usaully using md5(and already in php), but would it be any use to add the already encrypted password to database with PASSWORD()? E.G $myuser = md5('mypass'); mysql_query("INSERT INTO users(password) VALUES (PASSWORD('$myuser'))"); And then when somone logs in, I just encrypt his entered password and see if the one he entered and the one in the database match. That one I havent done yet, but Im definately thinking about it. I´m not going to keep national secrets on the site, but...well, the securer the better. >The drawback? Well, if they forget their password then it can't be retrieved >so I generate a new one randomly generated and sent to the e-mail on file >(retrieved by user giving username so they don't know what e-mail address >the new password was sent to). After they get the randomly generated >password they are encouraged to login and change the password again to what >they want. Can we truly call it a drawback? The security matters, user satisfaction too of course, but as he (or she ... without wanting to insult out female companions) will have the opportunity to change it again, then in my opinion there are no problems. >Additional drawback to this, I have a user who continually forgets what >password she uses and in two months she's reset it 2 times. Well, ... well,...yes. >Just my 2 cents worth. Feel free to poke holes in my methodology and tell me >why it wouldn't work. No actual holes found, though if there were any, someone could tell it. I hope more people will have something to say concerning security of web sites. Siim Einfeldt

« previous php.general (#23777) next »