Safe way for user login system

[andrewsmd]

I've never built a login system from the ground up so I just want to run my thought process by you guys and make sure I'm thinking about things right.

Usernames and pws are stored in a table pws are md5 hashed.

If a user puts in a successful un pw combo, I insert a record into a temp table. It stores their userid, sessionid, and date modified.

On any given page, the first function I call is my check permissions function which pulls their session id to see if it exists in that table. If it does, it makes sure their permissions level is correct. If so, nothing happens. If not, then I call header("Location: http://example.com/login");

Is there anyway someone could subvert this? If so, how can I make it secure? thanks!

[brotherhood of LAN]

Sounds fine. I assume you have exit(0) after header("Location: http://example.com/login"); so no content is served.

I run exactly the same setup. The 'temp' table is a MySQL MEMORY table so lookups are very quick based on a 16 byte MD5 session hash.

Cron job is run periodically to remove older sessions.

A nice touch is to include the redirected from URL, so the user goes back to the original page they were trying to view.

[andrewsmd]

Yea, I'm trying to get this baby off the ground, getting back to the proper url is first up in v2. I do have exit called as well. I've never done the memory table, does it really help performance that much? I suppose if there are a lot of users logged in at one time, that's what it is for?

I'll schedule something to clean out the old sessions, that's the only reason I was storing the date modified. I was thinking of updating my check permissions function to update the modified date because it get's called when they go to a new page.

Do I need to hash the session ids? I figured they were random enough as is.

I can tell you one thing, after coming from .net development, this makes me appreciate the membership provider that's built into .net. I just run the script on the db, add in a couple lines, and I've got user and sessions working. Plus, nice objects to query, update, and delete users.

[brotherhood of LAN]

PHP is much the same in that the session_start() function will pretty much deal with sessions for you and are simple to use, but it makes tables storing sessions a bit redundant as it uses temporary files instead. After revisiting the PHP manual page, it seems you can customise the way PHP handles sessions a lot more than you used to be able to.

I prefer to avoid them, particularly so when you're creating a table to store related data. Using a memory table is fast and I consider it good use of memory considering login credentials are checked on every page load.

[hugoramirez]

I've more or less stopped writing my own login systems ever since I ran into this little gem:

[barebonescms.com...]

But anyway, md5 is no longer the recommended method for hashing passwords. Using bcrypt is the "better" approach. If you want to do some reading on why using bcrypt is better, this might help:

[codahale.com...]

Basically, the guy points out that hashing algorithms are built for speed, which is bad for password storage.

[brotherhood of LAN]

hugo, there's a difference between storing passwords as MD5 hashes and having an MD5 as a session hash.

'Cracking' the former compromises the account, the latter only compromises the session.

In any event, if someone has the hashed values from your DB it's only a matter of time, but I agree RE: MD5 no longer being the best for hashing passwords.

[andrewsmd]

So it looks like I can't use bcrypt as it's not installed and this site sits on a server that I don't control. I read up on just crypt, is that really the best alternative I have?

[coopster]

See hash():
[php.net...]