Re: Restricting Login Attempts with Auth Component

2008-05-28 Thread aranworld

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=snippetid=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

2008-05-23 Thread leveille

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=snippetid=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

2008-05-22 Thread aranworld

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=snippetid=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

2008-05-22 Thread Mathew Nik Foscarini
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 cake-php@googlegroups.com
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=snippetid=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

2008-05-22 Thread davidpersson

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=snippetid=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

2008-05-22 Thread aranworld

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=snippetid=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

2008-05-22 Thread BrendonKoz

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=snippetid=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
-~--~~~~--~~--~--~---