Creating Log-In System

[Capo64]

Hi, I just need the basic idea of this.

I don't want to use a third party one since I've done everything from scratch thus far..

Do i just store the username and md5(password) in a cookie/session and do a login check every time a page is loaded?

Has anyone made a login script before?

[corneo]

I may really be wrong with this answer but every time I installed a Log-In System. It went to a database.

[marc_gfx]

I've done my login stuff from scratch too. read about http-authentication if you are really interested. It's a bit of a pain in the backside, but at least you know whats happening after that ... I store passwords using something similar to salted md5 and use https for login (I added the https stuff later on).

[Capo64]

Yeah, I understand how to secure the password and such,

but what do I store in the user's session?

The md5'd password and the username? and then just do a check every time a page loads to see if the username and password are correct?

[marc_gfx]

storing the password in the session makes no sense, if someone is going to steal it, it wont make a difference. it makes more sense to store some browser and ip information about the user to compare with the information you get from the client. that's only simple security though. check for session hijacking on google.

[Capo64]

I understand what you're saying in case someone hijacks the session, it won't matter. But the thing is..

If I don't store the password in the session, the person won't even need to hijack a session they could just log in as anyone if they know their username..right?


Say I only store $_SESSION['username'];

couldn't someone just change that to whatever username they want and log in as that person? At least if I store the password and do a check every time a page loads, the person will need to actually know the password to log in as someone else. (or the md5'd password atleast).

Sorry if this is obvious, I apparently don't know much about sessions..

[marc_gfx]

you only store user information when a person is logged in. the session information is stored on the server, not on the client. cookies are stored on the client. cookies can be used to store the session id, but not the session contents. So no one should be able to change the session content, without access to your machine.

I usually pass the sessionid in the url, as my site uses multiple domains and subdomains, that would otherwise cause sessions to get lost. you will have to call session_start using the sessionid to restore the current session in this case.

[Capo64]

Ooooh, ok that makes sense, well I'm gonna go to sleep, but I'm sure I'll have some more questions for you tomorrow.

Thanks a lot for your help so far.

[Capo64]

Ok, now I know what to put in the session, I finished a good portion of everything today, but I want it to be able to remember people, so what do I store in the cookies.

This is what I meant yesterday because I thought the session was stored on the client side.

I know I can't just put the username in the cookies because then you CAN just spoof it.

So what do I store in there. I thought username and encrypted password?

I was looking at salts, I kinda understand them but kinda not.. still checkin it out.

Pretty much I generate a random salt every time someone sends their pass and first I send the salt, they md5(pass . salt) send it to me, and I do the same?

[marc_gfx]

username + encrypted password would be a solution yes. any way your gonna have cookies to autologin, you will be leaving a kind of security issue though. if you transmit the salt to the user, you make things a little worse. This makes it easier for anyone who gets the cookie + salt to decrypt the password (only way is brute force, test every possible password). if the salt is also unknown the testing will require checking much longer passwords and can be too much for your attackers computer to decrypt in a useful time.

you should store your users password in some kind of encrypted form in the database (so no one, not even you, can easily decrypt it). you can then compare cookies user + encrypted password to the information in your database.

[Capo64]

Yeah, that's what i was thinking, but wouldn't someone be able to bruteforce the password anyway?

If I just transmit the password, rather than the password + salt, it seems it would be even easier to test all the combinations.

I think I'm just gonna finish the whole system right now, and implement remember me once I can fully see what's going on.

[marc_gfx]

its always possible to brute force, if you have access to the encrypted version. but... only if you know the encryption method. so if you use an altered version of md5... its going to be even harder to guess.

you never transmit the password or the salt in plain text. you set the cookie using the encrypted + salted password. the attacker therefore only has access to an encrypted password of which the encryption is hopefully not known.

[Capo64]

Ok, I'll just md5(sha1(md5(sha1(pass)))) or somethin like that?

Can you md5 a string of any length?