This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Servlets and the fly likes Blocking users after failed logins Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Blocking users after failed logins" Watch "Blocking users after failed logins" New topic
Author

Blocking users after failed logins

Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
Hello Everyone
Recently i was asked this question in my interview ::

Question : What would you do block a user if he fails to login in 3 consecutive attempts ?
My Answer : I will make use of Session object, so that server could identify that all 3 requests came from the same system.

Dont know if i am right . Please correct me .
Thanks!!!
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60755
    
  65

The session can easily be dumped by manipulating the browser. Or, someone could be using multiple browsers to make repeated attempts. So probably not the best approach.

What's your next thought on how to do this?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
Thanks Bear, will keep your suggestion from the next post.
Coming on the next thought..If Session would not work then what we can do is, In the login table add another field which stores the number of unsuccessful attempts from the servlet.
But that is also not fool proof, what if i open 3 browsers & enter wrong password once from each. It will increment to 3 in single login failure from each browser...
What to do ? :/
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 888
    
    9
Tarun Oohri wrote:But that is also not fool proof, what if i open 3 browsers & enter wrong password once from each. It will increment to 3 in single login failure from each browser...

Why is that bad? It's still the same user who is trying to login so it's not wrong to block if the request comes from different browsers or even different client types.
In a real world internet facing application that should accessed by a closed group you will probably have operating system level tools as well (like fail2ban) which temporarily ban an ip address if the login fails for a configured number of times to reduce database hits from automated brute force attacks.
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
E Armitage wrote:
Tarun Oohri wrote:But that is also not fool proof, what if i open 3 browsers & enter wrong password once from each. It will increment to 3 in single login failure from each browser...

Why is that bad? It's still the same user who is trying to login so it's not wrong to block if the request comes from different browsers or even different client types.
In a real world internet facing application that should accessed by a closed group you will probably have operating system level tools as well (like fail2ban) which temporarily ban an ip address if the login fails for a configured number of times to reduce database hits from automated brute force attacks.

Thanks Armitage, My point was if we replace 3 different browsers to 3 different computers, So account would get block on very first wrong attempt by single computer..
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60755
    
  65

Tarun Oohri wrote:
Thanks Armitage, My point was if we replace 3 different browsers to 3 different computers, So account would get block on very first wrong attempt by single computer..

I'm not following that at all.

Which browser/computer the request comes from should be completely irrelevant in this scenario.
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
Thanks Bear, i think i need to brush up servlet concepts again... sorry
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60755
    
  65

Think of it this way: when a request is received, if you ignore the session -- and in this scenario we've already established that the session is not a player -- the servlet really has no care about where the request comes from. Did the three requests come from the same browser? Did they come from different browses on the same machine? Did they come from different systems completely?

We don't care.

If we do something like record the failed attempts for a particular credential (such as a username) in a DB, where the request for the same credentials came from is irrelevant. All we care about is that three bad attempts to log into the same credentials were made.

Make sense?
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
Bear Bibeault wrote:where the request for the same credentials came from is irrelevant. All we care about is that three bad attempts to log into the same credentials were made.

Make sense?

Thanks Bear for this clear explanation , Yes it does make sense now.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15951
    
  19

Incidentally, if you are using the Tomcat webapp server, I believe that there is a "Lockout Realm" that can be used to enforce that policy using the J2EE-standard Container Security subsystem.


Customer surveys are for companies who didn't pay proper attention to begin with.
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
Tim Holloway wrote:Incidentally, if you are using the Tomcat webapp server, I believe that there is a "Lockout Realm" that can be used to enforce that policy using the J2EE-standard Container Security subsystem.


Thanks Tim, I asked my sir the same question...He said this can be resolved using GET , as it is idempotent ... resulting same failure reply 3 times , it will consider as one .... but i dot know how to implement it ...As each request gets a new thread, therefore if i increment a local variable, that is of no use as its scope finishes as the method is finish ... If i declare an instance variable than i have to make it thread safe..again a bad option ...
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15951
    
  19

Intruders are rarely polite enough to follow the rules.

That's why I recommend using the security manager that's part of J2EE.

It was designed by full-time security professionals, not people whose main task was to get an application up and running with security as a mere afterthought.

In fact, one of the most common exploits used by non-technical people to exploit a webapp is to craft a request that bypasses the login altogether. Where a "3 failed logins" policy would be immaterial.

The container security system gets around that by ensuring that resources marked as secure really are secure. Requests cannot even reach the application code unless they've passed the container security constraints.
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 172
Tim Holloway wrote:Intruders are rarely polite enough to follow the rules.

That's why I recommend using the security manager that's part of J2EE.

It was designed by full-time security professionals, not people whose main task was to get an application up and running with security as a mere afterthought.

In fact, one of the most common exploits used by non-technical people to exploit a webapp is to craft a request that bypasses the login altogether. Where a "3 failed logins" policy would be immaterial.

The container security system gets around that by ensuring that resources marked as secure really are secure. Requests cannot even reach the application code unless they've passed the container security constraints.


Thanks for the heads-up sir for your valuable feedback....shall study security manager and try to implement it.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Blocking users after failed logins
 
Similar Threads
plz give suggest me
How to Forward to a Particular Page for a Particular Role ?
JAAS on JBOSS
Login page problem
login/password question