Web Application Security Basics- Authentication and Session Management (Part II)

The most common way of dealing with forgot password is asking for username from user and sending an email with a onetime link to the user to reset password. Most of the financial institutions such as banks do not trust the security of emails as a fundamental part of forgot password workflow. The reason behind this is that email was with privacy and security in mind.

The following steps are a good workflow to be followed when implementing forgot password feature.

1. Establish the user’s identity with requests for two or more pieces of information such as the user’s Social Security number and account number. Start a session for this process and ensure that the rest of the process comes from the same session.

2. Once you have successfully established the identity of that user, as an optional step, consider asking the user a security question that users set up during registration.

3. Now that you have fully established identity, send a multi-factor token out of band. The best bet is to use a dedicated multi-factor device or application. Next best is to use SMS to the phone number on the account. The worst option is to send a token over email, but by having already established identity this is still better than an email password reset link alone.

4. Once you have verified that the user’s token is valid, allow the user to reset his or her password to a new, strong value according to your organization’s password policy.

For more information the OWASP Forgot Password Cheat Sheet by David Ferguson is a good resource.

Username Harvesting

Username harvesting occurs when an attacker tries to verify if a username is valid or not. This could be done in many ways and even including simple ways such as examining the error messages!. If an error message for a correct username and a wrong password states “Wrong password” this will imply that the entered username is a valid username.Setting up a generic error message is important to prevent this type of attacks.

However, it’s pointless to protect against username harvesting if you allow users to select their own username during account registration. Consumer-centric websites almost always verify if a requested username is in use already and disallow that choice if a duplicate name is selected.

This can easily be leveraged by an attacker to harvest valid usernames. In fact, some user registration mechanisms provide an AJAX-like widget to verify if a requested username is valid or not.

An attacker working with a list of names and email addresses can leverage these features to quickly harvest a large number of valid usernames.Consider implementing a throttle to slow down automated requests to these mechanisms.

Brute force attacks and account lockouts

A brute force attack occurs when an attacker attempts many passwords in high volume against a victim’s account, attempting to discover their authentication credentials through trial and error.

The most common defense is account lockout. Account lockout is a defense by which, after an attacker attempts to incorrectly log in to an account a certain number of times, the account will be disabled temporarily preventing anyone from logging in to the account.

If an attacker has knowledge of various usernames in your system, account lockout can be used to conduct a denial of service attack against your web application, effectively stopping any user from logging in to their account.

The Remember Me feature

In order to support the “remember me” feature, you essentially need to keep the user logged in for days, weeks, or months, something that is in direct opposition to everything we have discussed about properly limiting an authenticated session.

Also, “remember me” features are often subject to a replay attack. They often require that you store a credential or a session identifier in a cookie with no expiration. , an attacker who steals your cookies can replay that encrypted cookie in his own browser, use your server for decryption, and compromise the account.. If the business forces you to support a “remember me” feature, consider just remembering the username and prefill it on the login screen.

Multi-Factor Authentication

Using password as a sole authentication credential is not accepted in the modern security world. Multi-factor, or multi-step, authentication involves requiring two or more factors at login time (as well as during re-authentication).

Multi-factor authentication reduces the impact of password theft, mitigates bruteforce attacks without the need for account lockout, and in general protects the front door of your web application in a way that is much stronger than username and password alone.

Federated Identity and SAML

SAML, the Security Assertion Markup Language, is a way to federate or delegate authentication and access control information between two different systems, often in different organizations.

Let the following example explain the need and usage of federated identity.

eg:

Imagine that your website gains significant popularity. For example, you may have built a website that offers a new and clever way for people to buy specialized lamps and other lighting products. Now suppose that website reaches popularity of epic proportions.

Now suppose a major company wants your website to give many thousands of their employees specialized access in order to purchase co-branded lamps for promotional purposes. This access may include very proprietary information (who are you selling lamps to?) that only company members should access. Normally, your business partner would need to create and manage the accounts and passwords for these thousands of employees on your website.

Every time a new employee is hired a new account would need to be created on your website. Every time an employee leaves the company the account would need to be removed. For a company with thousands of employees this quickly becomes an administrative nightmare.

What if instead of your partner having to create and manage thousands of user accounts on your website, they could manage those accounts on their own systems? Suppose you had an arrangement with your partner (leveraging Single Sign On technology) that a user only needed to log in to your partner’s authentication provider and, based on a prearranged “handshake,” that user would automatically be authenticated to your awesome new lamp website because of your partner’s assertion that the user is legitimate? This is the heart of what SAML and identity federation provide.

Open Authorization (OAuth) is a protocol that allows your web application to authenticate against other services on behalf of your users. This protocol allows your web application to authenticate to the OAuth service on behalf of your users without requiring you to store any credentials. If necessary, your web application can authenticate to another service without your users even being logged in to your application. For example, if you would like your website to “tweet” on behalf of your users, without ever needing to know (and therefore protect) your users’ Twitter passwords or other sensitive information, OAuth is the protocol to accomplish this feat.

Originally published at http://neatrick.wordpress.com on October 1, 2015.