• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Blocking users after failed logins

 
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!!!
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ? :/
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Bear, i think i need to brush up servlet concepts again... sorry
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic