Page 1 of 1
opinion on passwords
Posted: Wed Jun 12, 2002 1:58 am
by hob_goblin
I'm going to try to make my site a "members" kind of thing..
What do you guys reccomend looking into about making it secure, and handling members only content, and public content...
Posted: Wed Jun 12, 2002 8:37 am
by qads
use MD5(); password encryption but i guess you already know that

Posted: Wed Jun 12, 2002 10:39 am
by hob_goblin
yeah, i was more worried about the best way to tell if a user is logged in..
Posted: Wed Jun 12, 2002 10:47 am
by volka
$_SESSION['uid'] is common I think and secure, too
Secure?
Posted: Wed Jun 12, 2002 11:25 am
by BDKR
Well, if you are worried about a person that's allready logged in, I would say two things.
1) DO NOT move sensitve information from page to page using the GET method. That puts all of the info right in the URL. Use the POST method. If you are using the built in PHP sessions, then it's even easier to deal with.
Now sessions have some security issues as well. There is a document about PHP security that you can check out. Here is the link.
http://www.securereality.com.au/studyinscarlet.txt
This is the reason I developed my own sessions handling.
2) You want to make sure that an inactive logged in user is automatically logged out after a set period of time. I set it at 15 minutes.
Something to consider about logging in and using MD5(). MD5() doesn't do any good unitl the password has reached the server. What that means is anyone that captures the information between the users browser and the server can see and read the password in PLAIN TEXT. That said, I do Javascript MD5() and send the password that way. The added bonus is that it's less processing I have to do server side.
Later on,
BDKR (TR Cox)
Posted: Wed Jun 12, 2002 1:37 pm
by volka
I have read
http://www.securereality.com.au/studyinscarlet.txt and I see no general fault in php-implementations. Upgrade your php-version (if necessary), turn register_globals off and keep an open eye on those security risks.
PHP and security
Posted: Thu Jun 13, 2002 11:07 am
by BDKR
The things mentioned as potential issues with PHP implementation of sessions is enough for me.
Are you sure you read the section concerning sessions?
Also, developers can't just simply rely on PHP to fix all issues or be watchful for them. The changes that have been made in PHP are indeed good, but does that mean that some clever dodger isn't going to find other issues? As developers, we in the PHP community have to be as paranoid about security as everybody else.
That said, I will not use PHP's implentation of sessions when I feel mine is "more" secure. Notice also that I said "more" secure. Not totally secure.
later on,
BDKR (TR COX)
Posted: Thu Jun 13, 2002 1:07 pm
by jason
volka: I think BDKR was refering to the fact that by default, session files are stored in /tmp and are easily accessible on a virtual hosting environment. By session handling, I believe he refered to saving session information to another place, such as a Database.
Posted: Fri Jun 14, 2002 3:51 am
by volka
ok ok, I agree there are pitfalls a developer/admin is invited to step in. But before reimplementig a 'basic' framework feature I try to make the most of it (and sometimes I don't

).
When I started to earn my money with developing I was eager to do it all on my own (it's not in <stdio.h> or <stdlib.h> - I have to implement it

)
May be I changed sides a litte bit too much.