We recently incorporated a handful of security features to the application. While most of the security measures we employ are behind-the-scenes, we wanted to highlight some of the more visible changes to explain why we made them. I should note that we haven’t made these changes because of any particular incident, but rather an attempt to proactively prevent problems before they occur.
Blocking Brute Force Logins
One of the most common threats against web applications is a script that repeatedly attempts to guess user passwords, also known as a brute-force attack. It’s a relatively simple attack to deploy — a hacker can write a script to try commonly used passwords, dictionary words, or sequential combinations of letters in order to find a valid password. Most servers and desktop computers have built-in protection against this kind of attack, but that’s generally not true for web applications. A brute force attack can usually run against a web application for days, even weeks or months.
There are a handful of ways to prevent brute force attacks. Desktop computers usually lock out an account for a set period of time after a series of invalid password attempts. This isn’t a great solution for web applications because someone might be trying to crack an account that a legitimate user is trying to access. Servers can also temporarily or permanently add the client IP address to a blacklist to prevent access to any services. This isn’t ideal either because there are so many cases where users share a single IP address. We might end up blocking an entire company or university because of one attacker, or just simply a single person who can’t remember his password and is making dozens of invalid attempts.
What we found to provide the best balance of security and usability, was the usage of a CAPTCHA image after a number of invalid password attempts. A user will need to enter the CAPTCHA code in addition to a password until a correct one is found. This should sufficiently block automated brute force attacks, without preventing valid users from logging in.
Password Strength Checker
Even with protection against brute force attacks, it’s important to ensure that all passwords have enough complexity to ensure that they can’t be easily guessed. The need to avoid commonly used passwords is best illustrated by The Plague:
We deployed a password strength checker to help users separate weak passwords from strong ones. We’ve added this to account passwords as well as data encryption passwords, with much more stringent checks applied to the latter. The password checker rates each password, with a higher score applied to those passwords with a good mix of letters, numbers and special characters. While it’s not perfect, it’s much better than a simple enforcement of minimum character length.
Reset Password Token
The last visible change we made was to the password recovery workflow. Previously, if you used the reset password link, we would email you a temporary password, and prompted you to change it once you logged in. With the change, you’re emailed a password reset token that needs to be entered before allowing you to change your password. It’s a subtle change, but what it does is prevent a denial-of-service attack where someone can repeatedly reset your password without your consent. The attacker wouldn’t be able to retrieve the temporary password without access to your email account, but you would be forced to use the temporary password to log in — an annoying inconvenience if done once, but a major pain if it was done over and over.