CODEWITHSUNDEEP
phpsecurityauthentication
gosukiwi
gosukiwi

Reputation: 1575

PHP Stateless Authentication

I'm not new to PHP, but for authentication I've always used sessions. Now I'd like to make stateless authentication, so I can't use sessions, because there might be many server instances, and they won't share session data, so what I thought is have a session table on my database, and do the following:

Something like this

id   | token        | ip         | key       | data
1    | a-guid       | 190.0.0.1  | username  | encrypted-data
2    | a-guid       | 190.0.0.1  | is_logged | more-encrypted-data 
3    | other-guid   | 190.2.2.2  | is_logged | some-more-data

So the user with a cookie with token a-guid and ip 190.0.0.1 can access username and *is_logged*

But I'm not sure about security, if someone could somehow get your token from your cookies, and your ip, and he/she could send a request with your cookie token and your ip, it would have complete access to your account.

Should I have some special considerations?

Upvotes: 1

Views: 2658

Answers (2)

Decent Dabbler
Decent Dabbler

Reputation: 22783

You seem to have the same misconceptions about the mechanisms of sessions, that a lot of people have. Even though there are a few mechanisms in which PHP is able to track sessions, the most typical way sessions are tracked is already by exactly the same mechanism you are proposing, namely: by using a plain old regular cookie with some unique token.

The thing that differentiates the way PHP sessions utilize cookies from the way cookies are otherwise typically used, is that sessions don't set any expiration date on the cookie (thus causing the browser to typically discard them when you close the browser), and (and this is where your proposed method corresponds) only filling the cookie with a session id (similar to your proposed token) as its data.

So then, where does that leave us? Well, for one thing... the security concern you have (intercepting your proposed token) is relevant to regular sessions as well (intercepting the session id). If you want to avoid this security concern, you'd have to start utilizing secure transfers (HTTPS using SSL/TLS).

And as far as using a central session table, as you proposed... this is indeed a common route to take. And what do you know? PHP already has a mechanism in place to 'easily' take care of this with regular sessions, namely session_set_save_handler().

This function allows you register functions (or since 5.4 an object with interface SessionHandlerInterface) that read and write to any persistent storage you seem fit. This could mean some session table in your database as well. Be aware though that writing these functions/methods can be tricky. But you can probably find good examples on the web and/or Stack Overflow.

Upvotes: 4

ethrbunny
ethrbunny

Reputation: 10479

What if you create a random string when they authenticate, save this in the DB for the session and use it to encrypt the above information? Any server that got the token could use the stored secret to decrypt the session but it couldn't be faked by a third party.

All that you'd save in the cookie would be the encrypted data plus some value used to look up the secret.

Upvotes: -1

Related Questions