Do you use Java?
We are a financial institution, we use a Java Framework based on
servlets with SSL, but if you ask my opinion SSL is not the big issue.
The vast majority of hacked sites are social engineering attacks. Secure
your database (do not store clear text passwords in the database)
minimize access of staff, require strong passwords (8 characters and
numbers). No strategy or amount of code is foolproof, although yes It is
also worth the extra effort to make your application a bit smart, but it
is better to focus your attention on preventing social engineering,
because no matter how clever you make it if the passwords are easily
guessed or users careless its all for nothing.
Design your application like a container that reloads its body, that way
you can implement security and logging application wide with minimal code.
We secure our application like this: on login (after authentication) we
store in state for the duration of that session, the users unique id and
session id and for logging purposes the current IP. (no cookies etc are
used at all, because cookies are stored on the client which is out of
our control).
We perform a check for each new login to ensure at least the user id and
session id does NOT exist in state before allowing the new login. We do
not allow two concurrent logins with the same account.
If you wish to implement session id switching you have to destroy the
users old session and recreate it and update the session id in state (to
me again, just my humble opinion, not so important)... it is far more
useful to use a session timer that times out after a few minutes of
inactivity, it will automatically call a sign out but you can keep the
users details in the server state until the browser closes, if they try
to continue activity, then you ask them to sign in again and add their
new session id back into your state object. When the browser closes a
session listener cleans out the session so the users details are discarded.
Again paranoid coding is not going to prevent social engineering,
educating users might... by far the most effective strategy is to tell
users to never give out their password, give them a support number and
inform them about what the support personnel is and isn't allowed to ask
them for. Lastly tell users exactly what type of email they will and
won't receive from your organization. When they login to your site tell
them they should ALWAYS check that the domain name appears correctly in
the address bar.
John Caron wrote:
Hello:
Our application is serving large amounts of scientific data over HTTP.
The user needs to login to access the data. We would like to use
session ids to reduce the login overhead. We cant afford the overhead
of HTTPS encryption of teh data (3 times slower ?). We realize this
makes us vulnerable to session hijacking. Still, we arent transferring
financial information, so tentatively we think its a reasonable risk.
The Wikipedia article (http://en.wikipedia.org/wiki/Session_hijacking)
suggest a couple of things that help, that seem reasonable to me:
# Some services make secondary checks against the identity of the
user. For example, a web server could check with each request made
that the IP address of the user matched the one last used during that
session. This does not prevent attacks by somebody who shares the same
IP address, however, and could be frustrating for users who's IP
address is liable to change during a browsing session.
# Alternatively, some services will change the value of the cookie
with each and every request. This dramatically reduces the window in
which an attacker can operate and makes it easy to identify whether an
attack has taken place, but can cause other technical problems (for
example, preventing the back button from working properly, on the web).
I would like to implement one or both of these in Tomcat: 1) IP
checking and 2) session id switching. I guess others have thought
about this. Does anyone have any advice or pointers (or code!) to get
started.
Thanks for any help.
John Caron
Unidata/UCAR
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
