I have the following scenario:
A user logs in, a session entry via connect-redis which is valid for 2 weeks. The user can now access certain parts of the app using the session id that is stored in the app.
Now, if 1. the user deletes that cookie in the browser (with the session) and 2. logs in again - there are now 2 session entries in Redis associated with the same user, with the older one being obsolete.
What is the best way to deal with such old/obsolete sessions? Should I use a client library for redis, search through all sessions to find the ones that match the info of the currently logging in user (after she potentially manually removed the cookie), and purge these obsolete session; or is there a better way?
Gracias,
nik
That depends whether this (user deletes the cookie) is a common scenario and, if it is, whether there's a problem with obsolete cookies in the server.
Two potential "problems" that I can think of are:
Security - could the stale cookie be exploited for malicious intent? I do not see how that's possible, but I may be wrong(tm).
Storage - are the stale cookies taking too much (RAM) resources? If there's a lot of stale cookies and each cookie is large enough, this could become a problem.
Unless 1 or 2 applies to your use case, I don't see why you'd want to go through the trouble of "manually" cleansing old cookies. Assuming that you're giving a ttl value to each session (2 weeks?), outdated cookies would be purged automatically after that period so no extra action is needed to handle these.
Related
I've been reading about sessions, both client and server side as well as few attacks possible on them. I'd like to know what are the practical solutions to the following problems related to sessions
Race condition between two request trying to change the session variables
When session ids are regenerated, what happens to the slow requests that reach the server with older session id
For your first question, see here for how ASP.NET handles this - "Synchronizing Access to the Session State":
What if other pages attempt to concurrently access the session state?
In that case, the current request might end up working on inconsistent
data, or data that isn't up to date. Just to avoid this, the session
state module implements a reader/writer locking mechanism and queues
the access to state values. A page that has session-state write access
will hold a writer lock on the session until the request terminates.
For your second question this would be down to your code regenerating the session identifier at a suitable point. For example, to avoid session fixation it is good to regenerate the session identifier upon login. At this point there should not be other, slow requests being made to the server, so therefore this is an optimal time to issue a new identifier.
In other situations it may be appropriate for your application to recognise expired session identifiers for a short time, and associate them to the new identifier until all connections have been closed.
I wrote a simple webserver with nodejs and express. I implemented an user authentication with email username and password. Furthermore I have a remember-function which stores the user id and pwd hash into a cookie. Now I would like an extra session that ends when the user will close his browser or click to the logout button.
Which way is the best practice for implementation? Is the session the same like the remember-function with an expire time and in each request I must check the credentials against the database? (I'm not that sure about this)
Technologies that I'm using: nodejs, express, mongodb
This is not a nodejs question only, I would prefer a general explanation for the problem.
Let me get this out of the way first; Storing the password hash into a cookie would allow anyone to login when they have the password hash and that would be disastrous if the password hashes ever got exposed for some reason. Encrypting cookies is just fine, but don't allow the actual hash you store in the database to be used for authentication. Ever.
About re-authentication, Node is a technology that operates on a single thread and is scaled by running more instances over multiple processors and/or machines. Keeping sessions is a good idea to avoid trips to the database, but you have to think about the architecture as well. What happens if you, say, use sessions stored in files (ala PHP) and you need to scale to multiple machines? Nothing good, at least. So you need a central point to keep track of the sessions.
This can be either your database (MongoDB) or something such as Redis, or another centralized mechanism allowing you to check sessions. Either way, you will have to spend time doing the request and retrieving the session values for the client. If you do not have additional values you need to store it makes no sense to create a dedicated session architecture (that needs expiration, and so forth) and just doing the authentication again is the easiest and most logical solution.
Personally I almost never need sessions and just do authentication again.
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
I have a question concerning cookie storage design. I am developing a web application which should cache it's server-fetched data to a local storage. No user credentials will be stored.
What is in the cookie:
list of data and it's properties
proof for up-to-dateness
Proof for up-to-dateness will not be a hash, but most likely a timestamp of the last write to the server which is checked against the DB. This is to ensure the user gets valid info if he has used the website on another browser/computer/device and is out of sync.
The cookie should be able to handle more than one user in it and most probably some sort of encryption so other people can't see plain-text data. Military-grade security isn't needed here as the information here is not so important. But everything hacked in less than 30-60 minutes should be considered unsafe.
Questions:
How to encrypt my data
How to enable the cookie for multiple users
How to prevent the cookie from being stolen
What would be a good and simple way to present the option to disable cookie caching and explain to my users the risks of using caching on public computers
Is the whole idea any good at all
What are some potential issues I haven't accounted for
I'll answer #5 (which renders the rest of the questions moot).
Cookies aren't designed for that sort of thing. They are make a round trip with every HTTP requests - including on same domain CSS, images, JS, etc.
I suggest you look at HTML 5 local storage or just sending the data down to the browser every time with a minimal key cookie.
For #3 - there isn't a way to fool proof way prevent someone from stealing a cookie or forging a duplicate.
How do i remember sessions, even after browser is closed.
is there any alternative than extending expire time of cookies.
i am using code igniter
I implement my version based on this article. The article explain a concept, security, and how to implement persistent login cookie.
The summary of what I done is:
Create a table to hold persistent cookie series and token (series is needed to detect if the cookies got stolen).
I write the model to create required cookies (separated from normal CI session).
The model also do database
read/write of the used persistent
cookies.
I integrate this model to existing user model that handle
normal authentication.
When user go to page that need relaxed authentication, without
normal CI session, but have
persistent cookie session in his
browser, my code will recognize it
since the same series and token also
stored in the database. The user
will got a normal CI session, but
with a flag that this session is
generated from persistent cookies,
not from login form.
When the user go to 'sensitive' page that demand a CI session
without persistent flag, then user
will be logged of, and sent to login
form (if you use yahoo mail, then it
similar with that). This usually the
page where user can do
add/edit/delete, and see sensitive
information.
I hope this help.
The cookies is that only solution i suspect. As you said, you need to extend the time. However if you wanted to use PHP sessions instead, you to make sessions life longer using php.ini file but i don't think using sessions for this purpose will be a good idea because data of sessions is stored on server rather than individual user.
Thanks