PHP: Remember Me and security?
Asked Answered
S

1

9

During the time I've spent taking breaks from learning how PHP supports Unicode I've been delving into making my "Remember Me" cookies a bit more secure. However there are a few things I don't understand and a few of my own musings I'd like some suggestions and opinions on.

1) Is there any method to adopting a "Remember Me" feature that doesn't involve cookies? Curious since there are obvious security flaws in storing authentication cookies. Not that there aren't security risks in just about everything.

2) Since I'm not working with a bank or "highly sensitive" information, is it necessary to require users to enter their passwords for the more "high profile" areas? It seems that remembering a login would be a waste if we're just going to ask them to essentially log in anyway two minutes later.

3) What's the absolute best method for storing an authentication cookie (aside from "not at all")? I have currently coded that area to set a single token in the cookie (hashed using time(), their user agent, remote_addr, and a salt - sha256). When said user comes back it checks the 'sessions' table for the token, then matches IP to IP to log them in. If the token is there but the IP doesn't match it silently unsets the cookie and asks them to log in as if they didn't have one.

Thanks again everyone.

Sales answered 20/1, 2011 at 4:55 Comment(1)
You should re-use an existing authentication framework whenever possible, because, really, it's complex. For example, take a look at github.com/delight-im/PHP-Auth You will need some persistent storage on the client side for what you're trying to do -- and thus cookies are the ideal choice.Sociology
W
6
  1. Essentially, no. It requires some sort of storage on the client side; you have no way to know who a client is without a cookie (or similar, like HTML 5 client-side storage).

  2. That is a trade-off you must decide. Minimum, the old password or some other form of confirmation (e-mail?) should be required to change it to a new one.

  3. You can't absolutely protect against cookie theft and subsequent impersonation unless you encrypt all the communications. That's the only secure method. Sure, associating an IP, user-agent etc. to the cookie might be helpful, but it's easier and much more secure to rely on encryption. (I misunderstood the point here -- what's important in the value of the cookie is that it's random, so you ought to change your generational method to be less predictable)

Wideeyed answered 20/1, 2011 at 5:2 Comment(4)
1) Didn't think so, but I thought it might have been worth asking anyway for possible radical ideas. ;) 2) I would definitely require the old password to update any information such as email, username, password, etc. I mainly meant for things like purchasing anything (it is a gamesite so users will have options such as that), trading with other users, that sort of thing. 3) I was actually referring to the system of storage/checking (the way it works per my initial desription) as opposed to encryption or no encryption.Sales
@Zyd Ah I thought you were saying you accepted only a certain cookie if the the IP, user-agent etc. matched. The only requirement of the cookie is that it's random enough so it can't be guessed. The method you're using is not very good because it's a bit predictable -- though the salt, if big enough, could offset this. In any case, you ought to change it.Wideeyed
To be clearer: Use HTTPS and set the secure flag on cookies, that avoids most forms of cookie hijacking (unless the user's machine is compromised).Tenpin
I could easily change it to only accept if the user-agent matched as well (so far I'm only checking to make sure the IP is the same). However setting a salted and hashed token and checking that token against the IP was the only method I could find that was "the most secure" so if you know of a better way I'd love to hear about it. And yes, as it is now it's not really all too predictable due to the addition of the salt.Sales

© 2022 - 2024 — McMap. All rights reserved.