User Authentication: It Doesn't Belong In Your Application

When building Web-based app, you've got a thousand design and implementation decisions to make -- decisions that affect the usability and performance of your application, as well as its key functionality. Unfortunately, user authentication is typically the last thing you spend design cycles on. Just do what you've always done -- create a user database with accounts and passwords, and maybe hash the passwords for good measure.

That approach doesn't work anymore. The online world is a complex place, and your application doesn't operate in isolation .The problem isn't so much one of technology as it is your users themselves. With dozens of accounts and passwords to manage, what do people do? They share them between applications. This means that even if your password file isn't compromised, attackers can still find ways into your data. And whether or not it's your fault, it's always your problem.

The best illustration of this is the recent concentrated password attack on accounts belonging to Twitter employees. The attacker managed to get access to a personal email account and, through a combination of doggedness, password guessing and password resets, discover and break into numerous other accounts hosting Twitter corporate data as well as personal information. And in doing so they demonstrated how even one authentication problem can compromise a whole chain of accounts.

What does this mean to you, as you develop your own Web applications? You've got two choices:

You can do what you've always done, setting up accounts and passwords and maintaining them in your application, and wait for problems to happen.

Or you can decouple the authentication process from your application and take advantage of the growing acceptance of standards like SAML and OpenID to let dedicated Identity Providers take on the responsibility of authenticating users.

Is it worth the hassle to research and implement federation standards for a simple user authentication? Let's take a look a closer look at the alternatives.

Rolling Your Own Authentication

Let's say you're old-fashioned and maintain a database of User IDs and passwords. You hash the passwords, so security's not an issue, right? Not so fast.

If an attacker manages to break into your application, they've got everything they need -- the hashed passwords might slow them down, but it won't stop them.

And it's not just your site that you have to secure -- you have to encrypt your backups, too. Because everything an attacker needs to steal your user accounts is right there on the backup tape.

As long as authentication is part of your total application, you've got security issues. You have to protect the database, and monitor it carefully, so you can tell immediately when it's been compromised. (Remember, today's attackers are more interested in stealth and financial gain than hacker glory, on the whole.) You have to protect the backups, dispose of tapes securely, etc.

Don't Store Authentication Information In Your Application

Here's a better idea: Never store the authentication information in the application itself. Keep it separate, so that even if your application is compromised, that cannot translate into larger password thefts and attacks. Today's attackers are looking for more than just the data in your application -- they're looking for accounts and passwords that they can try to use to break into other, more sensitive applications (again, see the Twitter password attack description.) If you authenticate to an external directory, you've at least put some distance between your app and its passwords.

Don't Forget the Forgotten Passwords

The other day I forgot the password to the Web application that manages my 401K. So I clicked the "Forgot password" link -- and was dismayed to find that the application sent me my password, in clear text, in an email. Not only are they storing my authentication information in their application, but they're handing it out to anyone who asks and can answer a few questions about me.

Attackers love the forgotten password or password reset routines -- instead of defeating the password security, all they have to do is fake-out the password reset process. Remember the hackers who broke into Sarah Palin's Yahoo email account in the run-up to the 2008 election? They did so by resetting the password to the email, after guessing or researching the answers to her "personal" security questions.

At a minimum, a forgotten password routine should never send the password in clear text. And in the Twitter attack mentioned above, it was an emailed password that gave the attacker entry into a larger number of accounts. Better to use an out-of-band process (such as a phone call to a registered phone number) to deliver a one-time account reset code.

The forgotten password routine should also never give the user a chance to change the out-of-band location (email, phone number, physical address, etc.) that receives the account reset code. It sounds obvious, but it happens.

Authentication Security Is Always Your Problem

Let's say you have great confidence that no one can break into your servers or steal your passwords, and you have taken care with password reset and forgotten password routines. You've done your job, right?

You're still not in the clear. Increasingly sophisticated attackers are often successful at fooling users into giving away their passwords to phishing attacks.

If many of your users are affected by a phishing attack and inadvertently give someone else access to their accounts, you still have to deal with the problem by:

Notifying users of the phishing attack -- or warning them not to fall victim to it.

Taking action to identify affected accounts and temporarily stop access until you can restore them to their original owners.

In other words, you've still got to do damage control for this problem that was in no way your fault. Can you protect against it? Only by strengthening authentication with a second factor, so that someone who steals a password cannot access your application. Now we're starting to talk about some real authentication work. It's time to either become an expert in identity services, or to take another look at federation standards.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!