Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Blocking users after failed logins

 
Tarun Oohri
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 65111
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Tarun Oohri
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 65111
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Bear, i think i need to brush up servlet concepts again... sorry
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65111
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18276
56
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tarun Oohri
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18276
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic