Mitigation Strategies

Overview

Mitigating vulnerabilities stemming from faults in authentication and authorization is a critical element that developers often overlook. These vulnerabilities are some of the very first ones that hackers and pentesters start checking when they set a target, so fortifying the most common attack vectors makes sense.

Multi-factor authentication (MFA)

We’ve already discussed the need for MFA earlier in this chapter. The most common form of MFA for almost all web applications available today is one-time password (OTP) codes that are sent to email accounts and phones. For example, it’s now almost impossible to create a new Google, Facebook, and Twitter account without handing them our phone number for two-factor authentication (2FA).

At a broader level, important employees of large companies are often given long, strong passwords from a password store that frequently change and a physical key card with a chip, without which they can’t gain physical entry into locations and use their company provided laptops. At some places, the laptops may also require OTP codes that are sent to the employees’ company managed phones (and numbers).

Good password practices

Passwords are integral. They may not be optimal, but in some cases, they’re the most the average user is willing to put up with. That’s why there has been a lot of work put into them. Some important points to consider are:

• Web applications should encourage users to generate strong, memorable passwords. Strong passwords are always long and personalized to the user setting them. For example, an American rancher with a sweet tooth is more likely to remember a long password such as “rockflagAndBIGjollyrancher*.”
• Websites should place reasonable character limits for passwords. Password managers are becoming increasingly common, and as such, a character limit of 8 or even 32 just isn’t going to cut it anymore.
• Discourage users from using easy, common, or short passwords. These types of passwords make their way into rainbow tables (a list of common passwords) and prove disastrous. So no, variants of “password,” like “pa55w0rD,” are not secure.
• Developers should ensure that their password store at the very least employs salted hashing. Using a robust hashing algorithm is a good idea because when an attacker compromises the system, all they’ll see is hashes. These hashes are not worth much to the average hacker. However, more determined and resourceful adversaries will always have the time, power, and money to crack these hashes in due time. Salting refers to appending some random text to the user’s password before hashing it in an effort to ensure that the same password does not result in the same hash.
• Implement honeywords. If a hacker uses a rainbow table, passwords or hashes from known breaches, or even old passwords from the target’s own password store to log in, the target system raises an alarm, and then the system administrator can decide on a counter strategy.

These security issues should be considered in depth before deciding how to set up password authentication for our website. For a comprehensive look at what not to do, check out the collection at Dumb Password Rules.

Let’s look at an example from the collection of what we absolutely should not do. ING Australia, a bank, once decided that a four character long, only numerical password was good enough. For extra safety, they randomized the numbers on the keypad, but that’s not even close to the level of security required to hinder the efforts of a determined hacker.