How Much Security is Needed?

Freshness Warning
This article is over 14 years old. It's possible that the information you read below isn't current.

Simon Willison proposes some ideas for securing authentication systems for Web-based applications and brings up a point that I’ve never thought much about. If you have a system that locks out a user after too many incorrect logins, then it becomes easy for a malicious user to deny access to your users by simply attempting to log in as them.

This doesn’t apply only to malicious users, however. Apparently there’s a host of people who think that they registered on eBay using my user name. Several times each month I get a notice from eBay that indicates I’ve asked to change my password. Someone probably can’t remember their account details and tries several username and password combinations, requesting a password reset for each of them.

If banning is a bad idea, then how do you defend against a brute-force dictionary attack on your site? Simon goes on to suggest a series of alternatives, listing the pros and cons of each. One thing that needs to be mentioned, however, is that your security approach should be appropriate for the value of information that is being secured.

A banking site needs a lot more security than a membership-based newsletter site. So locking out the account of a user might be acceptable for your bank, even though it would be silly for securing your vacation photos.

I’d like to see a system that reacts to a hack attack intelligently combining several of Simon’s approaches with some other ideas.

Simon said:

Ban login requests from the attacker’s IP address. This introduces the usual problems with IP banning, namely the risk of banning a whole bunch of people indiscriminately but leaving the attacker free to skip the ban using open web proxies.

You could use temporary banning to make life difficult for the attacker. After 40 consecutive invalid logins on the same user account over a period of time, ban the source IP addresses of the last few attempts for a few minutes. Instead of taking a few hours to break an account, it would then take several days. And the impact to real users would be minimal.

Lock the user’s account and email them a warning of the attack and a special key needed to unlock the account again.

This special key would also be vulnerable to a dictionary attack. You can mitigate this concern by issuing new keys as the attack continues. Each time an account has a certain number of invalid logins, change the key and resend it. It’s hard to brute-force a constantly changing key.

For systems that don’t need a high level of security, instead of creating a special key, you could actually reset the password to a random string and email it to the user. The attacker now has a moving target to crack.

Send an automated alert to a system administrator so they can analyze the situation in real time and take any necessary action. This relies on administrators being available 24/7 - hardly a safe assumption for most systems.

If you’ve slowed down the attacker as noted above, this becomes a viable option.

Other interesting (and perhaps half-baked) options would be:

  • Once you detect an attack, redirect the attacker to a honeypot. Let them bang away at a system that has no correct passwords. Or “authenticate” them into a clone of your system that contains nothing but faked data.
  • Throttle the speed of the whole authentication system during an attack. A fifteen second delay will be hardly noticeable to real users but will slow an attacker down enough that you can take action.
  • After a few incorrect attempts, change the form submittal URL for that user. A real user will be submitting the form as it’s presented to them and would have no idea that it’s going to a different address. An automated attacker would be repeatedly submitting against the original URL, not knowing that the account was no longer allowed to authenticate through that URL.

Roland
January 22, 2004 3:43 AM

Displaying the time and date of last few logins may be usefull to detect if a login/password has been compromised without triggering an alert.

Trackback from Mark's blog
January 22, 2004 9:55 AM

Authentication security

Excerpt: Both Simon Willison and Adam Kalsey have made excellent posts about authentication security. This has come at a very appropriate time as Mike and I are developing an admin panel for SC3 just now. I'll definitely be implementing a delay...

Scott Johnson
January 23, 2004 4:14 PM

"After 40 consecutive invalid logins on the same user account over a period of time, ban the source IP addresses of the last few attempts for a few minutes." I really like this approach. The company that holds my mortgage has a draconian approach to locking out users. If you don't log in with the correct password within three tries, you are locked out for 24 hours. I've done this to my account several times. I've even mistakenly typed in the wrong username and locked out another's account. They will let you call an 800 number to unlock the account, but to me, that really ruins the purpose of the web. If I wanted to call an 800 number, I wouldn't have even bothered with the website.

Your comments:

Text only, no HTML. URLs will automatically be converted to links. Your email address is required, but it will not be displayed on the site.

Name:

Not your company or your SEO link. Comments without a real name will be deleted as spam.

Email: (not displayed)

If you don't feel comfortable giving me your real email address, don't expect me to feel comfortable publishing your comment.

Website (optional):

Follow me on Twitter

Best Of

  • Pitching Bloggers Forget what you learned in your PR classes. Start acting like a human instead of a marketer, and the humans behind the blogs will respond.
  • Debunking predictions Read/Write Web's authors have some goofy predictions.
  • Google on the desktop Google picks up Picasa, giving them an important foothold on people's PCs.
  • Best of Newly Digital There have been dozens of Newly Digital entries from all over the world. Here are some of the best.
  • Rounded corners in CSS There lots of ways to create rounded corners with CSS, but they always require lots of complex HTML and CSS. This is simpler.
  • More of the best »

Recently Read

Get More

Subscribe | Archives

14

Recently

Networking as an entrepreneur (Oct 23)
Having a network is crazy important. Networking is not.
Stretching your team (Jun 11)
Stretching your team is one of the best ways to improve your output, your team's happiness, and your velocity. But they'll need coaching.
Physical camera shutter for Cisco Spark Board (Jul 6)
A 3d printable design for a camera shutter for a Cisco Spark Board
My Travel Coffee Setup (Jan 20)
What my travel coffee brewing setup looks like, and how you can build your own for under $100.
Turkey Legs (May 30)
Product naming gone awry.
Speaking for Geeks: Your Slides (Dec 17)
Tips and tricks for creating great slides.
Speaking for Geeks: Writing Your Talk (Dec 14)
Don’t wait until the night before the talk to write it. Crazy, I know.
Speaking for Geeks: Tell a Story (Dec 13)
Telling a story keeps your presentation focused, keeps your audience interested, and makes it easier for you to remember your talk.

Subscribe to this site's feed.

Elsewhere

Tropo
Voice and communications platforms, including Tropo and Phono. Work.
SacStarts
The Sacramento technology startup community.
Pinewood Freak
Pinewood Derby tips and tricks

Contact

Adam Kalsey

Mobile: 916.600.2497

Email: adam AT kalsey.com

AIM or Skype: akalsey

Resume

PGP Key

©1999-2018 Adam Kalsey.
Content management by Movable Type.