On 5 June 2012, a file containing roughly 6.5 million password hashes appeared on a Russian password-cracking forum. The poster was asking for help breaking the ones they could not crack themselves. Within days, researchers had established where the hashes came from and how badly they had been stored: unsalted SHA-1, a scheme already considered inadequate at the time. Around 90% of the hashes were reportedly cracked within a week.[1] LinkedIn confirmed the breach, reset the affected passwords, and moved on. The stock was broadly unaffected. No executive lost a job. Regulatory consequences were negligible. The story would be unremarkable except for what emerged four years later. In May 2016, a far larger dataset from the same 2012 intrusion surfaced for sale — in the region of 100 million records, with Have I Been Pwned ultimately listing over 164 million email addresses from the incident.[2] The 2012 disclosure had understated the breach by more than an order of magnitude, and nobody — including LinkedIn — had known. That gap between what was reported in 2012 and what was true is the actual lesson of this breach, and it is a lesson about incentives rather than about cryptography.
What Went Wrong Technically
The password storage failure was not subtle, and it was already avoidable using well-documented practice. No salt. A salt is a unique random value added to each password before hashing. Without it, identical passwords produce identical hashes, which allows an attacker to crack a whole database at once using precomputed tables rather than attacking each password individually. Salting was standard advice long before 2012. A fast hash function. SHA-1 is designed for speed, which is exactly wrong for password storage. Purpose-built password hashing functions — bcrypt existed from 1999, PBKDF2 was standardised, scrypt was published in 2009 — are deliberately slow and tunable, so that each guess costs the attacker meaningful compute. Using a fast general-purpose hash made mass cracking cheap. An injection vulnerability as the entry point. Reporting attributed the intrusion to SQL injection, a class of flaw that had been thoroughly documented for over a decade and topped every application security list of the period. None of these were novel failures. They were known-bad practices that persisted because nothing had forced a review.
Why the Consequences Were So Mild
It is worth being precise about why this breach produced so little accountability, because the mechanism explains most of the security under-investment of the era. The costs fell on users, not on the company. A cracked password is dangerous mainly because people reuse it. The damage — compromised email, banking, other services — landed on individuals, distributed thinly, and was largely unattributable to the original breach. The regulatory framework had no teeth here. In 2012, US breach notification law was a patchwork of state statutes focused primarily on financial and identity data. GDPR was a draft proposal published four months earlier, and would not be enforceable for another six years. There was no regulator with authority to impose a consequence proportionate to the failure. Disclosure was incomplete and nobody could check. LinkedIn reported what it knew, which turned out to be a fraction of what had been taken. Without forensic obligations or external verification, the reported scope of a breach was effectively self-certified. Users did not leave. The service was valuable and the alternative was non-existent. Switching costs on a professional network are unusually high, which removed the market discipline that might otherwise have applied. The rational conclusion for any company observing this in 2012 was that inadequate password storage carried limited business risk. That conclusion was correct for several more years, and it explains why comparable failures kept appearing.
Practical Guidance for Credential Security
- Use a purpose-built password hashing function with a per-user salt. Argon2id is the current recommendation; bcrypt and scrypt remain acceptable. A general-purpose hash — SHA-1, SHA-256, MD5 — is not password storage regardless of how many times it is applied.
- Set work factors deliberately and revisit them. The cost parameter should be tuned to the hardware of the day and reviewed periodically. A configuration set once and left for a decade is progressively weaker every year.
- Migrate legacy hashes on next login. Rehash with the new scheme when a user authenticates successfully, and force a reset for accounts that never return. Waiting for a rewrite means the old scheme persists indefinitely.
- Make multi-factor authentication the primary defence. Assume the password database will eventually be exposed. MFA is what makes that exposure survivable, and it protects against reuse from every other service's breach as well.
- Screen new passwords against known breach corpora. Blocking passwords that appear in public breach datasets prevents the most common real-world compromise route. Current NIST guidance favours this over composition rules and forced rotation.
- Fix injection at the framework level. Parameterised queries as the default, enforced by code review and static analysis, rather than relying on individual developers to remember.
- Investigate the full scope before disclosing, and re-examine later. The LinkedIn figure was wrong by a factor of twenty-five. Determining what was actually accessed requires logs that were retained and a forensic capability that most organizations only build after an incident.
- Monitor for your own credentials appearing in dumps. Breach monitoring services allow an organization to discover an exposure that the breached party has not yet disclosed — or has understated.
What Finally Changed the Calculation
The incentive structure that made this breach consequence-free has been dismantled, though it took most of a decade. GDPR, enforceable from May 2018, introduced both mandatory breach notification within 72 hours and penalties scaled to global revenue — converting a reputational question into a financial one. Class action litigation became more viable as courts grew more willing to recognise harm from credential exposure. Cyber insurers began underwriting on the basis of specific controls, making MFA and credential hygiene a condition of cover rather than a recommendation. And security questionnaires in B2B procurement started asking about password storage specifically, which made the answer commercially relevant. The Gulf followed the same direction. The UAE's federal personal data protection framework and Saudi Arabia's PDPL both establish breach notification duties and regulatory oversight that did not exist in 2012, and sector regulators in financial services have added specific authentication requirements. An organization here that stores credentials the way LinkedIn did in 2012 now has a compliance problem as well as a security one.
The Part That Has Not Been Fixed
What remains true is the asymmetry that produced the 2016 surprise. Organizations still report breaches on the basis of incomplete forensics, still discover years later that more was taken than they believed, and still rely on users to absorb the consequences of credential reuse. Credential stuffing — taking usernames and passwords from one breach and trying them everywhere else — remains one of the most effective attack methods available, and it is powered entirely by the accumulated contents of breaches like this one. The 2012 LinkedIn data is still in circulation. It is still being tried against corporate logins today, fourteen years later, and it still occasionally works. That is the durable lesson. A password breach is not an event that concludes. It is a permanent addition to the attacker's toolkit, and the only control that reliably degrades its value is a second factor.
Common Questions
What happened in the 2012 LinkedIn breach?
Roughly 6.5 million unsalted SHA-1 password hashes were posted to a cracking forum in June 2012, with most cracked within days. In 2016, a much larger dataset from the same intrusion emerged, ultimately accounting for more than 164 million email addresses — revealing that the original disclosure had understated the breach dramatically.
Why was unsalted SHA-1 a problem?
Without a per-user salt, identical passwords produce identical hashes, allowing mass cracking with precomputed tables. SHA-1 is also fast by design, making each guess cheap. Purpose-built password hashing functions are deliberately slow and individually salted for exactly this reason.
How should passwords be stored today?
With a dedicated password hashing algorithm — Argon2id preferred, bcrypt or scrypt acceptable — using a unique salt per user and work factors tuned to current hardware, combined with multi-factor authentication and screening against known breach corpora.
Why do old breaches still matter?
Because credentials from historic breaches remain in circulation indefinitely and are used in credential stuffing attacks against unrelated services. Password reuse means a 2012 dump can still compromise a corporate account today unless a second authentication factor is in place.
Password Security Audit — Outpace reviews how your credentials are stored, where reuse exposes you, and what an old breach dump could still unlock today.