Re: WAYS OF AUTHENICATION - open discussion
| From: | Siim Einfeldt aka Itpunk | 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 haven
t 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