Hi Peter:
Peter Stavrinides wrote:
Do you use Java?
yes
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).
doesnt the client have to return a jsessionid cookie?
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.
thank you very much for your advice, i will use it!
John
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
