What 'hashed passwords' in a breach notice really means

What does a company mean by "hashed"?

It means the password went through a one-way function before it was stored, and only the output was kept. A hash function takes any input and produces a fixed-length string of characters. The same input always gives the same output, but there is no way to run the function backwards. When you sign in, the service hashes what you typed and compares it with the stored value. If the two match, you are in. The service never needs the password itself, so a well-run one never keeps it.

That design has one weakness, and it is the whole story. Because the same input always gives the same output, an attacker who holds the stored hashes can take a list of likely passwords, hash each one and look for matches. This is not reversing the hash. It is guessing, at whatever speed the hardware allows. A common password falls in the first second. A long, random one does not fall at all.

Two refinements make guessing harder, and a good notice mentions both. A salt is a random string added to each password before hashing, so that two users with the same password get different hashes and the attacker has to work on each account separately. The US standards body NIST requires a salt of at least 32 bits in its guidance for password verifiers. A pepper is a secret key kept outside the database, so that a stolen database alone is not enough to check guesses against. NIST recommends storing it in a hardware security module or similar, and the OWASP Password Storage Cheat Sheet describes the same idea as defence in depth.

Why does the algorithm matter more than the word?

Because the algorithm sets the guessing speed, and the difference between a bad choice and a good one is not a few times but tens of millions of times. General-purpose hash functions such as MD5, SHA-1 and SHA-256 were built to be fast. That is a virtue for checking file integrity and a disaster for password storage. Purpose-built password functions such as bcrypt, scrypt, Argon2 and PBKDF2 were built to be slow on purpose, and to let the operator make them slower over time.

The published hashcat benchmark for an NVIDIA RTX 5090, a graphics card anyone can buy, puts the numbers side by side. The same card computes about 220 billion MD5 hashes a second, 70 billion SHA-1, 28 billion SHA-256, and 304,800 bcrypt hashes a second at bcrypt's lowest cost setting of 5. Each step up in bcrypt's cost setting halves the speed, so at cost 10, which OWASP gives as the minimum for bcrypt today, the same card manages roughly 9,500 guesses a second. A user on the hashcat forum measured about 9,900 against a real cost-10 hash. Against MD5 that is more than twenty million times slower.

Table scrolls sideways. Figures from the hashcat 6.2.6 benchmark; the cost-10 bcrypt figure is derived from the cost-5 result.

Two real cases show what that gap means in practice. LinkedIn stored its passwords as SHA-1 without a salt. When the 2012 breach turned out in May 2016 to cover 117 million accounts rather than the 6.5 million first reported, 90 per cent of the passwords were cracked within 72 hours, and just 50 common passwords accounted for more than 2.2 million of the hashes. The Internet Archive breach of September 2024, which exposed 31.1 million accounts, used bcrypt. The hashes still leaked, but every guess against them costs the attacker millions of times more computing time, and a long random password in that set is out of reach at those speeds.

Why does a strong hash still not make you safe?

Because a slow algorithm only protects a password that needs many guesses. It does nothing for one that is on the attacker's list already. Ten thousand guesses a second is slow by cracking standards, but it is still 864 million guesses a day per card, and the first few million guesses are the ones that matter: dictionary words, names, years, keyboard patterns, and every password that has appeared in a previous breach. A December 2025 survey of 1,500 US adults for PasswordManager.com found that 65 per cent use predictable patterns or personal information, and that only 16 per cent use a unique password for every account.

That second number is the real problem. If the password you used at the breached service is also your email password, the algorithm at the breached service is irrelevant. The attacker only needs the plain password once, from anywhere, and the reused copies fall with it. GoDaddy's 2025 consumer survey put reuse at 61 per cent of US consumers. Credential stuffing, where a leaked email and password pair is tried against hundreds of other sites automatically, exists because of exactly this habit.

And the password is rarely the only thing taken. The Gyazo dump also contained names, email addresses, login session IDs, device IDs, tokens for linked X and Google accounts, subscription status, and for images uploaded before 2019 the upload IP address and any location data embedded in the picture. A session ID is what keeps you signed in after the password check has passed. A stolen session survives a password change unless the service cancels it on its own servers, which is why Helpfeel says it reviewed its authentication data for invalidation alongside asking for new passwords.

So do you need to change the password?

Yes. Change it at the breached service, and change it at every other service where you used the same or a similar one. That is the advice of the UK's National Cyber Security Centre, whose guidance for individuals says that if any of your other accounts use the same password, you should change them as well. It is also what NIST tells service operators: verifiers shall not force periodic password changes, but shall force a change if there is evidence the password has been compromised. A leaked hash is that evidence.

If you want to know whether the old password was already on the attackers' lists, Have I Been Pwned runs a free check called Pwned Passwords. Your browser hashes the password locally and sends only the first five characters of that hash to the service, which replies with every matching suffix it knows. The comparison happens on your own device, so the password never leaves it. The NCSC's breach guidance points to the same site. A match does not mean your account was breached, only that somebody, somewhere, chose that password and lost it, which is enough for it to be in every cracking list from now on.

When you pick the replacement, the algorithm at the other end is out of your hands. Length is not. A long, random password from a password manager is what makes a slow hash worth having, because it pushes the number of guesses needed from millions into a range no card will reach. One limit worth knowing: bcrypt only reads the first 72 bytes of a password, so extra length beyond that adds nothing on services that use it.

What can you tell from the wording of a notice?

More than the companies intend, usually by what they leave out. Here is how the common phrases translate.

"Hashed passwords" with no algorithm named. This is the most common wording and it is the Gyazo case. It tells you the company did not store plain text, and nothing more. The algorithm could be anything from unsalted MD5 to Argon2. Plex's notice of 9 September 2025 said "securely hashed" and, according to Help Net Security's report, did not name the algorithm either, though Plex asked users to reset anyway. Treat an unnamed algorithm as a fast one.

"Hashed and salted" with an algorithm named. This is what a careful operator writes, because they know the question you are asking. bcrypt, scrypt, Argon2 or PBKDF2 with a stated work factor means the guessing is expensive. It still does not save a weak or reused password.

"Encrypted passwords." Encryption is reversible by design, which is exactly what a password store should not be. Sometimes the writer means hashed and picked the wrong word. Sometimes they mean it. Either way, assume the worst.

"Out of an abundance of caution, we are requiring a password reset." This is the company doing what NIST says it should. It tells you nothing about how strong the hashes were. The reset covers their account. The reused copies are still yours to deal with.

What does the notice not tell you?

It does not tell you what the rest of the data will be used for, and that part outlasts any password change. A name, an email address and the fact that you had an account at a particular service is enough to write you a message that looks like it comes from that service. The NCSC warns specifically about official-sounding messages about resetting passwords or receiving compensation that arrive in the weeks after a breach. If you need to change a password, go to the site by typing its address, not by following a link in an email that mentions the breach.

It also does not always tell you how long the attacker has had the hashes before you heard about it. Gyazo's window was short: the attacker got in on the evening of 11 September, the route was closed in the early hours of the next day, and the notice went out on the 16th. LinkedIn's full set did not surface until four years after the breach. A slow algorithm buys time, and time is only useful if you use it. The moment you learn a hash of yours is out is the moment to spend it.

A last word on the email address itself. Once it is in a breach dump it gets combined with other dumps, and no browser setting reaches that copy. The browser signal that tells sites not to sell your data speaks to the site you are visiting, not to whoever downloaded the dump. That is one more reason the password attached to that address should not open anything else.

Sources

1. Official notice on the unauthorised access to Gyazo, Helpfeel Inc., 16 September 2026, for the timeline, the 23.62 million user records and the data items listed
2. Hackers exploit Gyazo server flaw to steal 23.6 million user records, Help Net Security, 21 September 2026
3. Gyazo breach exposes 23.62 million user records and 490 million image metadata records, The Hacker News, September 2026, for the session IDs, SSO tokens and the review of authentication data
4. Password Storage Cheat Sheet, OWASP, for the recommended algorithms, the bcrypt work factor of 10, the 72-byte limit, salting and peppering
5. NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management, section 3.1.1.2 on password verifiers, for the 32-bit salt, the separately stored secret key, and forced changes on evidence of compromise
6. hashcat v6.2.6-851 benchmark on the NVIDIA GeForce RTX 5090, for the MD5, SHA-1, SHA-256, bcrypt, scrypt and PBKDF2 figures
7. RTX 5090 Bcrypt speeds, hashcat forum, for the measured cost-10 speed and the halving per cost step
8. As scope of 2012 breach expands, LinkedIn to again reset passwords for some users, Krebs on Security, 18 May 2016, for unsalted SHA-1, the 117 million figure and the 50 common passwords
9. 117 million LinkedIn emails and passwords from a 2012 hack just got posted online, TechCrunch, 18 May 2016, for the 90 per cent cracked within 72 hours
10. Internet Archive data breach, Have I Been Pwned, for the 31.1 million accounts and bcrypt hashes
11. Plex tells users to change passwords due to data breach, Help Net Security, 9 September 2025
12. Data breach guidance for individuals, National Cyber Security Centre, for changing reused passwords, the phishing warning and the pointer to Have I Been Pwned
13. Pwned Passwords, Have I Been Pwned, for the free check and the five-character hash prefix
14. PasswordManager.com survey finds 2 in 3 Americans still use predictable password patterns in 2026, PasswordManager.com via Yahoo Finance, survey of 1,500 US adults by Pollfish, December 2025, for the 65 and 16 per cent figures
15. 8 password reuse statistics for 2026, Enzoic, citing the GoDaddy 2025 Consumer Pulse survey for the 61 per cent figure