Wondering how this is typically implemented. Examples of always logged in websites are StackOverflow, Facebook, and Twitter. It seems like you'd have to have a background job regenerating the session ID (assuming you store session by ID in a database) before the session expires (say you tell the cookie to expire in 5 minutes). So every 5 minutes every session would be regenerated to keep it logged in while also keeping it secure. But before going down that road I'd like to know if this is how others implement it or if there is a more standard approach.
As far as I know, this is how it is done in majority of websites.
A cookie is set with an access token and limited life(of course, if the user checks on'Keep me logged in'). If the user comes to visit the site within that timespan, he is logged in and a current session is generated(from the server). And, the cookie timespan is reinitialized to the pre-decided time.
Say for example: I log in to a website example.com and check its check box, to keep me logged in. Now, as soon as I click the login button and and validated by the server, the server generates a session(for current session) and a cookie(for future sessions), with a time limit of say 1 month. Now, If i come back on say 29th day and open example.com, I shall automatically logged in using the token set in the cookie. The cookie will send my info to the server and the server shall generate my current session. Most importantly, the server will reset the cookie to expire after one month.
If, I return to the website after 30 days, then the cookie will either force me to login again.
I hope my input would be of some help to you.
Related
Im implementing a persistent cookie based on http://jaspan.com/improved_persistent_login_cookie_best_practice.
Question :
If a user tries to access a page. After the authentication is successful, the used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
When you generate a new cookie here, you need a cookie age, I put it as default of 1 month. So, every time the new cookie is generated, should I just put it as default(1 month) or should I store a field in my db which counts the expiry time(something like 1 month countdown). Whats the normal behaviour here ?
Another question, I feel that it is a bit overkill to remove the token and gerenate a new token to db everytime you visit a page. Is this operation as costly as I thought?
Add the expiry both server and client-side, otherwise a cookie grabbed by an attacker would be valid forever.
Changing the token is good and can help protect against the above scenario. Every page visit seems a bit excessive, and could have a performance impact if your site gets busy. How about refreshing it every 5 minutes or so?
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).
Is it possible to create a session cookie (one that is automatically deleted when the browser closes) AND also has an expiration so that it will expire after a set time, let's say 15 minutes unless the user continues using the site? If they use the site, i'd like to reset the expiration so it lasts another 15 minutes.
I've only really had luck with either creating a session cookie that expires when the browser is closed OR stays around as a persistent cookie but has an expiration either using expires or maxAge arguments.
The only thing I can think of is to create a session cookie that has a timestamp value stored in it and in the session middleware, check of the current time > the timestamp value and then deny the request and delete the cookie by setting it to null. If current time is <= the timestamp updating the timestamp to the new date effectively extending the session timeout.
While my idea may work, it makes me think there is a more official way of accomplishing what I want.
I'm currently experimenting with node and express so any insight that is tailored for that build-out would be appreciated.
Because the way you create a session cookie is to leave out the expiration, you can't really do it with a single cookie.
But, you can do it with two cookies, one session cookie and one expiring cookie. Here's some logic for doing it with two cookies:
Create a random number.
Create a session cookie such as session=randomNumber.
Create a second cookie expiry=randomNumber that expires in 15 minutes.
Have your code check to see that both cookies exist and contain the same random number.
If the browser is closed, the session cookie will be deleted.
If 15 minutes passes, the second cookie will be deleted.
If the browser is closed and then reopened, there won't be a session cookie and even if you coin another one, the second cookie won't have the same random number in it.
By checking for the presence of both cookies, you're making sure that both conditions have been met.
And, if you want the 15 minute cookie to continually refresh itself on any page load, you can have your server recreate that cookie on each page load with a new fresh time 15 minutes from now.
How to get session timeout of Domino server in XPages-SSJS. I want to prompt user to save his/her data before session expires. Thanks
Servers only communicate with users when those users make a request to the server.
Because of this, servers cannot send information to the user if they haven't requested it.
For example:
A user requests a page from a server.
The server sends that page back to the user, and creates a session
for that user. The session is set to expire in 5 minutes.
Those 5 minutes are up, and in the meantime the user hasn't requested
any further pages. So the users session ends, but because the user
isn't making any requests, the server has no way of communicating this
to the user.
This is just the way that HTTP traffic is designed to work. There are ways around this however, and by altering the example above I will show you one of the easiest ways:
A user requests a page from a server.
The server sends that page back to the user, and creates a session
for that user. The session is set to expire in 5 minutes. The page that the
server sends back has a javascript setTimeout function which is set to fire off just before the session of the server expires.
Those 5 minutes are up, and again, the user hasn't requested
any further pages. So the users session ends and the server has no way of communicating this
to the user. However, javascript on the page knows that the session on the server is due to expire, and fires off an alert to tell the user to save their work.
In SSJS you can get the setting of the SessionTimeout with the following code:
facesContext.getApplication().getApplicationProperty("xsp.session.timeout", "30");
But this is a static value (in minutes). The session expires in X minutes (30 is default) after the last request of the current session.
Well the timeout is reset with every interaction between server and client. So what could be done is basically have a count down on the client side that resets after every new request. And that could also be used client side to trigger a save interaction for a defined time prior to the actual session timeout.
Whether this makes sense or not is debatable... Alternatively auto-saving could be implemented aswell.
Really weird authentication problem going on - hope someone can help!
The Domino Web Server Log database shows all the requests a particular user is making for pages in an application I look after. The application is XPages-based and the user is regularly pressing Save on the document she is editing (every few minutes). The save does a full update.
The LTPA token is valid for 30 minutes - I assume however that every time the user performs a full update, the 30 minute token is renewed?
However, when looking at the logs, a save of the document at 09:05 shows the Remote User by name, another save at 09:07 still shows the user by name. The next save at 09:11 shows the remote user by IP address instead, and when you look at the log entry in more detail, the server has replied with 401 UNAUTHORIZED (The client is not authorized to access data). This has of course caused the user's browser to lose the work they had open at the time.
The Cookie on each log entry shows :
LtpaToken=AAECAzUwOUI2RjRCNTA5Qjc2NTNDTj1Bbm5lIExhdm91ZS9PVT1VSy9PPVJVSyvsCs5c4tITD9elgI0BCN5CnZ0O; SessionID=DBDFDKDGTI
The same LTPA Token and session ID for entries where the save document worked, as well as where it failed.
Unsurprisingly, they have then refreshed the session by closing the web page and going back in to it following the error and they get a new LTPA token and session ID.
The LTPA Token validity setting of 30 minutes I refer to is defined by our admins in a Web SSO Configuration document for the server, in the "Server\Internet Sites" view in the NAB. It's the Token Expirations (Minutes) setting. Am I completely misunderstanding this setting - should the timeout be renewed everytime the user does a full submit to the server? Or is something else going on here?
I don't think the token is renewed. It times out no matter if the user is active or not.
You could increase the expiration timeout to a reasonable high value and then add a lower minimum timeout to ensure that sessions doesn't timeout too soon.
Here's an example where expiration is set very high and timeout is set to 2 hours: