New answers tagged

1

The main risk of a persistent session is increased exposure for any existing client-side vulnerabilities (e.g. XSS, CSRF, session fixation, etc). That is, any malicious site targeting your users through exploits for the above would be more likely to succeed because the user is left logged in. With remember-me the above could apply too - Say the long-term ...


0

(I already had some thoughts on the matter but was seeking further opinions. Since I seem to have caused some confusion, setting them out here may help in understanding the problem I am trying to address). There are very definite functional impacts, particularly if the developer chooses to use the session substrate for storing transactional information, but ...


3

The problem Imagine the following scenario: Alice logs in to your site on her computer at home, and stays logged in. Later she logs in on a computer at school as well, but signs out when she is done. What happends when she gets home? To make this system work, you would need to set the cookie column to NULL on logout. But that would log her out from all ...


1

Cause it's easier to use a session hijacking attack... More about it here https://www.owasp.org/index.php/Session_hijacking_attack


2

There is a FIPSMode configuration option in Tomcat's APR Lifecycle Listener, which looks like it would fulfill your requirements. As observed in this very similar StackOverflow thread, and Tomcat/APR Lifecycle Listener documentation, it's really about the operating mode of OpenSSL, not Tomcat. On a not-unrelated note, Tomcat isn't FIPS-certified, due to the ...


2

This will depend entirely on the use case for the majority of the staff. If they typically run long term sessions because their applications or work require it, then you can be sure that trying to move to a shorter session length will cause problems. If they mostly run applications that can work unattended and only need to be checked later, then a very ...


4

Is SSL/TSL and HttpOnly enough to be sure that a session cannot be hijacked? Those are the must dos, and they offer good (but not perfect) protection. See question four. Is there a way to use client IP addresses as an extra layer of protection? Just checking that a session ID is used by the IP that created it will break your site for a lot of users, ...


1

I can not see any real disadvantage for your users. The worst that could happen to them would be to have to resubscribe. Note that with the current efforts put in anti-SPAM regulations and controls, every one with a mailing list should be extremely careful to properly maintain it. You certainly much prefer to have someone opt-out than having them report ...



Top 50 recent answers are included