-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam,
Adam Gordon wrote:
> 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 questi
On 3/9/07, Adam Gordon <[EMAIL PROTECTED]> wrote:
How so? Please elaborate.
Our web application sits entirely Tomcat land and it's accessible only
via Apache, but Apache is only acting basically as the redirector - it
knows nothing of what's going on, it just rewrites/relays requests and
serve
AM
Please respond to
"Struts Users Mailing List"
To
Struts Users Mailing List
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
--- Adam Gordon <[EMAIL PROTECTED]> wrote:
> Disabling the username isn't really feasible because
> we then affect the legitimate owner of that login -
The original suggestion was to disable to the name for
certain period of time, which you were doing anyway,
just not reliably.
d.
___
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 servi
In addition to any other issues mentioned you need to
consider that some browsers may time out if the Action
goes to sleep, which is ugly.
I think you'd be better off following an earlier
suggestion to simply lock out a given user ID after N
failed login attempts, put a timestamp in the DB, and
ch
How so? Please elaborate.
Our web application sits entirely Tomcat land and it's accessible only
via Apache, but Apache is only acting basically as the redirector - it
knows nothing of what's going on, it just rewrites/relays requests and
serves up responses.
-adam
Joe Germuska wrote:
On
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
t
On 3/9/07, Adam Gordon <[EMAIL PROTECTED]> wrote:
Our login page performs a POST to authenticate and I'd like to put in a
delay when a login failure occurs so that it hinders/frustrates any
malicious users and any scripts they might be running. I realize this
isn't a foolproof solution but si
I'm trying to determine the ramifications of putting a Thread.sleep(...)
call in a Struts action - i.e. since only one instance of the action is
created by the server, even though Tomcat is multi-threaded, would/could
an invalid login by one user hinder a valid login by another user?
Basically
10 matches
Mail list logo
