WebApp Sec mailing list archives
RE: Single terminal login
From: "Michael Silk" <silkm () hushmail com>
Date: Tue, 17 Feb 2004 13:07:40 -0800
Steve,
Basic code might look like ...:
class User {
private static final ArrayList MONITOR_LIST = new ArrayList(/* common
concurrent users, i.e: */ 50);
static {
// on first access to the user class,
// start monitor.
Thread t = new Thread( new UserCleaner() );
t.setDaemon(true); // so it does not stop app exiting if it is
the only thread left
t.start();
}
public User(){
//
// init code
//
MONITOR_LIST.add(this);
}
class UserCleaner implements Runnable {
public void run(){
while(true){
try {
Thread.sleep( /* some delay, say 20 mins: */ 20 * 60 *
1000 );
} catch(Exception e){ /* */ }
// check array list for old users, and remove.
}
}
}
}
-- Michael
On Mon, 16 Feb 2004 22:33:23 -0800 stevenr () mastek com wrote:
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
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
Current thread:
- Single terminal login stevenr (Feb 15)
- Re: Single terminal login Martin Tsachev (Feb 15)
- Re: Single terminal login Matt Wirges (Feb 16)
- Message not available
- Re: Single terminal login urbn (Feb 16)
- Message not available
- <Possible follow-ups>
- RE: Single terminal login stevenr (Feb 16)
- Re: Single terminal login lists AT dawes DOT za DOT net (Feb 17)
- Re: Single terminal login Ingo Struck (Feb 18)
- Re: Single terminal login lists AT dawes DOT za DOT net (Feb 17)
- RE: Single terminal login Michael Silk (Feb 17)
- RE: Single terminal login stevenr (Feb 17)
- RE: Single terminal login Michael Silk (Feb 17)