I have a Node / express app, using Passport for account creation and authentication. I'd like be able to check which sessions are active, ie., which users are currently logged in.
I could have a flag on each user's profile which is changed on login / logout, but I don't know how passport handles users who just close the browser and don't specifically go to the logout route, so I don't know if this flag would be set to false in that case.
What's the best way of achieving this?
My end game is to be able to tell the serve whether or not to send a notification email to a other user when they receive a message from someone else - if they're currently logged it, they won't get an email.
Ok, so if you have Passport set up, then the answer depends on what session storage you're using. Essentially, you'll query your session store to see what active users are there, but the actual mechanics of doing so will vary depending on your implementation. Once you know if a given user is considered active by the session store, you can decide to send the message or not.
However, the session store isn't infallible. No matter how you have your session expiration setup, it's almost impossible to guarantee that the store has perfect knowledge of all users; there is invariably some non-zero amount of time from when a user closes a browser window to when the session considers him or her offline.
So, even with that preemptive attempt to make sure a user is online before sending a message, if you want real reliable delivery, you will want to have your client code send back an acknowledgement of receipt. If the ack fails, then you can safely assume the user didn't get it and send the email after the fact.
Related
guys!
I got an expressjs application, an app service. On one of my routers the user will be redirected to another server(e.g: monkeyserver), some data is sent to monkeyserver (a random value, a url to send the user back to my expressjs application and some other stuff). The monkeyserver will send me back that random value so I can check if we are still friends.
So the doubt here is that random value variable(e.g: me_var). What's the simplest way for me to save that me_var so when the user is sent back to my app I can check if me_var value is still the same.
It's hard to understand the exact circumstances you're describing. If you have a way to identify a given http request as belonging to a particular user (session cookie created at user login is the usual way to do this), then you can store information for a particular user in a session store that is tied to the session cookie. Then, sometime later when the user returns, you can still access that same data that corresponds to that user. A session store may be long term persistent (database) or it may be shorter term only (memory store), depending upon how you implement your own session storage.
So, for your random value that will come back to you later in an URL, you can just store the original in the session store. Then, when the user comes back, that route they come back to can check the value in the URL (presumably as a query parameter) and compare it to the value in the session store to see if they still match and you can then act accordingly.
Hello fellow developers
I have obviously under estimated a thing when developing my first complex web site, where user creation and login is required.
It appears that cookies can be edited and modified by the user logged in, by using some developer tools i.e. in Google Chrome. That, I never gave a thought.
So, here is my issue.
When the user is logged in, I store the user name in a cookie.
If username-cookie is not blank, and I can find a user file with that name, the user is logged in, per se. Otherwise, no user is logged in.
When the user logs out, I simply expires the cookie, which works fine.
Now, the problem is, that a user obviously can edit the content of a cookie, outside the web application, or with javascript.
What would be the correct approach here to ensure, that the username cookie is not compromised in any way, other by my web application?
Making them read-only is not possible, I assume. Encrypting the cookie and then decrypting might work, I guess. Then, the cookie would be nonsense to the user, and if modified, result in a logout, as no valid username can be found upon decrypting the edited cookie.
I have stalked Googles cookies, and it appears that there are a lot of xxID cookies, which contains garbage. Does that mean, that encrypting/decrypting is the only way to make it work? I also considered some kind of login-ticket, but that would require a table lookup every time a user interacts with my web page.
Can anyone give me a hint as to what would be the correct approach?
Thanks in advance
Best regards,
Karsten Heitmann
You should look up session management for the language you are using.
The traditional approach is that when a user logs on, your application generates a long, cryptographically random token called the "session id" and sets that into a cookie. It stores data like who is logged in on the server side identified by the random value, so when a logged on user comes back, the browser sends the cookie with the random session id and the application can look up session data on the server side. This way an attacker has no way to guess a valid session id for a logged on user, assuming the session id is cryptographically random and long enough (which more precisely means it has enough entropy). Logging out means deleting the session data on the server side, and also removing the cookie, but that is not the most important part - the session will be invalid anyway.
Note that you should not code this yourself. You did not mention the language and environment you are developing in, but session management is rather tricky business if you want to secure it, and it is already provided by most languages / frameworks.
Just for curiosity, the encryption approach you mention is by the way a valid one. Some frameworks actually do that, but you should not attempt to code that either, because it is very easy to get it wrong, lots of things need to be taken care of to make it secure enough. Unfortunately an answer here is not the right format to go into details I'm afraid.
Btw you mention looking at Google. They use their own single sign-on solution, it is very complex compared to simple session management, so it's probably not the best example for you to look at. Find simple websites, most of those work the traditional way.
I am trying to setup a user login system with Node.js (Express), Socket.io, and Redux/ReactJS. This is the approach I'm taking:
The user connects through Socket.io as soon as he/she gets to the web app.
Through socketio-auth the user is required to authenticate and passes their username and password to the server.
Then, using socket.io-express-session, like in this example, I set a cookie with the user's username and password, so that every time they come back to the website they can be re-authenticated through socketio-auth. (I realize I could probably save a unique token in the cookie instead, would this be better?)
On the server, upon authentication, I just save their details with their socketId to the Redux store for use with every Socket.io request while the session lasts.
Assuming this is all done over SSL, is this safe? What changes would you suggest? I'm trying to make it as simple as possible yet still very safe.
It seems like point 3, with Local Storage, is the best way to go for now.
See someone else interrogation: https://github.com/hueniverse/hawk/issues/138#issuecomment-196989520
To counteract login session cookie theft, sniffing etc i've been thinking about this scheme.
i already read http://jaspan.com/improved_persistent_login_cookie_best_practice and what i wish to do is something less-complicated, maybe performance-wise faster too and something that blends well with both remember me functionality and normal session'ed login.
when registration is successful add session id to user(:uid) table and generate session cookie id for example d6c89ddba79b4f68be07bd874c5ff566 and store it in user browser.
When user visits another,the same page,refreshes it; another id will be generated and the current id in the user(:uid) table, the cookie in the user browser will be updated with the new one making the old one useless || invalid.
If an observer tries to steal the cookie, be it in unprotected connection, for example non-https website it will be rendered useless at user's next visit or refresh.
But... i'm sure there's a flaw somewhere in this logic. can the observer create a sort of time warping technique or do something locally to annihilate the benefits of such a scheme?
One concern comes to mind now.. i think it will be a possible situation that an observer steals the cookie when the user is afk or idle, then the observer refreshes the current page with that cookie or visits another one. the problem is that now the user is logged out while the observer has full grip of his account and can therefore change password if it's not a system where password change is confirmed through email or inserting current password before.
is that right? in that case, how could this scheme be enforced without bringing possibly extra complexity?
Yes, this is a good way to prevent session sharing:
the server will generate a new Session ID to store in the cookie every n number of requests. The Set-Cookie header will only be sent once, so if there are two browsers logged into the same session, one of them will be using the old, invalid session
is that right? in that case, how could this scheme be enforced without bringing possibly extra complexity?
As you say, you can get the user to confirm their password whenever a high security function is invoked such as password change. You could also get the system to confirm their password to continue the session in the case that session sharing is detected (i.e. some requests have been logged using the old session ID).
I'm writing a GWT application where users login and interact with their profile. I understand that each form entry needs to be validated on the server, however, I am unsure about potential security issues once the user has logged in.
Let me explain. My application (the relevant parts) works as follows:
1 - user enters email/pass
2 - this info is sent back to the server, a DB is queried, passwords are checked (which are salted and hashed)
3. if the passwords match the profile associated w/ the email, this is considered success
Now I am unsure whether or not it is safe to pass the profile ID back to the client, which would then be used to query the DB for information relevant to the user to be displayed on the profile page.
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
-Nick
What you are dealing with here is a session management issue. Ideally, you want a way to keep track of logged in users (using random values as the session key), know how long they have been idle, be able to extend sessions as the user is using the site, and expire sessions.
Simply passing the profile ID to the client, and relying on it to send it back for each request is not sufficient - you are correct with your concern.
You want to keep a list of sessions with expiration times in a database. Every time an action is executed that needs user permissions (which should be pretty much everything), check to see if the session is still valid, if it is, extend it by however long you want. If it is expired, kill the session completely and log the user out.
You can store your session keys in a cookie (you have to trust the client at some point), but make sure they are non-deterministic and have a very large keyspace so it cannot be brute forced to get a valid session.
Since you're logging a user in, you must be using a backend that supports sessions (PHP, .Net, JAVA, etc), as Stefan H. said. That means that you shouldn't keep any ids on your client side, since a simple id substitution might grant me full access to another user's account (depending on what functionality you expose on your client, of course).
Any server request to get sensitive info (or for any admin actions) for the logged in user should look something like getMyCreditCard(), setMyCreditCard(), etc (note that no unique ids are passed in).
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
Stefan H is correct that you can solve this via session management if your session keys are unguessable and unfixable.
Another way to solve it is to use crypto-primitives to prevent tampering with the ID.
For example, you can store a private key on your server and use it to sign the profile ID. On subsequent requests, your server can trust the profile ID if it passes the signature check.
Rule 1 - Avoid cooking up your own security solution and use existing tested approaches.
Rule 2 - If your server side is java then you should be thinking along the lines of jsessionid. Spring Security will give you a good starting point to manage session ids with additional security features. There will be similar existing frameworks across php too (i did not see server side language tags in the question).
Rule 3 - With GWT you come across javascript based security issues with Google Team documents and suggests XSRF and XSS security prevention steps. Reference - https://developers.google.com/web-toolkit/articles/security_for_gwt_applications