I would stay away from Thread.sleep anywhere within a J2EE container, this takes that control of a thread away from the container and can produce unpredictable results. I haven't read all of the replies sorry if I'm regurgitating what someone else said.
I have 2 suggestions; Frirst, what about only allowing a single person to be authenticated into the system at one time? You could use a token to keep track of the "first" (and hopefully the correct) authenticated user. Have a randomly generated token placed into the response and re-validate it on each request, so you know who the "correct" user is. You would also use this toekn to mark an account as "active" (it would need a reasonable time out like 5 min). If an account was marked as acrive you would ot allow any further login attempts and indicate that its already active. This will alert the real account owner if someone else is using their account or if the real user is already logged in will keep your security transparent to them. It is probably also a good idea to tell the "failed user" what information you have on them, and that a "notice has been sent to security". Its probably also a good idea to log this and actually send it to security :) This implementation does assume that your customers will be "okay" with only being able to log in with one account at a time. If you wanted to get more complex with this you could implement a set of questions at the time of the account set up so you can re-validate the user at any time with more than just u/p. You could then keep track of valid IP addresses for the account (or put cookies on their computers to mark them as valid) and each time you don't see a valid IP for the account (or cookie on the computer) you prompt them with this set of questions to re-validate their authenticity and then mark that IP as valid (or put a cookie on the computer). However, the more complex this gets the more the users are going to need very intuitive user interfaces or a phone number to call. Matt Filion CSC - GTS --> Raytheon - ISF (818) 468-6271 [EMAIL PROTECTED] -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Adam Gordon <[EMAIL PROTECTED]> 03/09/2007 11:47 AM Please respond to "Struts Users Mailing List" <user@struts.apache.org> To Struts Users Mailing List <user@struts.apache.org> cc Subject Re: Thread.sleep(...) in Struts Action Paul- Thanks for the response. I agree the implementation isn't great, but it's all we could come up with so far. Disabling the username isn't really feasible because we then affect the legitimate owner of that login - we work in a pretty competitive market and our clients rely on our service being available 24/7. A customer will generally freak out if you tell them their account was locked due to illegal access attempts. Shoot, I know I would - especially if the account is sensitive, like a bank or something. Their next question would be did they get in and what did they get? We discussed blocking, but can't realistically block IP addresses because large corporations will generally appear as 1 IP address due to proxy's (or similar) and blocking an entire company because of one computer in their company is, well, kind of silly. The only thing we can think of right now is look for N failed attempts from an IP address within X amount of time and notify the appropriate folks of what's going on. It's definitely a tricky problem and even some of our better engineers are having a rough go of trying figure out a solution. All the solutions we can think of only slow someone down, not keep them out. We briefly (like all of 5 seconds) thought of having image verification for the login, but clearly that's not feasible either. Customers want to know that their information is secure, but they don't want to be hindered by that security, and I agree - it should be as transparent as possible. If anything else comes to mind, please let me know. Thanks. -adam Paul Benedict wrote: > Adam, > > Your idea is good but the implementation is bad. The solution presumes a > malicious user is attempting to break passwords through a serialized > attempt: try, wait, try, wait, try wait, etc. But anyone who can guess > at > your methodology will then just spawn N asynchronous requests, which > will > then defeat your security measure all together. A better solution is to > disable the username, perhaps for a couple minutes, after N invalid > attempts. And on your login screen, display the timestamp of the last > successful login. This will give the true user some information to what > is > going on. > > Paul > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
