Idea Details

Restrict Concurrent Logins

Last activity 03-06-2017 03:07 AM
Anon Anon's profile image
10-31-2014 10:41 AM

During IT health checks and pen tests that we commission for some of our higher security implementations of CA SDM 12.5 we often get the following issue raised.

 

Description:

The application did not prevent a particular user from logging in multiple times creating multiple sessions,

potentially from different IP addresses.

Permitting a user to login multiple times may create concurrency faults, created when a particular set of data

is updated simultaneously or at least almost synchronously by separate requests from alternative sessions.

This could generate inconsistencies or exceptions, depending upon the nature of the data being modified and

give cause to user confusion. In addition, failure to prevent concurrent logins may permit a potentially

compromised account to go unnoticed as ‘illegitimate’ and ‘legitimate’ usage could occur at the same time.

Recommendation:

User accounts within the application should only be permitted to use one session at a time. The session

management system currently in place seems to prevent the identification and/or exclusion of multiple

sessions. It is therefore recommended that session concurrency settings be implemented.

 

I understand that restricting concurrent logins in web applications can be problematic - especially for support teams where users can lose a session by abnormal shutdown of the browser and then maybe unable to login again until the session times out. However I propose that CA SDM is enhanced to popup a message to the end user if they try to login to a second session. The popup should advise that the userid is already logged in on a session and ask if they would like to continue and that continuing to login would mean that the previous session would be logged off. If the user accepts the prompt and asks to continue then the other session for the user id should be ended and the new login session created.

 

If the user does not accept the prompt then they should be returned to the login screen without creating a new session.

 

If someone tries to use a session that has been ended in this way then they should be prompted with a session ended message / prompt and sent back to the login screen without creating a new session.

 

This idea would provide a useful security enhancement to the application which would go some way to keeping our security accreditors happy.


Comments

03-06-2017 03:07 AM

Hi.  We had an occurrence where a person with a user profile had a faulty IE installation.  The problem this created was when the person selected CA service desk, the browser started sending multiple connection requests to the service desk repetitively.  The service desk eventually crashed after running out of memory as it tried to establish all of these connection requests.  There was nothing we could do from a support perspective as the faulty IE browser generated 1700 connection requests in under 2 minutes.

The fact that a simple function like that could lead to a brute force attack on the service desk application and shut it down is worrying. 

A popup function as suggested by other members would go a long way to prohibiting this especially if it was combined with a NX.env entry whereby you could limit the number of concurrent connections from a single person based on their role.

10-06-2015 02:50 AM

I fail to see how concurrent sessions might lead to data inconsistency as there is a checkout-checkin mechanism already in place, which blocks (or at least warns the user of) these situations. Security-wise I do agree, having the possibility to limit sessions to one would be a nice addition for the more paranoid

10-04-2015 04:12 PM

We are still on SDM 12.9, so I'm unsure if this is already available, but having the ability to monitor active sessions would be beneficial. I would want to be able to filter the currently active sessions by contact type too.

10-02-2015 12:43 PM

Thanks for the suggestion and insights provided about how you would like the "apparent" session handling dealt with. The challenge here is that the system is intentionally designed to operate with multiple sessions to enable a variety of capabilities - like being able to have more than one ticket open at the same time. Altering the session design used is not feasible without a very invasive refactoring of the entire system.

09-04-2015 06:28 AM

Totally agree....  Role based that an administrator sets on each role.

09-04-2015 03:53 AM

I agree - a role based option would be good but I think control of it should remain centrally with system admins (defining policy) rather than individual preference.

08-29-2015 01:27 AM

Yes role based setting may be even bether

08-28-2015 06:10 PM

I actually think rather than an nx.env option or options manager setting, this should be something that can be allowed or not for each role or access type.  That way you can allow multiple sessions for Administrators who often do need it, but not allow it for the regular 'analysts'.

 

Tammy

08-28-2015 05:07 PM

I agree it should be option in nx.env

08-28-2015 04:56 PM

If you're going to consider this, I would make it optional.  I often have multiple sessions open on my machine.  Could be for testing purposes where I have multiple tabs open with different sessions for different IDs.   Or sometimes I'll do it because I need to work in multiple parts of the tool simultaneously with search results from different views and don't want to have to re-run/resort the results as I go back and forth which is time consuming.  So there are benefits of allowing multiple sessions.

12-17-2014 04:52 PM

I agree with this idea, if you already have SDM open in the browser, clicking any external SDM link should not generate another session.

10-31-2014 11:16 AM

I should also state that the content of any login messages and alert boxes / prompts should be carefully designed to ensure that information relating to the users login id is not reflected back in the response to the client. This is to protect against any possible attempts at username enumeration to aid brute force attacks on the service.