Re: Single terminal login

["lists AT dawes DOT za DOT net" <"lists AT dawes DOT za DOT net"@securityfocus.com>]

Hi,

The approach where you simply invalidate any existing sessions when 
users log on again is not such a bad one.

Firstly, it deals with the issue of browsers being closed without 
logging off, leaving sessions lying around.

Secondly, there should not be such a large performance impact, as this 
is only done at logon time, which should not be such a frequent 
operation, even on a busy site. If you have a mapping between sessionid 
and username (generally you must have sessionid --> username and other 
info) such that you can look up a sessionid from a username, you can 
simply invalidate any existing sessions for that particular user at 
logon time.

Thirdly, the user will definitely be aware that someone else is using 
their account. When the user with the invalidated session tries to 
perform an operation, they can be presented with a notice saying that 
their session has been invalidated due to simultaneous login from 
another location, and to change their password or contact the helpdesk 
to resolve it.

I have experienced this myself doing testing of an internet banking app, 
where there was only a single test account on the production system, and 
multiple people using it. It is nearly impossible to work when your 
session is being invalidated every 5 minutes, just as you try to execute 
a command. You log out and log back on to get a legit session, and the 
other person/people do the same. It makes the application unusable, 
which will lead to the user changing their password, and not sharing it 
in future.

Obviously, you need to make sure that you have the necessary procedures 
in place to allow users to get their own accounts, with the necessary 
permissions for them to do their jobs. Otherwise, you will end up with 
troubles of a different sort!

Regards,

Rogan


stevenr () mastek com wrote:
> Hi
>  
> Updating the timestamp in the DB is a general workaround, but as I mentioned in my first post, if I update the DB for every page accessed, it will be a very expensive method for a high volume site.
>  
> Also, what Matt suggested about closing the prev session with every new login does make sense, but that would mean that a user would get in every time, invalidating the prev session. To give a background, I need to implement the Single Terminal Login concept to avoid password sharing among users, which is playing havoc with my audit trails. This method would work towards solving that, but the user will not realise that someone else is logged in from his/her account previously, possibly meaning a stolen password etc. 
>  
> Regards
> Steve 
>  
>
> 	-----Original Message----- 
> 	From: urbn () visi com [mailto:urbn () visi com] 
> 	Sent: Tue 2/17/2004 1:07 AM 
> 	To: Steven Rebello 
> 	Cc: webappsec () securityfocus com 
> 	Subject: Re: Single terminal login
>         
>         
>
>          One factor you didn't mention is server resources issues, do you mind these
>         
>          sessions staying in memory for... hours?
>         
>          What I have done in the past is store user information in a database, and
>          include a record that tracks the last time the database was accessed (each
>          time
>          a page is accessed or refreshed) a script is run to update this field.
>         
>          2 main fields, a filed that stores if they are logged in, and a field that
> 	 stores a time (last time page access). 
> 	
>          When the user tries to login, if this field is less then say 5 minutes old
>          (preset time), they can not login.  After five minutes, if they are listed as
>         
>          Logged in, they receive a warning they did not log off correctly and must
>         type
>          in their password again.
>         
>          Don't really know if that was what you are looking for, because you run into
>         
>          issues with sessions being killed once the browser is closed, timeout issues
>          on
>          the server side, and many more issues.
>         
>         
>         > Quoting Matt Wirges <wirges () purdue edu>:
>         >
>         > > stevenr () mastek com wrote:
>         > > > Hi
>         > > >
>         > > > I have worked with web based applications since quite some time. One
>         > issue
>         > > to which I have not found a satisfactory answer yet is that of a problem
>         > with
>         > > Single Terminal Login in a web based application.
>         > > >
>         > > > By Single Terminal Login, I mean that if one user logs into a web
>         > > application (say JSP based), s/he should not be able to login from
>         > another
>         > > machine or even another browser from the same machine. This can be
>         > achieved
>         > > easily by setting a "logged in" flag on the server side using a DB or
>         > LDAP
>         > > etc. When the user clicks on the Logout link, the flag is reset and only
>         > then
>         > > the user can login from another browser/window. Now the hitch. If the
>         > user
>         > > closes the browser directly, or the power goes out, or browser hangs and
>         > has
>         > > to be killed, the flag remains as "logged in". In short user cannot login
>         > > into the system again. The one workaround used commonly, is setting a
>         > timeout
>         > > after which the user can login again, where a "last active time" is
>         > > maintained for each user. Every login request is cross-checked against
>         > this
>         > > time and if the difference is greater than some threshold value, the user
>         > is
>         > > able to login again.  But this means that everytime the user does
>         > something
>         > > the "last active
>         > > time" will have to be updated, which will be expensive in a high traffic
>         > > site. Also, the threshold value is always a hot topic of debate :-)
>         > > >
>         > > > Does anyone know a better or a different approach to this? Would be
>         > helpful
>         > > if someone knows some site/papers for this. Have googled but havent come
>         > > across any myself.
>         > > >
>         > > > - Steve
>         > > >
>         > > > "He who laughs last probably made a backup..."
>         > > >
>         > > >
>         > > >
>         > > > MASTEK
>         > > > "Making a valuable difference"
>         > > > Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
>         > > > In the US, we're called MAJESCO
>         > > >
>         > > >
>         > >
>         >
>         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         > > > Opinions expressed in this e-mail are those of the individual and not
>         > that
>         > > of Mastek Limited, unless specifically indicated to that effect. Mastek
>         > > Limited does not accept any responsibility or liability for it. This
>         > e-mail
>         > > and attachments (if any) transmitted with it are confidential and/or
>         > > privileged and solely for the use of the intended person or entity to
>         > which
>         > > it is addressed. Any review, re-transmission, dissemination or other use
>         > of
>         > > or taking of any action in reliance upon this information by persons or
>         > > entities other than the intended recipient is prohibited. This e-mail and
>         > its
>         > > attachments have been scanned for the presence of computer viruses. It is
>         > the
>         > > responsibility of the recipient to run the virus check on e-mails and
>         > > attachments before opening them. If you have received this e-mail in
>         > error,
>         > > kindly delete this e-mail from all computers.
>         > > >
>         > >
>         >
>         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         > > >
>         > >
>         > > Steve,
>         > >
>         > >    What we've done in the past on a few applications is simply close the
>         > > old session the next time the user logs in.  For example, one of the
>         > > applications I worked on is a web interface for incident response.  One
>         > > of its features is time tracking to see how long a responder has worked
>         > > on an incident.  So if the responder closes his web browser or his
>         > > session expires, i.e. he doesn't log out via the application, the
>         > > session remains active in the session table until the next time he logs
>         > > in.  When the user logs in again, the system asks him to enter the time
>         > > when he last used it and then closes the session updating it with his
>         > > logout time and initiates the new session.
>         > >
>         > > In other applications I've simply just auto-closed the session when a
>         > > new login is detected.
>         > >
>         > >
>         > > -matt
>         > >
>         > > --
>         > > Matthew Wirges
>         > > IT Security and Policy Analyst
>         > > Security and Policy
>         > > Information Technology at Purdue
>         > > wirges () purdue edu :: (765)49-62307
>         > > www.itap.purdue.edu/security
>         > >
>         >
>         >
>         >
>         
>         
>         
>
>
>
> MASTEK
> "Making a valuable difference"
> Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
> In the US, we're called MAJESCO
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically 
> indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and 
> attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended 
> person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any 
> action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This 
> e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the 
> recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in 
> error, kindly delete this e-mail from all computers.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~