If you’re in the process of building a web application or, thinking about having one built for you, you’re probably aware you need to take security seriously. There is a basic minimum level of security any application should have in place. For example, a user shouldn’t be able to access the server or database of the application directly, a user shouldn’t be able to access private data not intended for them, etc. Many of these basic points have been widely discussed, but there’s a number of additional features which can be added to improve security which you may not have come across before.
Two factor authentication
Two factor authentication (2FA) is one of the most common security additions and is already available on many high value services such as banking websites or large service providers such as gmail. 2FA is primarily used on login pages to protect against the risk of a username and password being obtained by attackers and allowing them access to an application. Usernames are usually considered public, so logins on many websites are secured only by ‘something you know’ – the password. 2FA works by adding another factor – usually ‘something you have’ such as entering a numeric code from an authenticator app on your phone or plugging in a physical USB key. This means that if someone discovers your password they still can’t log in as they don’t have the additional factor such as your phone, with an authenticator or the USB key.
The decision to support 2FA in your app will probably depend on the value to an attacker of obtaining access to an account, the risk of this happening and the damage they might be able to do with it. One common option is to only require 2FA for admin accounts, as these have access to more data within the application. The increased security does add some additional hassle for users who need to enable 2FA on their accounts and ensure they don’t lose the device/key used with it.
Excluding common passwords or breached credential data
While security best practices state that you use a different password is used for each online account, evidence suggests that many users are reusing the same common passwords. One of the problems that this creates is that if a site is attacked and usernames and passwords are stolen, an attacker may test these users against other common sites. Should any users have the same password on your site as the one they used on another compromised site, the attacker may be able to log into your site using the details from the other site.
Details of attacked sites are often published by researchers as soon as they’re disclosed so it’s possible to use this data to compare against the list of users in your site and notify them or temporarily disable their account if they’re reusing a password.
Along the same lines, many users will use a simple password such as ‘password’ or ‘12345678’ which an attacker may try against a number of accounts to try and gain access. Common password lists are also published by security researchers, so it’s possible to check these lists when users create an account or update their password and prevent them from using a common, easily guessed password.
As with 2FA, the decision to include this functionality in your application will depend on the functionality or data an attacker would have access to with a compromised account, and the risk of the application being targeted by these sort of attacks.
Reauthenticating the user on high value transactions
Normally once logged in to an app or web application, you won’t be required to log in again unless you manually log out or are logged out due to inactivity. Sometimes, you’ll find the app asks you to re-enter your password (or use another form of authentication such as a fingerprint), before performing a certain actions such as making a purchase.
This form of reauthentication is designed to ensure the person currently using the app is the same person who originally logged in, and the action within the app isn’t being taken by someone else – the common example being a child accidently purchasing something via an unlocked mobile phone, but this could be any attacker who’s managed to gain access to the user’s device in some way.
Typically, the most important transaction to secure is the ‘change password’ screen, so you’ll often find you’re asked to enter your password here, as this prevents an attacker who has access to your device but not your password, from resetting the password and completely taking over your account.
We would suggest all applications require reauthentication when changing a password (or email address as the password reset process can allow an attacker to take over the account), but also that all actions within the application are reviewed and any which allow access to particularly sensitive data, payments or irrevocable actions, require reauthentication of the user before allowing these to be performed.
Audit logging
An audit log is a record of every action which is taken within the application by every user. While an audit log won’t help prevent an attack against the application, it may help in detecting an attack or identifying exactly what data or functionality was compromised should an attack happen.
An audit log will typically record actions such as a user logging in or logging out, a user attempting to access data or functionality they don’t have access to or access to large amounts of sensitive data within the application. It will also record identifying information about the affected users, location and date of attacks, allowing the relevant users to be identified in case of an attack.
Ideally all applications should have an audit log recording certain security related transactions (login attempts, failed access to resources etc.), and applications containing sensitive data should have a full audit log recording all access to sensitive data.
Rate limiting / brute force protection
Along the lines of an audit log, rate limiting doesn’t just monitor a user’s access to various features in the application, but tracks the number of accesses over a certain time and should it detect the user exceeding a certain limit, specific action will be taken.
The most common example of this functionality is protection against ‘brute forcing’ the login process. This is when attackers try a large number of user/password combinations in the hope of finding a valid user login. Brute-force login protection would typically only allow a small number of attempts to enter the correct password before locking an account either temporarily or permanently.
Apart from logins, there may be a number of other areas which should be rate limited, e.g access to user data to detect and prevent a compromised account from retrieving user data for a large number of users within the system.
All applications should have rate limiting on login to prevent the brute forcing of user credentials, whether your application requires further rate limiting will generally depend on the amount of sensitive data held within the application and the risk should this data be compromised.
What’s next?
These five security features are just a few of many different features you may want to consider if you’re having a web application developed, or attempting to improve security on an existing application.
While some of the features are essential, a large number depend on the sensitivity of the data and functionality within your application, and the risk of it being compromised, so it can be difficult to know exactly what features need implementing for your own app.
If you’d like to discuss potential security options further, or would like us to provide a security review of an existing application please get in touch.