John and Peter SE seems definitely O/T so please email me offline on this topic of Social Engineering..Perhaps this is a project which the government never discloses? Admittedly I have no information as to the definition and or implications of such a plan
Thanks, Martin-- --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------------- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. ----- Original Message ----- From: "John Caron" <[EMAIL PROTECTED]> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Monday, January 29, 2007 3:17 PM Subject: Re: session hijacking again > 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] > >
