What This Year’s Data Breaches Reveal About Identity

Another year, another litany of data breaches. While attacker tactics, techniques and procedures (TTPs) morph and evolve from year to year, one thing remains constant: The attacker’s goal is to somehow compromise the victim’s identity. Last year’s Verizon Data Breach Investigations Report (DBIR) cited that 80% of basic web application attacks were caused by the use of stolen credentials.

This article draws themes from prominent data breaches over the past few months and provides key takeaways for end users, application developers and security practitioners to help stop history from repeating itself.

Credential Stuffing Remains Effective

In mid-January 2023, Norton LifeLock sent data breach notifications to customers about a credential stuffing attack that attempted to break into Norton accounts as well as password manager accounts. Soon after, PayPal reported a massive credential-stuffing attack that impacted over 35,000 accounts.

Credential stuffing is a type of cyberattack where attackers obtain credentials from a data breach on one service and then use those credentials to attempt logging in to other unrelated services. This is not a new or sophisticated technique, but it remains an effective way for cybercriminals to take over victims’ accounts. Akamai found that 193 billion login attempts in 2021 were attributed to credential stuffing attempts.

The driving force behind the continued effectiveness of credential stuffing is the tendency to reuse passwords across sites. This behavior is driven by fear and forgetfulness. In a 2022 survey, 64% of respondents cited that they would avoid visiting certain websites or accounts where they have forgotten their password. An easy—yet risky—“fix” for this forgetfulness is having a few favorite passwords that get reused across sites, to everyone’s detriment.

Who Watches the Watchmen?

Password managers have been growing in adoption over the years, which is certainly a positive development. However, protecting hundreds of passwords with one master password is bound to cause some anxiety if something goes wrong. A few months ago, LastPass and parent company GoTo informed users of multiple data breaches where attackers stole usernames, salted and hashed passwords, and even some multifactor authentication (MFA) settings.

Password managers generally encrypt passwords and employ measures to ensure that, even if passwords are stolen, attackers aren’t able to readily use them. This is good news, but it’s also deferred bad news. If we know anything about adversaries, it’s only a matter of time before a vulnerability or bypass is discovered that makes the next password management company breach much worse for everyone involved.

Looking beyond individual breaches, this raises an important question for application builders about the need for passwords in the first place. If you’re building an app today, there’s no upside to having shared secrets like passwords for your users – not from a usability perspective and certainly not from a security perspective. The best password is no password because then there’s nothing for attackers to steal (encrypted or otherwise).

Mind Your Sessions

Credentials aren’t always passwords. A session ID for an authenticated session is considered a very strong authentication method. Attackers getting a user’s session ID is as dangerous as attackers getting a user’s login credential because an external party with a stolen session ID has the same access to resources and functionalities as an authenticated user.

This is what happened at CircleCI. Adversaries infected an engineer’s system with malware to steal their 2FA-backed session cookie and used it to impersonate the employee. Since the employee had privileges to generate production access tokens, the attacker was able to exfiltrate encrypted data as well as encryption keys that could allow them to access the data.

As long as we continue using stateless protocols like HTTP, session management best practices must be kept in mind–from simple fixes like not appending the session ID in the URL and using HTTPS, to more nuanced considerations, like defining session lengths based on the sensitivity of your application.


So, what can we learn from last year’s breaches as they relate to identity? It’s important to preface this section by stating that silver bullets and panaceas do not exist in cybersecurity – the best we can do is respect the basics and continue raising the bar for adversaries so that it’s much harder (not impossible) for them to cause compromise.

With that in mind, here are some key takeaways:

End users
● Exercise some healthy paranoia and assume your go-to password has been leaked or will be soon.
● Do not reuse passwords across online accounts.
● If creating a new account with multiple authentication options available, look for a passwordless method like social login, biometrics, magic links or one-time passcodes. One less password on the internet is one less password that can be used in credential stuffing.
● If you are using a password manager, do not reuse your master password on any other site in case that site gets breached.
● Never stay logged in to any sensitive application. Never stay logged in to any application or website when you are on a system you do not usually use.

Application developers and security practitioners
● Whether you are building an app or already have one, consider moving to passwordless authentication. You can onboard and retain more users by not imposing the cognitive load of creating and remembering passwords. Passwordless authentication also greatly reduces your attack surface and nips attacks like credential stuffing and brute force in the bud.
● Follow secure session management. Don’t keep your app’s session lengths longer than they need to be. Issue a new session identifier after authentication is completed to prevent session fixation attacks. Set session ID cookies to HttpOnly to prevent cross-site scripting attacks.
● Take measures to prevent the theft of refresh tokens. Refresh token rotation is an effective technique that returns a new refresh token every time a new access token is requested. Tying refresh tokens to the device ID can also help prevent MFA bypass where attackers impersonate victims from a remote location.

Avatar photo

Rishi Bhargava

Rishi Bhargava is a co-founder and CRO at Descope, a stealth startup building something in the authentication space for application developers. In a career spanning over 20 years, Rishi has run product, strategy, go-to-market, and engineering for category-creating cybersecurity startups and large enterprises. Before Descope, Rishi served as VP of Product Strategy at Palo Alto Networks which he joined via the acquisition of Demisto, a security operations startup. Rishi was a co-founder at Demisto where, under his stewardship, the company created and later led a new “security orchestration” category within 3 years before being acquired. Prior to Demisto, Rishi was VP and GM of the Datacenter Group at Intel Security, launched multiple products at McAfee (acquired by Intel), and played a key role in product strategy and growth at change management startup Solidcore (acquired by McAfee). is passionate about technology and serves as an active investor and advisor to multiple startups in Silicon Valley and India, some of which have already seen successful exits. Rishi has over a dozen issued patents in the area of Computer Security and holds a B. S. in Computer Science from the Indian Institute of Technology, New Delhi.

rishi-bhargava has 1 posts and counting.See all posts by rishi-bhargava