User Login Help

[ngreenwood6]

I have a question for some more advanced developers out there. I am creating a user login class that I want to make secure. Now without cookies, no problem but everyone wants a remember me  . So what I was planning on doing was storing a single unique value in a cookie. Now when the user visits the page it will check there unique value against the values in the database. Then what I wanted to do was have some other data that is unique to that user to see if they are the same person or not. For example when user A with ip address 0.0.0.0 goes to access my page and has a cookie stored it will check the database for user with ip address 0.0.0.0 and the unique value in there cookie.

 

Now my question is, what values should I check against. It is my understanding that users can spoof ip addresses so that isnt exactly the best check. I was also going to use the hostname as well but you have to have the right ip address in order to check it so that isnt really reliable either. Another option is securing it another way. If anyone has any other suggestions that are secure to do a user login please let me know. I am open to anything at this point because I am creating the system from scratch. However, only secure systems are the way I want to go. I have advanced experience in php so dont worry about me not understanding .

 

Any help is appreciated.

[Zurev]

Well you could always have the page check a random value in their database table that's regenerated each login, against their userID. That seems to work fine unless you have more than one user logging into the same account at the same time. I suppose if you're storing a salt in the database for that user then you could check against that, however I'm unsure of the security implications that would cause.

 

Personally, I would use a simple process like my first suggestion:

User logs in, credentials are ok, generate random value and store it in "loginkey" field in the users row.

Set the cookie to their userID.loginkey

In your config file (or whatever file is used every page), pull the users information, if the userID doesn't match the loginkey or vice versa, log them out.

 

This way if they decide, oh I can set the first part to any userID I want, I'll set it to userID 1 since that's probably admin, then it checks if their loginkey is the same as userID 1's, and logs them out immediately.

[ngreenwood6]

So tell me what happens when I copy your cookie to my computer. Guess what it lets me login as you because I have your unique id and that is all that I am checking it against. That is why I want to check against something/somethings that are unique to users. If I check against the users cookie and there ip address the chances are alot better that the person trying to hack didnt realize I was trying to check against ip address too when they stole the cookie. However, after the first time they do that and guess what there in because they spoofed the ip. Looking for something that is unspoofable/unhackable.

[johnny86]

I think you should create your own session handlers that will store data in your database. You'll always get a session ID when you start a session, and upon login or so you should use session_regenerate_id for fresh ID to prevent session fixation.

 

After that you should create your own random string and hash it. Store it as cookiehash or so. Save it to your database, link it to the new session that started. And send it for the client as a cookie.

 

I prefer to use only User Agent in my checks so that atleast that won't be able to change during session. IP addresses might change caused by proxy servers mostly. So I tend to save the user agent hashed to my database upon login.

 

Now when I need to, I can always check these values:

- Session ID to know what session we are accessing

- Cookiehash (from cookie) against the one in database

- Hash of user agent against the one in database

 

You should also create a token to your forms on the fly which is stored to the session also and compared too when logged in user submits a form. It can even be different on every form submit.

 

This is basicly my approach in a nutshell.

[johnny86]

And also you should have some kind of serverside salt that is applied to the hash in case some hacker tries to spoof stuff. That salt should never be sent to the client but only used at comparsion.

[ngreenwood6]

@johnny86 I think that there is still an issue with your code being able to be hacked pretty easily as well. If you are storing that data in a cookie and checking it when a user revisits the page then all I have to do is copy the cookie you are saving on someone else's computer to mine and I can login as them as long as I am using the same browser. If I am incorrect please explain to me how because in reading your approach it seems that you are just storing a unique value in a cookie and then checking it when the user revisits the site comparing that value with a hash of the user-agent which is the same for each user that is using the same browser.

[Zurev]

So tell me what happens when I copy your cookie to my computer. Guess what it lets me login as you because I have your unique id and that is all that I am checking it against. That is why I want to check against something/somethings that are unique to users. If I check against the users cookie and there ip address the chances are alot better that the person trying to hack didnt realize I was trying to check against ip address too when they stole the cookie. However, after the first time they do that and guess what there in because they spoofed the ip. Looking for something that is unspoofable/unhackable.

 

You clearly did not read/understand my post in the slightest.

 

because I have your unique id and that is all that I am checking it against.

No, you're checking it against the random loginkey that is generated ONLY for that user each time they log in.

 

That is why I want to check against something/somethings that are unique to users.

The randomly generated loginkey can be made unique to each user.

 

I have a hard time believing you have advanced experience in PHP while still bringing up the "check against IP address" point.

[ngreenwood6]

@Zurev I highly doubt you have advanced experience in php since you dont understand that your method is severly flawed. You are storing the userID.loginkey in a cookie. Now if you were to give me the value of that cookie say "1abf" all I have to do on my computer is create that cookie and I WILL have access to your account. Sure I may not be able to be admin since the user_id doesnt match the the loginkey if I were to change it but I could still be logged in as you. You are not checking it against anything other than the cookie. If I found anyone's cookie I could easily login to there account simply by creating the same cookie on my computer. And I am an advanced php developer but I do not have advanced knowledge of security which is why I came here. Run your solution past any other person that knows security and they will tell you it has the flaw I am telling you about because I have run into that before.

[Zurev]

So let me get this straight, you have advanced php experience, but don't have knowledge of security. But me, I don't have advanced experience because I'm giving you bad security advice? Right.

 

Anyway, you're saying if I give you my cookie value, you can login as me, yeah, you're right. I'm a bit confused of what the issue is there, you're afraid somebody might give out the information in their cookie? I'd be worried about that as well, just as worried about them giving out their password.

[fxuser]

I will just try to help and throw an idea...

 

What about creating a cookie with users id and an unique hashed generated id which will aumatically change on each page that requires to be logged in.. so even if u get the cookie on your computer you will probably wont be able to do it since the unique id will be changed and if the user logs out the cookie and unique id will be set to NULL..

 

Just throwing an idea.. not sure if it will help you...

[PHPTOM]

To put it bluntly anything using cookies is a security risk. This is just part and parcel of implementing a remember me. The only things I could think of is if the person logs in with the remember me checked:

 

1) Login with checked

2) Insert into a remember me table with the IP, ID of user, agent, random auth

3) Set a cookie with the random auth

4) check against it all and if it comes back true login to the user ID

 

Only thing I could think of in the early hours of the morning. I do think this is one of the better methods as you can be remembered on different computers.... eg work and home

[johnny86]

ngreenwood6,

 

The web isn't a safe place. There is no way to create a login system that is 100% safe. If someone really wanted, one could hack into any website. The thing is tough, what would he be able to do in a worst case scenario as a logged in user? Not much, he could just register and have the same privliges as anyone else, right?

 

Offcourse cookies can be stolen. But if you make them expire as the session ends they will disappear from the computer. You can't get ones cookies with JavaScript from another site. That's why you should worry about preventing XSS attacks to your site so that no one will be able to get those cookies.

 

In order to get the cookies, you'd have to be physically on the computer and take them. That could be the case in a public internet Café or something but even there users should logout and get their cookies destroyed that way. Or close the browser.

 

There are million of ways to get around the login system and there is absolutely no chance to make it 100% safe. You could for example mail some checking numbers for the users that are created and require the user to submit a checking number #123 which could be 243522. That would just kill the convenience of logging in with your account to always have to carry some paper with the numbers. Even that wouldn't improve anything at all in the matter.

 

The thing here is that we can worry about users giving out their cookies, passwords or any kind of identification keys you provide them. But what can you do about it? Not much. You can't control everyone else hacking into your users' computers and getting their cookies and saved passwords.

 

Even your banks website is insecure. If you carelessly forget your wallet somewhere, drop your banks information note somewhere or anything like that? What can the bank do about it -> nothing. If there was a safe login system, why would we need all those checking numbers and security numbers banks give us? Because there isn't one. All they want to do with those numbers is that they trust them to _you_ and hope to god you'll not going to lose them. Because the numbers ensures that even if your banking session is hijacked, they cannot do transfers without the numbers.

 

Web is anonymous, you can't identify anyone on your webpage.

[johnny86]

Even with HTTPS it's not a problem to sniff the data from the network and figure out whats going where. The data might be encrypted but the whole idea of encryption is that it can be decrypted at the other end. All the hacker needs is enough data to do calculations and comparsions to figure out how it can be decrypted. It only slows hackers down, doesn't stop them. Once they know how to decrypt it. They'll know what you send them and what they send you. And they can spoof whatever information they need to hack the site. You'll only be increasing your server load drasticly.

 

Users on the web should be aware of that web just isn't safe. You should never click on anything and you should never send anything to identify yourself (Even cookies). And yes all this improves security and takes care of most attackers. But if someone really wants and needs something they will get it.

[ngreenwood6]

@Zurev I am not concerned about users giving out there passwords. I am worried about malicious users stealing there cookies. Like johnny86 said cookies can be stolen using XSS attacks and therefore giving them access.

 

@johnny86 thanks for the help. I was pretty much under the same understanding when asking the question but just wanted to make sure that there wasnt something out there that I was missing. I guess I will put some checks in place for the login system and just make sure that no xss attacks are able to take place to keep my users safe.

[johnny86]

Yeah, I've been thinking about safe web a lot and it just isn't possible. =) But atleast when the user is trying to post something or change their profile info, you should always ask for their password to confirm the request. If the session is hijacked, the hacker won't know the password because he used cookies to grab the session. And in my opinion, any kind of passwords should not be stored in a cookie. They can be in session which is at the server. But always make sure you have them hashed with strong algorithms like blowfish. Because lets face it, our servers are also pretty vulnerable

 

Best way to affect security today is to do our (developers) part to the best it can be. And then try to educate our users to behave as they should on the web.

[ngreenwood6]

Yeah I agree. I never store anything that has anything to do with a user account where someone can actually see it. Usually it is just something that links it to that user account so that I can pull the account from it.

[mofm]

OK some people seem to think you can make a website 100% secure ..... you can't all you do its make it harder. What your asking is how do i let my code know if a users cookies have been sniffed. All you can really do is check it against the IP/user agent  etc etc witch can all be faked one way or another. If this isn't secure enough for you your next port of call is using encryption for all pages on your site this may be unpractical. The overheads of encryption can cause a lot of issues. And even then this isn't secure against man in the middle attacks so...... make your choice choose whats best for your situation and not necessarily the most secure.

Even with HTTPS it's not a problem to sniff the data from the network and figure out whats going where. The data might be encrypted but the whole idea of encryption is that it can be decrypted at the other end. All the hacker needs is enough data to do calculations and comparsions to figure out how it can be decrypted. It only slows hackers down, doesn't stop them. Once they know how to decrypt it. They'll know what you send them and what they send you. And they can spoof whatever information they need to hack the site. You'll only be increasing your server load drasticly.

 

Users on the web should be aware of that web just isn't safe. You should never click on anything and you should never send anything to identify yourself (Even cookies). And yes all this improves security and takes care of most attackers. But if someone really wants and needs something they will get it.

 

Today's encryption would take a ridiculously long time to crack its not really a viable option. man in the middle attacks are properly the option an hacker would go for.

 

Mofm