Incidents & Vulnerabilities
Takufile-bin Data Leak (2019) — Why Plaintext Password Storage Is Fatal, and the Hashing Defense
In January 2019, Japan's file-transfer service Takufile-bin (Ogis-Research Institute) was breached and ~4.8 million records leaked. The decisive failure: the leaked login passwords were stored unencrypted — in plaintext. Defend by storing passwords as a one-way salted hash (bcrypt/Argon2id) and keeping no plaintext.
We read real, public breaches not as replayed news but as "how do you defend against this?" This article is based on the public record (company statements, reputable reporting). Sources are listed at the end, and no attack how-to is included.
- Target
- Users of the file-transfer service "Takufile-bin" (operator: Ogis-Research Institute)
- Detected
- 22–25 January 2019 (a suspicious file spotted → service halted → disclosed)
- Pattern
- Unauthorized access via a server vulnerability → theft of customer data (login passwords stored in plaintext)
- Scale
- ~4.8 million records (names, emails, login passwords, dates of birth, gender; including withdrawn customers)
- Root cause
- Passwords stored in plaintext (reversible form) + a server vulnerability + retaining unnecessary data, including withdrawn users
- Real fix
- One-way hash + salt (bcrypt/Argon2id); hold no data you don't need / minimize retention; vulnerability management; prepare for reuse (2FA)
What happened (in plain terms)
A service is entrusted with users' passwords. The question is how it keeps them. Store a password in plaintext (readable as-is), or with only reversible encryption, and the moment the data leaks its contents are directly usable.
At Takufile-bin, a server vulnerability was exploited for unauthorized access and customer data leaked. A follow-up report then disclosed that the leaked login passwords had not been encrypted — they were plaintext. Because many people reuse the same password across services, a plaintext leak lets an attacker try it elsewhere for account takeover. More than the intrusion itself, plaintext storage is what widened the damage.
'Encryption' and 'hashing' are not the same
A common misconception in password storage is that encryption makes it safe. Encryption is reversible with a key, so if the key leaks too it's no better than plaintext. The correct approach is a one-way hash that can't be reversed, plus a per-user salt, using a deliberately slow algorithm (bcrypt / Argon2id). At login you hash the input the same way and compare — so there is no need to store the plaintext at all.
The attack chain is also a defense map
This was a chain with a place to stop it at every step. Read it as where it could have been broken, not as a how-to.
1. Unauthorized access via a server vulnerability
A neglected known weakness becomes the way in.
Stop: vulnerability management; patch discipline; minimize the attack surface
2. Customer data and login passwords taken
A large store of data, including withdrawn customers, was held.
Stop: don't hold data you don't need; minimize retention
3. Passwords in plaintext = immediately usable
Not encrypted, so usable the moment they leaked.
Stop: one-way hash + salt (bcrypt/Argon2id) = not directly usable if leaked
4. Secondary damage via reuse (account takeover)
Other services sharing the same password get targeted.
Stop: stop reusing passwords; 2FA; prompt forced reset on a leak
Published timeline
2019-01-22
A file the company didn't recognize is found on a server (a sign of unauthorized access).2019-01-23
The service is halted as a precaution.2019-01-25
Unauthorized access and the data leak are disclosed (~4.8 million records, including withdrawn users).2019-01-30
A follow-up report discloses that the leaked login passwords had not been encrypted (plaintext).2019-03
Detailed findings from an external security firm are reported; the service stays suspended.2020-01-14
Discontinuation is announced (given the cost/time of a safe rebuild); the service ends that year.
The root cause wasn't only "being breached"
Writing this off as "they got hacked" misses the point. Intrusion can happen; what matters is whether storage minimizes damage when data leaks.
The setup that failed
- Login passwords stored in plaintext (usable the moment they leak)
- A large store of data, including withdrawn users, kept around
- A server vulnerability became the way in
- Hard to stop account takeover on reuse sites after the leak
The setup that holds
- Passwords stored as a one-way hash + salt (bcrypt/Argon2id)
- Hold no data you don't need; minimize retention (delete after withdrawal)
- Vulnerability management / patch discipline closes the way in
- 2FA and prompt forced reset on a leak limit secondary damage
The after-the-fact bill dwarfs the up-front design investment
Takufile-bin stayed suspended and was ultimately shut down entirely (given the cost and time of a safe rebuild). Hashing passwords correctly is cheap, while the cost of lost trust, withdrawal and secondary damage from plaintext storage is far greater. Design how you store passwords correctly when you build it, not after.
How you defend against this
If you're entrusted with even one user's password, this is yours. In priority order:
Store passwords as a one-way salted hash
Don't store plaintext or 'reversible encryption'. Use a one-way hash with a per-user salt, via a deliberately slow algorithm like bcrypt or Argon2id. For the full how-to, see how to store passwords safely.
Hold no data you don't need
Collect the minimum of fields, and delete data once a user withdraws or it's no longer needed. Data you don't hold can't leak. Don't hoard withdrawn users' records.
Close the way in — manage vulnerabilities
Patch server and library vulnerabilities and minimize the exposed attack surface. Assume intrusion is possible, and reduce the ways in.
Limit damage even if it leaks (2FA, reuse defense)
Offer two-factor authentication, and force a prompt reset on a leak. Nudge users away from reuse. Together with hashing, aim for a state where a leak isn't directly usable.
Where this overlaps with how this site is built
At its core, this incident kept the most important secret — the password — in a form usable as-is if leaked (plaintext). That is the mirror image of this site's own principles — handle secrets in an irreversible form, hold nothing you don't need, and shrink the blast radius. "We encrypted it, so it's safe" is a dangerous assumption; passwords belong in a one-way hash + salt. "Keep no plaintext, hold no needless data, make a leak unusable" is a defense anyone can implement at any scale.
Sources (public record)
The facts here are based on the following public information. No attack how-to is included — only the defensive lessons.
- Ogis-Research Institute official statements ("On the unauthorized access to the Takufile-bin service" / apology and report, 2019–2020) — ogis-ri.co.jp
- Contemporary reporting (service suspension, detailed findings, and discontinuation, 2019–2020), based on the primary disclosures
Read next
- Practice: How to store passwords safely (hashing and salt)
- Glossary: What password hashing is / What a salt is
- Glossary: Two-factor authentication (2FA) (so a leak isn't directly usable) · Practice: Security baseline checklist
FAQ
QWhat was the most serious problem in the Takufile-bin incident?
That the leaked login passwords were stored unencrypted — in plaintext. The trigger was unauthorized access via a server vulnerability, but because passwords were plaintext, they were immediately usable the moment they leaked. Had passwords been stored as a one-way hash (with a salt), a leak would not have exposed usable passwords, and the damage would have been far smaller.
QIs 'encrypting' passwords safe enough?
'Encryption' and 'hashing' are different. Encryption is reversible with a key, so if the key leaks too it's no better than plaintext. The right approach is a one-way <strong>hash</strong> that can't be reversed, plus a per-user <strong>salt</strong>, using a deliberately slow algorithm like bcrypt or Argon2id. At login you hash the input the same way and compare — so there is no need to store the plaintext at all.
QAs an individual user, what can I do?
Yes: (1) never reuse a password across services (so even a plaintext leak can't lead to account takeover elsewhere); (2) use a password manager for long, random values; (3) turn on two-factor authentication or a passkey wherever offered. Even if the operator stores passwords poorly, not reusing them breaks the chain of secondary damage.