The scenario leveille brings up is the one I'm in. This is more of an extranet than an intranet. The server is off-site, and is being accessed by many people who all share the same IP.
My solution was this: 1: upon entry to user login form, check if user's IP is associated with a threshold number of failed attempts 2: if IP is not on banned list, then allow display of login form 3: for first few attempts, use session data, to avoid unnessary inserts into database 4: if user fails after a handful of attempts, then write failed attempts to database increasing count for this IP This way if a user just makes a typo a couple times, the failed attempts don't get registered, and the database table remains a more accurate count of people who were trying to login with absolutely no clue about their password -- ie hackers stabbing in the dark. On May 23, 5:47 am, leveille <[EMAIL PROTECTED]> wrote: > Bear in mind that the browser fingerprint would only be reliable if > the server to which the clients are making the request is in the same > network (behind the same firewall). In that case the IP address would > be a DHCPd 1.9.168.*.* variation. If the server to which the requests > are going to is outside the network, the requests would all show as > originating from the same IP address. > > On May 22, 8:33 pm, BrendonKoz <[EMAIL PROTECTED]> wrote: > > > If you're worried about using just the IP, why not store a browser > > fingerprint in the database and use that as the mechanism for > > identifying an identical user? A simple browser fingerprint would be > > the IP and UserAgent string concatenated toghether, and then hashed > > (MD5 for instance). Although this technically could lead to > > duplication eventually, the chances that you'd have multiple hits on > > the same IP would be greater. You can find more about browser > > fingerprinting with a simple web search (and find better methods). > > > On May 22, 4:29 pm, aranworld <[EMAIL PROTECTED]> wrote: > > > > Thanks for the feedback. I will add some database functionality to it > > > as well. > > > > One problem I am coming across is that many of my users are all in the > > > same office with identical IP addresses. So if one user makes 5 > > > unsuccessful attempts, I run the risk of locking out everyone else in > > > the office. > > > > I'm thinking that I can have a session based lockout set at 5, but > > > then make a database lockout with a much higher limit to compensate > > > for the fact that many users could all enter wrong passwords within a > > > week's time. Even if the limit is as high as 100, I still think that > > > is very likely to combat brute force methods, which usually require > > > 10s of thousands of entries to have any hopes of success. > > > > On May 22, 12:58 pm, davidpersson <[EMAIL PROTECTED]> wrote: > > > > > There's a brute force protection behavior available over at the > > > > bakery:http://bakery.cakephp.org/articles/view/brute-force-protection > > > > > It may need some changes to make it work with 1.2 but I think it's > > > > simple and does it's job. > > > > > On May 22, 9:13 pm, aranworld <[EMAIL PROTECTED]> wrote: > > > > > > I am trying to figure out the most reliable way of restricting login > > > > > attempts while using the Auth Component. > > > > > > Here is my best stab at the problem thus far: > > > > > >http://cakeforge.org/snippet/detail.php?type=snippet&id=220 > > > > > > I'd love to hear what other people have done, or what they think of > > > > > the method I am using in the code snipped I've linked to. > > > > > > -Aran --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
