RE: Single terminal login

[<stevenr () mastek com>]

Hi Michael
 
Yeah, what you have mentioned does seem feasible (theoretically atleast, I havent tried this option out before :-) ) . 
I would appreciate if you could shed some light on the server thread which does the cleanup. Talking with respect to 
Java, I could think of only of one method. Creating a thread which sleeps till notified and when notified, starts up 
and does the cleanup job. Anyone else have any other ideas?
 
Regards
Steve

        -----Original Message----- 
        From: Michael Silk [mailto:silkm () hushmail com] 
        Sent: Tue 2/17/2004 9:37 AM 
        To: Steven Rebello; urbn () visi com 
        Cc: webappsec () securityfocus com 
        Subject: RE: Single terminal login
        
        

        Steve,
        
         An idea comes to mind ...
        
         I don't know what language you're using, but in java
         or .net it is easy to implement a static list of all
         the current "logged in" users.
        
         You can, at "logging in" point, create a "user" type object,
         with "lastActivity" field, add it to the list, and update
         this object, not a database or LDAP, with the time of access.
        
         You can then also have a server thread that sits in the
         background "logging out" these objects after some time period.
        
         The time period will be easy to figure out based on the type
         of application you use.
        
        -- Michael
        
        
        -----Original Message-----
        From: stevenr () mastek com [mailto:stevenr () mastek com]
        Sent: Tuesday, 17 February 2004 12:58 PM
        To: urbn () visi com
        Cc: webappsec () securityfocus com
        Subject: RE: Single terminal login
        
        
        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.
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        
        
        
        
        Concerned about your privacy? Follow this link to get
        FREE encrypted email: https://www.hushmail.com/?l=2
        
        Free, ultra-private instant messaging with Hush Messenger
        https://www.hushmail.com/services.php?subloc=messenger&l=434
        
        Promote security and make money with the Hushmail Affiliate Program:
        https://www.hushmail.com/about.php?subloc=affiliate&l=427