Old code can hide a flaw for 27 years, and whoever runs it carries the risk

Niels Provos, co-author of the bcrypt password hash, talked about two pieces of his 1990s work on GitHub's podcast. A bug he committed to OpenBSD in 1998 was found only recently. His hash, bcrypt, is 28 years old and still in use. A speaker on the show said the bug was never exploited in 27 years.

What was said

A host said Anthropic's Mythos model found a vulnerability in OpenBSD, an open-source operating system, that traced back to Provos's own commit. He located his November 1998 change in the public history. The transcript renders it as "TCP SAC and forward acknowledgements", though the spelling is uncertain.

Provos was struck by it. "I hadn't thought about this code in decades," he said. A speaker on the show said part of the thinking had been that code this old probably held no vulnerabilities. That is one recollection, not a measured view of how the industry treated old code.

The same speaker said anyone who knew of the flaw could bring machines down with a single packet, and that those machines are used in critical workflows. As general background, not a finding about this bug: network software reads data from strangers, and a packet built to break its assumptions can crash it.

bcrypt aged differently. Provos said computing power kept growing, so "Every year the passwords that you thought last year were perfectly fine were twice as easy to guess as before." With bcrypt, he said, you can raise the number of iterations, so every year you could tune it. Background: iterations are repeated rounds of work per guess. Raising the count makes each guess slower, so the hash can keep pace with faster hardware without a redesign.

Why it matters

Our reading: the two stories form a pair. bcrypt had a dial built in for growing hardware. The 1998 code had no such dial, and its flaw surfaced only recently. If such a flaw sits in software you run, the risk falls on you, not on whoever wrote it.

Provos said people who hunt for zero-day flaws, meaning flaws unknown to the vendor, can already do so with existing models. He said he planned, probably the following week, to open-source a tool that automates that search. If so, looking through old code gets cheaper. For buyers and managers, the useful questions are whether a patch exists and how the component gets updated.

The other side

One case does not make a trend. The claim of no exploitation comes from one speaker on a podcast, and a flaw nobody detected being used is not proof nobody used it. The excerpts give no count of affected machines, no patch status and no cost of a fix. So the price here is risk, not a measured loss.

Provos also said open code lets other people find vulnerabilities for you. The excerpts do not say whether openness helped here. He said he was thinking only a year or two ahead when he designed bcrypt, and the excerpts do not show that deployments retune it each year.