Protecting against credential stuffing attacks

With every major site that is breached, millions of credentials and other information are being stolen. With literally every site/service on the web asking users to login, people tend to use the same credentials across sites. Taking advantage of this, credential stuffing attacks are becoming more prevalent.

In a credential stuffing attack, credentials stolen from one site is tried against other sites in the hope that some of the users used the same credentials at more than one site.

For instance, you could have signed up to a electronic invitation site to manage your kid’s birthday party. The problem is that the invitation site may not have very strong protections (salting and hashing password, encryting other sensitive information, etc). Their network/application security may also not be very strong. If you have used the same credentials (userid and password) on your banking site also, you are potentially allowing someone to siphon off your money if the invitation site was breached and your credentials stolen.

Even if your banking site used the best encryption to protect the credentials on their end, an attacker can just try the credentials obtained from the other site and get into your accounts.

As a consumer, you can protect against this attack by

  • Not reusing the credentials across sites. Make sure that you use at least different passwords in each site/service
    • Consider using a password management tool to keep track of all the different credentials for the various sties.
  • Enabling multi-factor authentication (MFA), if the site/service supports it

As a site owner or service provider, you can protect against this attack by implementing one of more of the below methods:

  • Multi-factor authentication. Now there are different ways you can implement this. For instance, if the information stolen includes full name, date of birth and mobile phone number and your system uses an SMS OTP, it might still be possible for an attacker to obtain the OTPs, using SIM swapping attacks.
    • Ensure processes where your help desk does not allow deactivating MFA on accounts. The attackers may attempt to call your help desk, pass identification tests if they are based on the stolen data and remove MFA. Once that is done, your site will also be compromised.
  • Multi-step login process. By splitting the login process into several screens, you can make the attacker’s task more complicated. By also not showing an error message until all the data in the authentication process is submitted and not identifyin which credential was wrong, you can make the attack’s task more difficult.
  • Random Character Challenge. This involves challenging the user to enter specific characters from a knowledge based authentication factor. This would be something that the user either already configured (eg. answer to a question, a phrase} or it can be the for the password itself. Instead asking for the full word or phrase, you would ask for specific characters (3rd, 6th and 10th characters). By varying the position of the character you challenge the user to provide every time, you can protect against automated attacks to a certain extent. Be aware that this will complicate the way you store this particular element. If you hashed the entire string, it will be impossible to compare specific characters. So, you either have to encrypt it or store each letter separately as a hash. For this reason, I strongly recommend not to use the password for RCC, but have an additional element.
  • Traffic monitoring. Credential stuffing attacks are usually automated to enable the attacker to try out a large number of credentials. This means login attempts can be monitored to identify these attacks. For instance, if the number of login attempts or the number of failed logins spikes, then you are probably under attack. The key is to constantly watch out for these spikes.
  • IP Blocking.These automated attacks can usually be tied to a bunch of IP addresses and if you are looking for spikes in login attempts, you can block them. More sophisticated attacks may us botnets to spread the attack around a large number of compromised devices and IPs and some valid users may be affected as well. You can minimize the impact to your customers by making the IP blocks temporary – anything from 15 minutes to 24 hours.
  • Limiting Login attempts. Implementing a limit on consecutive invalid login attempts on a particular user account can also help. For instance, industry best practice usually calls for an account to be locked or suspended for a short interval after 5 consecutive invalid login attempts. Doing this can buy you and your users time to prevent account take over.
  • Device fingerprinting. Implementing device fingerprinting can help you identify attacks quicker. This works by generating a unique signature using javascript for each device that the user logs in from. There are two ways you can use this:
    • You can prompt for enhanced authentication if the device fingerprint changes or is new for that user.
    • You can look for the same device fingerprint being used to authenticate into multiple user accounts. Some customer may have 2-3 accounts, but if you see the same device fingerprint trying to login as 10 different users, you may want to block the device and investigate or even ask for enhanced authentication.
  • Behavior biometrics. One thing that is getting more prevalent is behavior biometrics. This works by creating a pattern of behavior that includes typing cadence, specific patterns in typos, and if on mobile how the user holds the device, pressure while touching the screen and a host of other parameters. Any deviation from the normal should be flagged and the user sent through an enhanced authentication journey.
    • Depending on the complexity of your aplication you be able able to implement some extra behavior analysis. For instance, if the user normally logs in with a specific time range, or from a specific location, or accesses the application in a certain way (the journey is the same every time), if it is a payment application, the payments are always within a particular range to a specific set of beneficiaries in specific cities or countries, etc. Anything anomalous to the normal pattern should be flagged for action or enhanced authentication.
  • Mobile push notifications. One enhanced authentication method may be using push notifications that are encrypted using key pairs. By binding a mobile device to a user and using private and public keys, you can send encrypted push notifications that can only be decrypted on the device by your app. This can protect against SIM swapping atacks as well and make the attacker’s task a lot more complicated.
  • Threat Intelligence. Some vendors provide services where they look for stolen credentials on the internet/dark web and for services that have signed up, provide real-time checks and alerts on potentially compromised credentials. For instance if user X had their credentials to one site stolen and that is now available on the dark web, and those credentials are being used on a site that has integrated the vendor solution, they will alert you to the fact that the login attempt may be unauthorized. You can then use IP checking or behavior biometrics or some other enhanced authentication (MFA) to vet the user and the login attempt. Some vendors bundle the behavior biometrics and the threat intelligence to provide a more authoritative alert on unauthoized login attempts.

Individually, none of these will be foolproof. However, I always recommend a “defense in depth” approach that uses multiple coverlapping controls. By using a combination of the above methods or all of these, you can dramatically reduce the chances of a successful credential stuffing attack on your site or service.

In addition, have an incident response plan ready, in the event of a successful attack:

  • Run simulations of credential stuffing attacks to rehearse your response.
  • Have communcations to customers prepared. You most probably also have to report the incident to regulators or other agencies.
  • Have a plan ready to invalidate credentials for the affected users or even all of your users. The user will then have to reset ther credentials to be able to use the service.
  • And if you had to activate this plan, you are going to have to plan on customers calling in because their credentials are not working anymore. You may want to augment your help desk as well.
  • Is turning off the service, even for a short time, an option? If you find out that any of the existing authentication methods that you already support are not sufficient, you may need time to implement something different.