Pre-Authentication vs Post-Authentication Attacks
Heya,
The more we interact with systems that affect the real world using online accounts, the more important it is to secure those accounts. There are two kinds of attacks, as outlined in this article. Pre-authentication attacks attempt to take over or gain access to users’ accounts, via phishing or credential stuffing, among other attacks. Post-authentication attacks exploit weaknesses in applications after the user has logged in.
Customer identity and access management software often focuses on preventing pre-authentication attacks. Efforts to do so include password hashing to prevent credential stuffing, multi-factor authentication (MFA) to add additional layers of security to online access, and integrating solutions like CAPTCHA to slow down bot attacks. All of these make it more difficult for nefarious users to gain access to user accounts.
Post-authentication attacks are different. Common post-authentication attacks include:
CSRF attacks trick a user into submitting a request provided by an attacker. This request is done as the user, including sending session tokens. This opens up a channel of attack, such as changing an email address.
XSS attacks inject a malicious script into an application. The script can then take additional steps, like transmitting private information to an attacker. More here at OWASP.
CIAM systems typically integrate with an application, but do not control application behavior after use log in. Instead, the application holds a token or session identifier indicating successful login, perhaps with other user characteristics such as roles. Because of this, it’s difficult for an auth server to offer robust protection against post-authentication attacks. These attempts focus on the application which delegated authentication to the auth server, not in the auth server itself.
There are some steps that can be taken, though.
A CIAM system can bind tokens to a client. There are a few standards out there, but one of the most promising ones is DPoP. It is not yet widely adopted, however. This lessens the value of bearer tokens, because if they are stolen they can't be used.
Auth system providers, whether commercial or open source, can educate developers on safe ways to handle tokens and prevent attacks. Developers often look to auth system documentation and support teams for help on implementation, so the purveyors of software can document safe integration patterns and secure ways to handle sessions and tokens.
If the application uses the CIAM system for session management, additional protections can be implemented, such as monitoring sessions for strange behavior such as connecting from a bizarre location or time. An auth system can also send messages to fraud tracking systems or users when new devices are used to log in. Doing involves a deeper integration between the application and the CIAM system, because the application is now communicating with the CIAM system to determine session validity. But this approach does offer the application developer protection against some of the post-authentication attacks.
The article also gives some other advice. It tends to be focused on employee users rather than customers. The advice includes:
limiting token lifespan, especially of tokens issued to admins (this lessens the value of stoken bearer tokens)
encrypting network calls (yes, apparently you still have to tell folks to use HTTPS)
logging out users daily (this works well for employees who are paid to access your system, but customers may take a dim view of this and bail on your app--test this)
I like the framing of post-authentication attacks as an entirely separate class of malicious behavior.
After all, security concerns don't stop when the user successfully logs in.
Cheers,
Dan