Re: Restricting Login Attempts with Auth Component
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 -~--~~~~--~~--~--~---
Re: Restricting Login Attempts with Auth Component
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 -~--~~~~--~~--~--~---
Re: Restricting Login Attempts with Auth Component
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 -~--~~~~--~~--~--~---
Re: Restricting Login Attempts with Auth Component
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 -~--~~~~--~~--~--~---
Re: Restricting Login Attempts with Auth Component
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 -~--~~~~--~~--~--~---
Re: Restricting Login Attempts with Auth Component
Assuming that your blocking their IP, because you think a hacking attempt is taking place. Usually, hacking attempts are performed by robots, and it wouldn't be hard to have the robot retry every 5 minutes. I think storing the IP address in the session isn't useful. If they fail to login after the number of tries, then this IP should be stored in a black list database. The IP address can have a TTL value that expires in say 30 days. What's important is the IP address attacking the website. A robot could attack all the known users for a domain. Where the user name is shown a robot can just process all the account looking for someone stupid enough to use a commonly known password. This would be a strict approach. - Original Message From: aranworld <[EMAIL PROTECTED]> To: CakePHP Sent: Thursday, May 22, 2008 3:13:57 PM Subject: Restricting Login Attempts with Auth Component 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 -~--~~~~--~~--~--~---
Restricting Login Attempts with Auth Component
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 -~--~~~~--~~--~--~---
