should I limit attempts to login rails?

Question

I'm thinking about building a login system for Ruby on Rails, much like this one

http://visionmasterdesigns.com/tutorial-create-a-login-system-in-ruby-on-rails/

In terms of security, should I limit the attempts a user can have to login if they get their username wrong?

Also,The basic steps of logins seem to be:

• authenticating username and password against those in database
• if authentic username and password, create a session variable
• before filter so that pages require login are protected.

Is there anything else I should consider?

Answer 1

Yes limiting the number of login attempts per ip (not per session) increases security.

Do you know there is already several authentication systems with Rails ? There's no need to reinvent the wheel.
Here's is a non exhaustive list.

• Clearance
• AuthLogic
• Restful Authentication

If you do not wish to use any, you can take example on what they're doing.

Answer 2

Another consideration should be the Denial of Service attack. Limiting the number of requests to dynamic pages to a reasonable rate should make it harder for a malicious user to take down your site. While helping with the password cracking issue, this will also help prevent users from manipulating site data in unintended ways, which could pose a security risk (perhaps through the corruption of data).

If you decide to use this approach, you should try to find a well supported module to help you with this (instead of rolling your own).

Answer 3

One other way you could do it is with rack. You could track the number of times an IP visits the login page over a certain amount of time storing the login attempts on the database, memcached, redis, tokyo cabinet, etc. Then deny the user access to the page if they have exceeded a set quota for a defined time interval.

Damien suggested Authlogic. Authlogic is my favorite authentication system for Rails. It is very comprehensive and adaptable. There are plenty of existing modules for Authlogic, and I'm sure you could leverage one of these to have Authlogic work for you.

Answer 4

First, rate-limit the login page per IP. Use an invisible captcha system on the login page. Then you should put login limits per IP, but you should also put login limits per user as a last resort to stop botnets from brute-forcing from multiple IPs. Send an email to the user if an attempt to brute-force their password is detected. Don't send hordes of repeated e-mails if someone tries from a bunch of different IPs. A botnet could do some serious spamming otherwise, and worse, cause an important message to end up in the spam folder. Be sure to mention that they might want to change their password, and/or upgrade its strength.

If you put IP login limits on, make the limits high. A lot of places use three strikes and you're out. That's nuts and user-unfriendly. It should be at least ten or more realistically, and when you hit it, you should get a time-based ban rather than a "Call customer support" ban. No one is going to brute force a password in ten tries. So I recommend a per-IP login limit of 10 and a per-user login limit of between 1,000 and 10,000 (high enough to frustrate denial-of-service attacks, but low enough that a botnet is unlikely to have cracked the password yet). You should have some form of alert to the sysadmin/on-call pager that there's a botnet at work that triggers long before you hit that threshold though. (Keep a count of failed logins for all users and individual users, do a rolling average, and alert if it crosses either threshold. Remember that if someone has a sufficiently large user list, the probability of succeeding for at least one account across the entire user base is roughly the same as the probability of succeeding by attacking just one account.)

Block obvious attackers at the firewall. Expire the bans after awhile. Be sure to make it so that customer support can unban someone, but make sure the ban is somehow linked to the offense. You shouldn't be unbanning someone who's attempted to break twenty different user logins or something. Judgement here of course, because script kiddies with not-at-fault family members and grandmas who have been taken over by botnets can certainly manage to get themselves IP-banned.

If you actually have time to do all that, you'll have a first-rate login form. I doubt you need that much.