- Bucket brigade attacks
- Replay attacks
- Cross-site Request Forgery (CSRF or XSRF) attacks
- Brute-force attacks
- Credential stuffing attacks
- List validation attacks
Bucket brigade attacks
One type of threat is a bucket brigade attack, sometimes called a “man-in-the-middle” attack, where the attacker gets between two parties. Each party thinks they are interacting over a private connection, but the interaction is actually being controlled by the third-party attacker. For this type of attack to succeed the attacker must create mutual authentication between both parties. Usually, bucket brigade attacks involve the attacker using a WiFi router to intercept a user’s communication. The user connects to the attacker’s router then visits a website and logs in with their confidential credentials. The attacker saves that user’s login credentials for which they can then use to impersonate the user. Some bucket brigade attacks can also modify the data transmitted between the application and the server. Attacks can occur from new PC trial and preinstalled software, software update tools, and other software vulnerabilities. In a worst-case scenario, this could result in remote code execution, backdooring the system, installing malware, and so on. This could also lead to the compromise of other network assets. To help defend against this type of attack it is important to use strong encryption and authentication between the application and the server. Using encryption the server authenticates the application’s request by presenting a digital certificate, and only then can the connection be established. For example, HTTPS uses the secure sockets layer (SSL) capability of the browser to mask web traffic. To decrypt HTTPS, an attacker would have to obtain the keys used to encrypt the network traffic. With the configuration of TLS on your servers, we suggest using the Mozilla OpSec recommendations which use TLSv1.2. Mozilla also provides an SSL Configuration Generator, to use this first choose which platform your server is running and then choose the most modern configuration based on what your application base can support. The more modern configurations provide stronger ciphers to help prevent attacks.Replay attacks
Replay (or playback) attacks allow attackers to:- Gain access to a network and information which would not have been easily accessible
- Complete a duplicate transaction
- Set a short expiration time for tokens
- Provide a way to add tokens to the DenyList that have been used (and possibly even the users)
- Use one-time passwords
jti
field as a way to prevent replay attacks. Though Auth0 tokens currently don’t return the jti
, you can add tokens to the DenyList using the jti
to prevent a token being used more than a specified number of times. In this way, you are implementing something similar to a (think of the token’s signature as the nonce). If a token gets stolen or it gets used more than the specified number of times, it should be added to the DenyList. This prevents a valid token from being used maliciously. Once the token expires, the attacker will no longer be able to impersonate the user.
You can also avoid replay attacks by using one-time passwords. With Auth0, you can use Authentication, which relies on single-use codes and email links instead of traditional passwords. Auth0 also provides (MFA) which uses one-time passwords as a second-factor authentication which can be sent via push notifications and texts.