I have some problem in this specific scenario:
If my XPages application
If I have my Domino HTTP configure with Single server setting the Ext.lib Keep-Alive control work well...and my session don't expire.
But I I use Domino HTTP configured with Multiple SSO (LPTAtoken) with Firebug I see the Ext.lib Keep-Alive control work well (I see the PING request) but I don't know because my session expire.
Have someone any suggest for me?
Tnx you
p.s. my release in 9 social on linux 32 bit
What kind of key did you use when you created the LTPA token?
When using WebSphere LTPA keys, a token is assigned and it will expire when the time specified in the field Expiration (minutes) elapses, no matter whether you are actively using your application or not.
When examining the documentation for products that use WebSphere server (Sametime, Connections) I found that IBM suggests to set Expiration time to a long interval (such as 600) minutes to minimize the risk of users being logged out in the middle of a working day. I admit that this does not sound like a good suggestion security-wise.
I assume it is the same when using Domino LTPA keys, with the added option of being able to specify Idle Session Timeout.
So, you can either increase the token expiration interval (depending on your requirements this could be an easy fix) or go with Stephan's suggestion. I don't know how to code his approach, but if I find a solution, I'll update this answer.
In a single server setting the server tracks the validity of the cookie. So whenever you hit the server it is updated. In a multi server environment you get a new cookie before expiry. So you need to process the incoming cookie to replace the predecessor. Easiest way using a regular page and an iframe
Related
A little background: I am going to be constructing a webserver, likely the most up to date version of apache when I get around to it. It is going to be updated with sensory information from a makeshift security system I have.
As a counterpart, I am designing an app to go along with it, that will automatically contact the webserver and pull the sensory information about once every 1.5 minutes.
I want to have an authentication method so that the average Bob can't see this information, mostly due to the fact that there will be some command and control as part of the server as well.
The question: I feel like a simple username and password is the wrong way to go about this since it isn't dynamic and theoretically seeing the same credentials sent that frequent could be dangerous, so is there any other authentication method that could mitigate this?
The question pt. 2: Obviously I want an encrypted channel, will https stumble over itself if it tries to renegotiate every minute and a half?
I haven't begun this project yet much less chosen any language to write it in, meaning I am super open minded to suggestions, any help is greatly appreciated.
The question: I feel like a simple username and password is the wrong
way to go about this since it isn't dynamic and theoretically seeing
the same credentials sent that frequent could be dangerous, so is
there any other authentication method that could mitigate this?
You could use Google Sign-In to allow log on via a Google account.
Or you could implement two factor authentication with say Google Authenticator or via SMS to prove that the user logging in has more than one factor of authentication. These factors could be:
Something you know (e.g. password)
Something you have (e.g. phone that provides a One Time Password)
Edit: Having re-read your question - yes you are fine to authenticate with username and password (over HTTPS), however you should then store a session identifier client-side and simply send this in future rather than the username/password each time. This is more secure as it can be stored safely client-side, and if exposed the identifier can be easily revoked.
The question pt. 2: Obviously I want an encrypted channel, will https
stumble over itself if it tries to renegotiate every minute and a half?
Nope, this is what it is designed for. Browsers will keep open an HTTPS connection for a length of time. Additionally, they will use session resumption rather than executing a full HTTPS handshake in the case that a new connection needs to be established. Session resumption is much quicker than establishing a completely new session. See this article on the CloudFlare blog for more info.
We modified our Session handling from cookie based to URL Rewriting. By doing this the session id gets transmitted as part of the URL.
Now there is a vulnerability issue, where whoever uses this URL will be able to log in into the system.
To resolve this issue we have done the following
[1] A HTTP Session Listener has been created to maintain list of HTTP sessions.
Listener reacts on the events when session are created or destroyed.
[2] A Session Filter has been created to verify HTTP Session and check its integrity against HTTP Request attributes
Session will be invalidated in case Request attributes (identifying the client origin) do not match original attributes stored with session. (to block the session hijack attempt)
However i think that this has a gap, when you are trying to access over a proxy etc.
Is there any other effective solution for this?
Also we cannot use third party libraries to resolve this because of the nature of the produce.
So you need to be doubly careful with session ID likes this: users share URLs! The definitive advice on the subject comes from OWASP:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
But I think you should consider the following additional controls:
Rotating the session key on each request. This is only practical with simple web applications though. It'll cause problems undoubtedly with AJAX and might be difficult to manage if the user is likely to open a second tab on the application.
Shorter timeouts.
I am presuming that in the 'HTTP Request Attributes' you mention you are already picking up the User-agent, source IP address and invalidating the session if these are inconsistent.
If you are using SSL it might be possible to do a great solution where the session ID is tied to the SSL connection (Apache, for example, exposes this in a SSL_SESSION_ID environment variable). But this information might not be available to your application.
If you put sit Paros on the traffic between your browser and a web application being hosted in WebSphere, you will have two session identifiers passed as part of the cookie section of the HTTP request:
A JSESSIONID. This is your HTTPSession ID as far as I can tell.
An LTPA2 token. This is your “single sign on” session as far as websphere is concerned.
Now, IBM say that a single hosted application cannot invalidate the LTPA2 token when a user is signing out. The thinking behind this is that it is an SSO identifier, so a single application should not be able to invalidate it as it is intended for use across multiple applications. There is no configuration in WAS to declare “this environment hosts only one application so therefore that app can invalidate the LTPA2 token”.
What is worrying is that these LTPA2 sessions hang around for a configurable amount of time. Therefore, if another user got a handle on a users’ LTPA2 token, they can use it to access that users’ session and therefore their sensitive data.
You can prevent a man in the middle attack to capture the session value by forcing the transmission of the cookie to occur over SSL, and by specifying HTTP only for cookies. However, I am still worried about the cookie being available on the local machines’ hard drive. The browser has to store it somewhere, so therefore there has got to be a way to get access to it?
My question is, is it possible for someone to get an LTPA2 value such as this from the hard drive? Say someone sits down in a library, signs in to their online banking, does some work and then logs out. Is it possible for the next user to get the LTPA2 token somehow?
I tried searching through the directories where I thought FireFox 4 and IE8 would store the cookie, but couldn’t pattern match the value. My gut instinct is that it may be possible to find this data on certain browsers?
By default the LTPA2 token is a "Session Cookie" Websphere does not set an expiry on that cookie, and it is just stored in Browser Memory until the user closes their browser.
Unless your client is explicitly manually pulling that cookie and storing it client side, it will not be stored in any files on the user's machine.
You can invalidate the LTPA token if you want to.
But this would require using IBM extensions (naturally)
Look at these:
(a) http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html
LTPA token is non-standard, but is simply a credential/token and does not impact the application development team.
Redirects to the ibm_security_logout URL in order to remove the LTPA token when users log out.
(b) ftp://ftp.software.ibm.com/software/dw/wes/0409_botzum/WAS-511-Security-AdvancedTopics.pdf
Though these articles are old, these should still work (as these basics haven't changed a lot over the years)
By invalidating the LTPA token(which as Terrell mentioned in a "in memory session cookie" )all your worries that you had should be gone.
HTH
Manglu
I've implemented an login on a site (didnt use asp.net default). When a user logged in I save his ip in the db. If he doesnt doing anything in X min his ip get deleted. Whenever a user trying to enter a page that is restricted I check if his ip is on the db. If so he can continue.
The problem is that if the logged on user is on a wifi network or any other shared network, all the other users will have the same ip, and thats not good. How can I overcome this problem? Is cookies the best answer?
How is the user logging in? Username/Password? I'm assuming the password is stored as a salted hash in the database, so why not pass a cookie back with the user's username and hashed password? Whenever they try and access a restricted area check that username/password hash against your database. Make sure to sanatize the cookie values before checking them against your database to prevent injection. Or, depending on the language this is in, you could use session tracking.
I'm assuming by the tags that you're using WebLogic Server for your solution, although your comment about ASP.net makes me wonder. (although no ASP tags set for the question?)
The short answer is that you're making life harder than it needs to be - if I understand your problem correctly - that you want an idle user's session to be timed out after a certain period of inactivity for security reasons - then you can do this via application configuration with the session-timeout parameter:
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webapp/web_xml.html#1017275
Wherever possible when security's involved, I always prefer to avoid rolling my own solution. Just not smart enough to trust it. :-)
Apologies if I'm off in my understanding here.
I had an authentication problem in cakephp, when positing credentials from an external site the authentication would work, and then get immediately lost, with the site prompting for login information again.
This guy determined that the cakephp session cookie was changing. His solution was to set security to low.
Seems like in medium or high security Cake makes a double check for
referer... but with low security works fine when clicking auth-
protected links from external sites like hotmail or yahoo
This solution also worked for me, but what I am losing by setting cakephp to 'low' security?
When security is high, a new session ID get generated on every request. It is practically impossible to create a single-sign-on solution between two applications by sharing a session cookie in this case, since Cake will constantly change the session ID without notifying the other application.
When security is medium (or higher), session.referer_check is enabled.
When security is low, you don't have either of the above features, but it is still just as secure as any average PHP website/CMS out there.
The main thing that I know of is the session timeout, as per the app/config/core.php comments, in that your session timeout will be multiplied by a lower number.
The book backs this up,
The level of CakePHP security. The session timeout time defined in 'Session.timeout' is multiplied according to the settings here.
Valid values:
'high' = x 10
'medium' = x 100
'low' = x 300
'high' and 'medium' also enable session.referer_check
CakePHP session IDs are also regenerated between requests if 'Security.level' is set to 'high'.
Ref: http://book.cakephp.org/view/44/CakePHP-Core-Configuration-Variables
So the other thing looks to be the referrer checking.
session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string.
So the looks of it, the things you are lose are the ability to accuratly determine who and which sessions you are dealing with.
I ran into a similar problem with losing sessions and many answers pointed to using $this->requestAction() as it will basically curl a request out of the app, so it can look like another session being created with a high security.
The other thing that many google answers threw up was turning off Session.checkAgent in your app/config/core.php as that meant the session would not be checked. This at least prevented me from losing the session information between page requests.
:)
two things happens when setting to 'low'
1)timeout is bigger
2)if session highjacking is easy, then it will be easier! since the session dosent regenerate between requests as when set to 'high'!
and nothing else.
by the way you can change for a specific page the security level or the session timeout or both... so it is not a no-undo-choice
I believe the only ramifications of setting this to low are that the session time is multiplied by 300 rather than 10 or 100 for high and medium respectively and the session refer check that you are having the issue with.
Update:
If you previously had this set to high, you would also loose out on the session id regeneration between requests.