We're familiar with attacks that try to compromise your usernames and passwords. Weak passwords can be cracked. Reused passwords are vulnerable to credential-stuffing and password-spraying attacks. Phishing scams try to steal usernames and passwords outright.
All of these are "pre-authentication" attacks. They try to obtain your credentials so that attackers can then log into a service as you.
But there are also ways to get into your account after you've logged in. Most of these involve stealing or abusing the session tokens that are granted to legitimate users upon a successful login. We call these "post-authentication" attacks.
Post-authentication attacks can bypass multi-factor authentication (MFA) and remain invisible to the legitimate user and the service being accessed. They can defeat even the most modern forms of authentication, including hardware keys and passkeys.
It doesn't matter how strong a form of authentication is, or how many factors are used, if the post-authentication session token can be stolen.
"The battleground has really shifted over the past 12 months," Okta Chief Security Officer David Bradbury said in a recent interview. "It's no longer about pre-authentication/before login attacks. It's about post-authentication attacks."
Passing the token
When you log into an online account, whether in a web browser or a mobile app, the online service's server assigns your device a "session token," which is attached to each subsequent interaction to remind the server that you're an authorized user. Otherwise, a website might ask you to log in every time you clicked to another page or submitted a form.
The session token is usually a long string of random numbers and letters, and it's meant to be temporary. When you log out of the service, the token is erased from both your device and the server your device is interacting with.
However, some session tokens last a very long time. If you're a frequent Twitter/X user, you may have noticed that you almost never have to log back in again unless you're using a new machine. That's because Twitter/X session tokens are essentially indefinite.
Unless you actively log out, you'll stay logged in — even if you reboot your PC or phone. The session tokens for Gmail and Facebook are nearly as long-lived.
But those are extreme examples. In the workplace, company policies normally mandate that a user must log back in again to workplace services and applications much more frequently, sometimes more than once a day. Logging out "clears" the session tokens so that you can start fresh.
In web browsers, session tokens take the form of "cookies," the same sort of temporary ID that can also be used for tracking users and analyzing behavior. Mobile apps store session tokens in internal databases.
There are other forms of authentication tokens as well, not all of which may be temporary:
OAuth tokens are often used by "social" login schemes that let you log into websites with your Google or Facebook credentials.
Machine certificates are used to verify device identity when establishing secure HTTPS or VPN connections.
API keys are used to authenticate communications in automated interactions between processes and devices across a network, or even the internet.
Stealing tokens
As MFA, biometrics, hardware keys and other forms of strong authentication have gained ground, attackers have pivoted to stealing and abusing authentication tokens as a workaround.
"It's easier to go after these tokens, these strings of numbers and letters," said Bradbury. "Why go through the front door when the window is open?"
Unfortunately, almost every kind of authentication token can be stolen. Unless completely secure communications are used during the authentication process, a token can be "packet sniffed" by software that monitors network traffic.
Likewise, unless strong encryption is used to store data, authentication tokens can be stolen by malware that has infected devices.
The best-known post-authentication attack is a session hijack, which involves the theft and misuse of browser session cookies. In addition to packet sniffing, attackers have several ways of stealing session cookies:
Malicious browser plug-ins or extensions: Mini-apps that can be added as extra browser features can often spy on user activity, including the transmission and storage of session tokens to and from third-party services.
Even extensions and plug-ins found in the Chrome Web Store or Firefox Add-Ons library can be malicious. Don't install any browser extension that you don't truly need.
Cross-site scripting and cross-site request forgeries: These two types of attacks on web browsers and web apps can be combined into a one-two punch that first injects malicious code into a client's browser or web app, then sends malicious requests to a website to steal session cookies. Cross-site scripting can also steal cookies on its own.
Malware infections: Malicious software that goes beyond the browser to infect the PC itself can scan the browser's local storage for session cookies, try to intercept data packets between the browser and the network ports, or even try to scrape running system memory to extract cookies there.
You can normally get rid of malicious browser extensions by disabling them, but malware is more persistent and may need to be flushed out by endpoint-protection or antivirus software.
"They're actually just gonna go straight to your browser and steal that little session token cookie that's in your browser," Bradbury said in another recent interview. "And they're just gonna copy it and paste it into their own browser and access all your applications."
Protecting yourself against post-authentication attacks
Fortunately, there are several ways to guard against, if not completely prevent, the theft of authentication tokens.
Limit the lifespan of authentication tokens. If you're administrating an in-house website or web apps, set session tokens and OAuth tokens for regular users to expire every 12 or 24 hours. And make sure that machine certificates and API keys are not immortal — they should have short lifespans as well.
Make admin tokens as short-lived as possible. If possible, govern admin authentication tokens through a privileged access management (PAM) platform, and consider using just-in-time authentication for admin accounts.
"The default session duration for Okta administrator sessions is 12 hours maximum and 15 minutes idle," said Brett Winterford, Regional Chief Security Officer for Asia-Pacific-Japan at Okta. "This is a key control against stolen session tokens."
Force user logouts. Regular users of in-house apps and websites should be logged out daily to clear session tokens from their browsers and web apps.
Strongly encrypt network transmissions. Website and web-app sessions should be HTTPS all the way through so that the machine certificates used to establish secure links cannot be stolen during the client-server "handshake."
Strongly encrypt storage of authentication tokens. Do this to make sure that malware can't read stored tokens in database or in running memory.
Limit browser extensions. Block users from installing unapproved extensions on managed workplace browsers and educate them on why that's necessary.
Force browser updates. Make sure that your employee browsers are kept up-to-date and fully patched.
Run and use endpoint/antivirus software. Endpoint protection software is still the best defense against malware infection. Make sure it's on all your workplace endpoints and consider paying for antivirus software for employees who access your network remotely using their own devices.
Monitor usage of session tokens. If you're administering a website or web apps, you can track where the session tokens are coming from and try to block those being used from unexpected locations or at off hours.
Implement session binding. It's possible to "bind" session tokens to a specific device. Microsoft and Google both tried several years ago to tie session tokens to the transport-layer security (TLS) mechanism that authenticates a secure session between a client and a server. But those efforts seem to have stalled.
"If we had the mechanism, which was provided by WebAuth some years ago when their specification was drafted, we would've been able to bind these tokens to the browser that you're currently using," said Bradbury. "But sadly, that wasn't implemented or adopted by Google or Microsoft in their browsers."
Now, both Microsoft and Google are attempting to bind session tokens to the Trusted Platform Modules (TPM) found on most modern Windows PCs, but the protocols are still in development.
Fortunately, third-party solutions like Okta already allow session binding for administrative accounts, which should make session hijacks of admin accounts nearly impossible.
Winterford recommends that "Okta customers apply IP session binding to administrator sessions (ASN Session Binding is on by default) and apply policy conditions in which users are prompted to re-authenticate as they access a sensitive application mid-session."
Bradbury is optimistic that the TPM-focused token-binding efforts will come to fruition, and notes that Okta is part of the development process.
"We are a key partner building this with Google to adopt this for all Okta's customers and to bind these tokens so that no one can steal them, that they will actually cryptographically secure these using the TPMs in your laptops to ensure that when you log in to a corporate application, the token that sits in your browser as a cookie cannot be taken by a threat actor," he said.
