In my web application I would like to show the user if he/she is already logged in on another machine. Also I would like to provide the user with the option to sign out of all machines except the current one.
Now I'm talking about session logins, not active sessions so updating a last_activity column isn't going to do the trick.
Now I assume the (only) way to achieve this is to decrypt the session payloads from the database and checking the Auth id from there. This is quite a heavy operation to do for every page request for 1000 logged in users.
Am I correct in this guess? Is this the correct (or only?) way to do it? Is there a better way to do this? If decrypting the Session payload is indeed the best option, how do I do this? I tried using Crypt::decrypt($session->payload) but I get 'Invalid Data' from the Crypt class.
Related
I'm developing a login page for a very small site, and for the "remember me button",
I use the user-id which then I encrypt before placing it in the cookie, and when i want to check if he already has a cookie, i uncrypt the value and connect with the user-id given.
But I'm sure that's not secured enough and people will just have to set a cookie with a random value with encrypting and this will make the job, isn't it ?
As solution to this could be to generate a random token, put it in cookie and in database. Then, if you have the token, you can connect.
If user get stolen this token, this is not the page problem isn't it ?
But I don't know how to process differently..
Anyone has a solution ?
To simply answer the asked question: You can't.
Cookies are stored on the users computer and with enough access rights and/or knowledge the user will be able to delete or modify any cookies your website set.
Encryption is taking information and make into non-sense so no one can access the information. If you need encryption is up to you. But I think this kind of session management is implemented already in a lot of ways. One of the simpler would be some kind of "dynamic API Token"-implementation - Storing some kind of Hash-like String in the cookie and in DB. If they match -> login, if not -> logout. (Symfony example: https://symfony.com/doc/current/security/custom_authenticator.html )
Another one would be JWT (JSON Web Tokens), these are indeed encrypted because they send information back and forth.
If you want to implement something like this yourself I would suggest to look at documentation about these two to start.
I’m using Symfony2.1, a very simple login form based on documentation (http://symfony.com/doc/current/book/security.html#using-a-traditional-login-form) and a custom authentication success handler.
Anonymous user can do some action which are stored in database with the user's session ID. Now the user is logging into the system and I want to update saved actions with user's ID so that logged user can continue its work . Unfortunately in success handler I have already an updated session ID and I don’t know which records in action's table belongs to user (since they are stored with old session ID that I can’t access to [or can I?]).
What is the best practice to handle this kind of situations. Should actions be saved in database with token stored in cookie instead of session id or is there a build in mechanism and I’m trying reinvent the wheel or maybe I’m asking wrong question and therefore I can’t find answer.
The default mechanism of generating a new session id on an access level change is best practise. You could write your own authentication that does something with the new and old session ID. But unless you really know what you are doing security and authentication code is best left alone.
Best method would be as you suggest to save a token in the database and in a cookie and track your users with that. Don't forget to clean up the used tokens in the database and cookies if you no longer need them.
I have a really, really poor understanding around security and safety when building websites - what I want to do is store the information the user enters to log in into a cookie so that I can do two things:
Check the cookie from flash (via a php file) to grab information about a logged in user (if at all). This will be used for highscore APIs, etc.
Automatically log in a user when they come back to my site.
The site itself doesn't really have any important information etc, so I mean it doesn't have the be the most secure thing on earth (or even close). But I'd like it to not be tampered with if possible.
From my understanding, storing user information in a cookie can be bad because the user can just alter the cookie and be logged in as someone else.
I was thinking; is it reasonably safe to do something like this?:
When the user logs in, store an MD5'd version of their email address (used to log in). This way at least it's extremely unlikely that they will be able to modify the information to reflect another user in the database.
Because someone could just MD5 an email address that they know someone else uses for the site and change their cookie to reflect that, should I maybe store their MD5'd password alongside it and then use these to attempt a login at every page? Only thing is that this seems like it would be slow/non-strategic because it's needing to basically re-login with the information in the cookie every page.
This approach probably seems really strange, but would it work fine? The main requirement I have is that if the user is logged into my site, playing my flash games anywhere on the internet will automatically pick up that they're logged in and work with their information.
Use PHP sessions.
Php stores the session id in a cookie on the browser, and everything else in the session is stored on the server. Your flash script should be able to the the session id from that cookie and maybe you can write a php file that will return the information that the flash file needs when the flash file passes in the session id?
Because session ids are more or less random, it is difficult for the user to change their session cookie and accidentially access the login of another user.
I have developed a web application in PHP for a client. The client is now renting out access to the system to another company on a per user basis.
Is there a way to prevent the secondary company to use a single login and give it to 20 people to use at the same time? I know one can get the IP address of the client machine that is being logged in from, but this is obviously not very reliable method. The answer probably lies in a combination of cookies and tracking things in a database, but my brain gets a bit stuck thinking on how to implement a strategy here.
Create a unique session ID when a user logs in and store that in the DB. Add something to the session authentication code (run on all page visits) that checks that the user's session ID is equal to the one in the DB and if not, log them out. Then your web app will be accessible by only one user at a time.
To be completely honest though, can't you raise this issue with your client?
No way to tell if the login is shared among 20 people. You can restrict access by blocking simultaneous usage thru session cookies.
Most of all, protect yourself with a published Terms and Conditions document. Violation of which - revokes any standing agreement/contract. And sue them if you can provide evidence (logs) that they violated it.
Make sure you bind one user to one session. In that way you can generate a warning screen if somebody uses the same login with another session. You can then let the user choose to close the other session.
In that way you can make sure two users are not using the system at the same time. It's a bit like a software program you have installed on a computer: multiple users can use it, but only one at a time. This is probably fine.
If you don't want that, you should try to bind the login more firmly to the user: make sure he logs in with a personal e-mail address, and he gets notifications (if applicable) via e-mail. Also let the user set personal configurations. In that way you create extra value for users to have their own account.
If you have a login you have authentication, and you write any user id in session, make sure that only one session with this id created, if the session already exists throw error message.
The only problem you will have in case and user did not logout properly, instead of it pressing x button on browser then he will not be able to login till session s not expired.
I'm working a site where users could technically stay logged in forever, as long as they never close their browser (and therefore never get a new session key). Here's what I could see happening: a user leaves a browser open on computer A. The then use computer B, login and change their name which is stored in the session. They logout of B, but A is still logged in and still has their old name stored in the session. Therefore, their name won't be updated till the next time they logout manually or they close their browser and open it again and are logged in through the remember me function.
Name is a simple example, but in my case the subscription level of their account is stored in the session and can be changed.
How do you deal with this?
A few ideas that I have are:
After a period of 10 minutes or more, the session data get's reloaded. It might be exactly 10 minutes if the user is highly active as the function will get triggered right at the 10 minute point or it could be after 2 hours if the user leaves and comes back and then triggers the functionality.
Store as little information as possible in the session and load the rest from the DB on every page call. (I really don't like this idea.)
Use database sessions and use the same session on all the computers. I like this, but I could see it getting confusing when something like search criteria are stored in the session--the same criteria would show up on both browsers/comptuers.
For information, even such as the user's name or username/email address, store it in the session, but for other information that would heavily affect their abilities on the site, don't store it in the session and load when needed (attempt to only do it once per instance).
Are there other better methods?
--
Another option: 5. Use database session and when an update is made load the user's other sessions (just unserialize), change the relevant information and save them back to the database.
I would go either with number 1 or number 4. If you store the time of the last update of the information, you could even ask on every request whether the date has been updated.
Don't store information likely to change in the session, if you're looking at scenarios like the one you outline. Just get over your dislike of loading user data with every page - it's by far the best idea.
I'm guessing you don't want to load the data from the database because you're concerned about performance issues somehow. Before you try out any of the other solutions, you might want to test how long it takes to actually load a users data from the database, then check that against your number of users - chances are you won't see any performance problems due to loading user profiles on every page.
Regards
I'd go with option 6: only store userid and session specific stuff (search criteria) in his session and put the rest into APC/xcache (memcached if you're using multiple servers).
this way you'll only have to go to the database the first time (and after the cache expires) and you can still share any data between users sessions.
Normally you should do 2), but you don't like it.
maybe you can use sessions stored in db.
when a user change his name, put into all sessions from that user the information "refresh userdata".
on the next request the userdata is reloaded again into the session and is cached there.
this can be done be reusing your loaduserdata function which called at login.
php session_set_save_handler() - also read comments
php session_decode() - to read the username from the session to store it additionally to the sessiondata. usefull for easily to find the users sessions for updating.
[edit]
don't forget:
when you are updating all the sessions while the page is generated (between session_start and session_write_close) you changes maybe lost.