I have a Mothership domain, and if you log into it, a token is created in the database for your login with user Id, created datetime, expiry datetime and user agent. The expiry is set to an hour after the token was made (created when the user logins).
To be able to login from Mothership to Scoutship, I append a query string like so
<a href="http://www.spaceship.com?user=ahs6588ads6d8das">go to spaceship</a>
Then on the scoutship, it looks up the database like so:
$query = "SELECT user_id FROM user_tokens
WHERE token = $tokenFromUrl
AND user_agent = $thisUserAgent
AND expires > NOW()
LIMIT 1";
If it finds a match, it logins the user, and then sends location headers to remove the query string.
Obviously, if someone accessed that URL, it will log them in as whoever it is (provided they came within the hour of login of the old site, and have the same user agent string). This to me doesn't sound as secure as it should.
Is there a way to beef up this security? Should I have a column in the db like has_auto_logged_in
and set it to TRUE for the first lookup, and deny all incoming requests after that?
Many thanks
Here is what I came up with
So, is the only way one could defeat this is if person A is on the site and person B (hacker)
Is there much more you could do besides this? You could probably put am AJAX script that gets a new hash and updates the links, but is that more trouble than it's worth?
Try a nonce. I even reserve a table for stuff like this
When the user is going to be redirected, create a random hash based on the time, user id, etc. Send that over the URL. When the URL redirects and it tries to log the user in on the other side, it checks if the nonce is in the database. If it is, it logs the user in and deletes the nonce. If it isn't, it denies the user.
You can even add an expiration.
Thats the way security works in many implementations. You can see these when having a SID-parameter in url or cookie. The only way to make these more secure is to use a larger id.