1

I was just finishing up a reset password system, and thought it would be wise to have a limit attempt restriction on the actual reset page (for the token input). I did a few google searches, and I'm finding next to nothing on doing that with CakePHP. Now, I can throw something together, but I like reading up on other implementations because it helps me catch ideas that I might not have thought of, and helps avoid potential security hazards and bugs.

Because I was unable to find anything, it has made me wonder if I am attempting a poor form of security for my application. Is there a reason that this is greatly under covered (ie, is it covered by the security component or something else, a bad way to prevent brute force attacks, replaced by a better method), or is this a good method of protecting my application? Should I be looking at a different way to protect my application?

Thank you!

xtraorange
  • 1,386
  • 1
  • 12
  • 37
  • I should add: my surprise comes because any time I think of anything I'd like to implement, and do a google search, I get 1000 previous implementations to look through. Yet in this case, I only found one, and the code in the example was frightening (as in using a single equal sign as a comparator in several places, for example). – xtraorange May 01 '14 at 21:04
  • Your question doesn't really fit the guidelines for StackOverflow. Please read the [faq] on how to post a question here – thaJeztah May 01 '14 at 21:24
  • Good golly. Okay, I will reword. – xtraorange May 01 '14 at 21:27
  • I don't know of any systems that have a limit attempt on the reset page, but I do know of systems that have a time limit. Time limits are good in case someone leaves the page open by accident, someone else could maliciously change their password. If you set the time limit short enough, it could I guess aid in brute-forcing, though you don't want it too short, or it'll inconvenience users. I think though limiting attempts on reset isn't usually implemented, since password reset is usually sent to a person's email, which is theoretically secure, or else they have bigger worries. – Kai May 01 '14 at 21:32
  • @Kai - I'm concerned not with the reset page, but the page allowing access to the reset page by the token sent to the e-mail. The attack would be against the token sent to the user's e-mail (trying thousands of tokens until one succeeds). A short token expiration would help, but less than an hour would probably be inconvenient, which still leaves plenty of time. An example: Assume that the attacker discovers a user's e-mail address. Attacker requests token to e-mail. Attacker goes to reset page, and begins attempting brute force on the token to gain access to the password reset page. – xtraorange May 01 '14 at 21:42
  • 1
    If your token is long enough using enough characters, then is an hour really going to be good enough to brute force? As said here, http://stackoverflow.com/questions/6163428/secure-token-url-how-secure-is-it-proxy-authentication-as-alternative if you use alphanumeric only, 10 digits is 839,299,365,868,340,224 combinations... Will your server be able to even respond fast enough to brute force? – Kai May 01 '14 at 21:55
  • @Kai - Excellent point. I clearly was not thinking this through. Thanks! – xtraorange May 01 '14 at 22:09

1 Answers1

0

Implementing a per-user rate limiting is difficult, because the common ways to identify a user (cookie, IP address) can be defeated by an attacker.

A simplistic yet efficient approach could be

sleep(2);

before you return the result of the token check. Such a small delay is acceptable for a legitimate user but will slow down a brute-forcing attacker.

In the case of a password reset token that is generated by the system, making it long enough should not be a problem though. Given enough entropy, rate limiting should not be required to make an attack unfeasible.

As a general guideline about passwords and account security I recommend reading The definitive guide to form-based website authentication (which is not CakePHP specific, though).

Community
  • 1
  • 1
pixelistik
  • 6,797
  • 2
  • 28
  • 39
  • That makes it quite easy to DOS a server by submitting requests in parallel. It's a much better idea to either implement rate limiting in php returning an error immediately if hte limit is exceeded, implement rate limiting via the webserver or use something like fail2ban to block attackers once they are recognised as such. – AD7six May 02 '14 at 10:07
  • Thank you for you valid criticism. A lot of `sleep`ing requests will indeed take up server resources. Do you have any pointers how to implement proper rate limiting in CakePHP? – pixelistik May 10 '14 at 13:34
  • Here's [an example rate limit implementation](https://github.com/kvz/cakephp-rest-plugin/blob/master/Controller/Component/RestComponent.php#L253-L278) - key points are you must log all requests to be able to count how many have occurred in a given period. Any php implementation can be used as a template, it doesn't need to be a CakePHP solution. You can also [get the webserver to do it](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html) which is much more efficient. – AD7six May 10 '14 at 13:39