Security Spending Is Up. The Login Screen Hasn't Changed.

Nine Months After Coupang, the List Keeps Growing

On September 3, a joint public-private investigation team under Korea’s Ministry of Science and ICT released its findings on the Tving (a Korean streaming platform) breach. Roughly 39,540,000 user accounts and 361 technical assets, including source code, had been exfiltrated. A day later, on September 4, an abnormal access to the consultation-history API at Gangnam Unni, a cosmetic-medicine platform, exposed the information of 220,000 people. In August, Jeongsang Language School (a Korean English-education academy) reported a leak of 260,000 records, and Day1 Company, an adult-education platform, also issued a breach notice.

The Coupang leak became public knowledge in late November of last year. Nine-plus months later, the list still hasn’t gotten shorter. According to Korea’s Internet & Security Agency (KISA), 1,236 breach incidents were reported in the first half of this year — up 19.5% from the same period last year. Ransomware infection reports rose 76.8%, and distributed denial-of-service attacks rose 56.7%.

And it’s not as if companies stopped spending on security during this stretch. KISA’s information-security disclosures show that Coupang spent ₩134,900,000,000 (~$100M) on information security in 2025 — up 51.6% from the previous year, and the second-highest figure domestically, trailing only Samsung Electronics at ₩412,100,000,000. And starting September 11, Korea’s revised Personal Information Protection Act took effect, allowing regulators to fine companies responsible for large-scale leaks up to 10% of total revenue.

Budgets went up. The law got tougher. The list didn’t shrink. This piece looks at what’s missing in between. The answer isn’t a lack of technology. The tools to protect accounts have existed for a long time, and Naver and Kakao already support them. What’s actually happening is that, somewhere, in some meeting, every single day, someone decides not to turn them on.

---

Tving’s Breach Included the Encryption Keys

The Tving incident began at 6:01 p.m. on May 30. The company detected the breach after noticing an anomaly — CPU usage on a database server spiking to 100%. It confirmed the leak the next day, filed a report on June 1, and notified users on June 3.

The part of the investigation worth dwelling on isn’t the scale — it’s the encryption status. Passwords were one-way encrypted and couldn’t be decrypted. But for phone numbers and email addresses, the encrypted data went out together with the encryption key that unlocks it. The investigation team judged this to be effectively equivalent to a plaintext leak. It’s the equivalent of stealing the entire safe and taking the key along with it. The leaked fields — 20 categories, 70 types in total — included names, dates of birth, phone numbers, email addresses, and Connecting Information (CI)¹.

One distinction matters when reading the headline number. 39,540,000 is the account count, not the number of people. A KBS report put the actual scale of the leak at 19,000,000 people — a figure that appears to filter out cases where one person created multiple accounts or was counted more than once. The exact scope by data category will be separately confirmed by Korea’s Personal Information Protection Commission.

What Tving did between June 10 and July 2 says a lot about the nature of this incident. It locked out and forcibly logged off every account registered under a CJ ONE ID. The move was meant to block attempts to use ID-password combinations leaked from Tving to log into other CJ services. This is known as credential stuffing².

The fix has existed for a long time

Credential stuffing is the most common route to secondary damage in Korea. Last January’s breach at GS Retail (a major South Korean retail conglomerate), which exposed information on 90,000 people, worked the same way: IDs and passwords collected from various sources, plugged in at random. A password leaked from one place ends up opening ten other doors.

The tools to stop this have been around for a long time. Two-factor authentication requires one more thing besides a password — a one-time code or device verification. Even if someone knows your password, they can’t get past the second gate, so credential stuffing simply doesn’t work. Going a step further, there’s the passkey³. It removes passwords entirely and logs you in using a private key stored on your device plus fingerprint or face recognition. There’s no password sitting on a server to steal, so even a leak is useless. Google, Apple, and Microsoft support it, and so do Naver and Kakao, Korea’s two largest internet platform companies.

So the problem isn’t a lack of tools — it’s that the tools that already exist aren’t turned on by default. At most Korean services, two-factor authentication is an optional item buried inside a settings menu. The default on the login screen is still a single password.

Why isn’t it turned on? It’s not about budget. Adding one more authentication step at login lowers signup conversion and login success rates. And that number is directly tied to somebody’s quarterly target. That’s why, in practice, security implementation keeps getting pushed back for reasons like “it’ll hurt user numbers” or “it’ll hurt the flow.” It’s not a legitimate excuse — but it’s the most commonly used one anyway.

There’s something worth checking here: has that premise ever actually been verified? Research on passkeys says the opposite, in fact. The claim is that shortening the checkout process reduces cart abandonment, and that it simultaneously cuts the cost of sending one-time passwords and handling password-reset inquiries. But this kind of research is mostly conducted on companies that have already adopted passkeys, so failure cases are left out. It’s a stretch to conclude that turning it on increases revenue.

So I went looking for accounts from actual users. What came up wasn’t complaints about conversion rates at all.

There’s an Unlocked Back Door Beside the Locked Front Door

On September 15, a post titled “I don’t like passkeys” went up on Hacker News and drew 73 comments. Even in a crowd of developers, there was plenty of pushback.

The complaints break down into a few strands. The most common one: lose your device, and you’re locked out of your account. There’s no universal way to register the same account’s key across multiple devices, so switching devices or operating systems means starting from scratch every time. Some people store their keys in a third-party password manager, only to find the site doesn’t recognize it properly and nags them to create a new one every time they log in. Others say they tapped a confirmation button a few times without realizing it registered a passkey, then got locked out on a different computer later. Ask where the key is actually stored, and the answer is “it depends” — so users end up using the system without even knowing what they stand to lose.

There’s a clear counter-argument too. Plenty of people say using a manager like 1Password or Proton makes moving between devices seamless, and that in the Apple ecosystem there was essentially nothing to configure. Their view: this isn’t a flaw in the concept, it’s a flaw in how each platform implemented it.

But the sharpest point in this whole debate is a different one. It’s the answer to the question: what happens when you lose your device? Click “I lost my device,” and a reset link arrives by email or text. Which means: you can install the latest lock on the front door, but the back door is still running the old one. An attacker doesn’t bother knocking on the locked door — they just walk in through the open one.

In Korea, this point lands even harder. Account recovery for domestic services almost always converges on mobile phone identity verification. And the information that identity verification leans on is name, date of birth, phone number, and yeonge-jeongbo (linkage information tying a phone number to a verified real-name identity). The 20 fields, 70 data types leaked from Tving — a Korean streaming service — are exactly that list. The phone numbers went out together with their encryption keys.

So turning on passkeys and fixing the recovery path have to happen together. Changing only the front door doesn’t eliminate the cost of an attack — it just relocates it to the back door. Most of the information leaked in Korea over the past few years wasn’t the key to the front door. It was the key to the back door.

Which brings us back to the earlier discussion. The objection that comes up in actual planning meetings is signup conversion rate. But the problem that actually exists is account recovery and device migration. These are two different problems, and they call for different solutions. When you push off the real problem for a fake reason, you lose the chance to design a solution for it at all.

The Fine Hasn’t Flipped the Math Yet

For a decision to keep deferring security to hold, the cost of deferring has to stay affordable. So far, it has been.

On June 11, the Personal Information Protection Commission (PIPC) fined Coupang ₩624,681,000,000 (~$451 million) and imposed an administrative fine of ₩16,800,000 (~$12,100). It’s the largest penalty on record, far surpassing the previous high of ₩134,791,000,000 (~$97.4 million) from SK Telecom’s SIM card breach. The scale of the leak was 37.55 million people — 33.22 million members plus at least 4.33 million non-members. The PIPC cited neglected authentication systems and key management, along with a failure to detect anomalous activity for more than six months, as aggravating factors.

But in the same ruling, the PIPC noted that Coupang’s annual revenue exceeds ₩30 trillion (~$21.7 billion). The largest fine in history amounts to just over 2% of revenue. SK Telecom, pointing to the ₩1.2 trillion (~$867 million) it spent on compensation and remedial measures, filed a lawsuit in January to have its fine overturned.

This is exactly why a joke circulates in online communities that Koreans’ personal data is basically already a public good, or that everyone should just get a full reset. The joke’s logic is precise. When leaks keep repeating, the marginal cost of adding one more incident to data that’s already out there starts to feel like zero. That feeling isn’t confined to users. The people calculating the cost of an incident come to share the same feeling, and that calculation gets baked into the default settings of the login screen.

The revised law that took effect on September 11 is an attempt to disrupt this math. For intentional or grossly negligent violations that repeat within three years, or that cause large-scale harm affecting 10 million or more people, regulators can now levy fines of up to 10% of total revenue. The previous ceiling was 3%. The aggravation multiplier for repeat violations was also raised, up to a maximum of 80%.

A countervailing mechanism arrived alongside it. Companies that had already invested in security before an incident can get their base fine⁴ reduced by up to 40%. The PIPC also released a companion “Fine Reduction Guidelines for Security Investment” laying out the evaluation criteria. There are three categories. One is the scale and ratio of investment in budget, personnel, equipment, and systems, along with its continuity and rate of growth. Two is the operational maturity of the protection framework, including oversight by the CEO and the Chief Privacy Officer (CPO). Three is additional safeguards that go beyond what the law requires. No reduction is granted for intentional or grossly negligent violations.

Here’s something worth flagging. Of the three categories, the first two look at how much was spent and what was put in place. Only the third category actually counts things like login-screen defaults or account-recovery pathways. Increase the security budget, and the first two boxes get checked — as Coupang did when it raised spending by 51.6%. But the decision that actually stops credential stuffing lives in the third box. It’s obvious which box is easier to fill.

Let me lay out the remaining changes. Even if a leak isn’t confirmed, companies must notify authorities within 72 hours of becoming aware if a leak is highly likely. Data corrupted by ransomware is also subject to notification requirements. Companies with annual revenue of ₩180 billion (~$130 million) or more that process the personal data of 1 million or more people must now get board approval and report to the PIPC whenever they appoint or replace a CPO. Under the supplementary provisions, none of this applies retroactively — so it doesn’t touch the Coupang or SK Telecom cases. Mandatory ISMS-P certification⁵ for major companies takes effect next July, after a preparation period.

The cost of attack has already collapsed

While the defensive baseline stays put, the cost structure on the offensive side has shifted.

That’s the crux of a security software report JPMorgan’s North America equity research team put out on September 15. The report tracks the average time from vulnerability disclosure to actual exploitation: 63 days in 2018, 32 days in 2021, 5 days in 2023. And by 2025, it estimates, that number has gone negative — meaning attacks now precede patches. Other sources confirm the direction. VulnCheck, a vulnerability intelligence firm, found that 32.1% of vulnerabilities exploited in 2025 were weaponized on or before the day they were disclosed.

The cost side is even more direct. Per the report, scanning an entire operating system for security flaws now costs under $50, and building an attack capable of fully taking over a computer takes half a day and less than $1,000. The same-caliber attack used to trade on the black market for $500,000 to $2 million — a 500x to 1,000x drop in price.

There’s a real-world case to match. In September 2025, a group identified as a Chinese state-backed actor manipulated Claude Code to target roughly 30 institutions. According to Anthropic’s investigation, the model independently carried out 80–90% of the operation — from reconnaissance through vulnerability discovery, credential theft, and data exfiltration — with humans stepping in at only four or five points per intrusion. Actual data exfiltration succeeded at 4 of the 30 targets.

Once the per-attack cost falls this far, services that were too small to be worth targeting before become targets too. In an environment like this, it’s not strange at all that a 220,000-user platform’s consultation-history API gets hammered on two consecutive days through different attack paths.

Oswarld’s Lens

What keeps nagging at me as I look at this list is that the importance of security never actually gets through. It’s not that people don’t know. Ask anyone and they’ll tell you exactly why it matters. But nobody implements it. There’s a gap between recognizing the problem and acting on it, and that gap sits outside the security organization, not inside it.

When the security team proposes turning on two-factor authentication, the pushback doesn’t come from hackers. It comes from the team responsible for sign-up conversion and active user numbers. And that team’s metrics get checked this quarter, while the losses from not turning it on show up years later under a different name. Since these aren’t two comparable numbers, the argument always ends the same way. You don’t lose this fight in the budget meeting — you lose it in the product meeting.

So here are three proposals. First, put login conversion rate and account-takeover attempt counts on the same screen. Right now, two different teams look at these two numbers in two different meetings. Until you put them side by side, nobody calculates which one actually costs more.

Second, don’t design authentication as all-or-nothing. Instead of requiring two-factor authentication on every login, there’s adaptive authentication⁶ — additional verification kicks in only when risk signals appear, like an unfamiliar device or an abnormal access pattern. This shrinks the population subject to the drop-off argument from all users to a subset. It’s a way of shrinking the size of the counterargument itself.

Third, bundle the work of redesigning the front door together with the work of auditing recovery paths into a single project. You need to first check what information the recovery screen currently asks for, and whether that information already appears in some leaked list somewhere. This isn’t a budget item — it’s a half-day audit.

There’s one more thing I’m watching. Starting September 11th, companies above a certain size will need board approval to replace their CPO. The fact that a security personnel decision becomes a board agenda item also means that, for the first time, security debates will end up in board meeting minutes. It creates a paper trail for recording who postponed the login defaults, and why. Whether this actually works in practice is something we’ll only know once the first case comes along.

Closing

Reader, this revision doesn’t just change the penalty cap. Security investment has, for the first time, become a line item that returns as a dollar figure. But what it returns on is mostly how much you spent. What you actually switched on barely makes it into the third column.

So over the next few years, companies will split into two kinds. Ones that ramp up spending to hit the mitigation requirements, and ones that fix the login screen and the recovery screen together. The numbers on the disclosure will look similar. The difference shows up in whether your name ends up on the list below.

---

💬 Pick one service you actually use and walk through its account recovery screen. What does it ask you? Is any of that information already sitting in a recent breach dump?

📨 If you have a colleague who designs login flows or owns sign-up conversion, send them this piece. It’s more their read than the security team’s.

References & Further Reading

Primary sources

• Ministry of Science and ICT (MSIT) and Korea Internet & Security Agency (KISA), “Findings of the Joint Public-Private Investigation into the Tving Breach,” September 3, 2026. ··· This is where the finding that 39.54 million accounts, 361 technical assets, and encryption keys were all compromised together comes from. I’d recommend looking directly at the list of the 20 categories and 70 types of leaked items.
• Personal Information Protection Commission (PIPC), “Sanctions Resolution on the Coupang Personal Data Leak and Breach Incident,” June 11, 2026. ··· It lays out what the Commission treated as a severity factor when calculating the fine. The key point: the breach went undetected for more than 6 months.
• PIPC, “Briefing on the Enforcement of the Amended Personal Information Protection Act and Its Enforcement Decree,” September 10, 2026. ··· It confirms the requirements for applying the 10% of revenue special provision, along with the three items for investment-based mitigation. I’d recommend reading it alongside the accompanying “Guide to the Fine Mitigation System for Investment,” released at the same time.
• Ethan Hawksley, “I don’t like passkeys” and the Hacker News discussion, September 15, 2026. ··· What today’s piece quotes isn’t the original post itself but the 73 comments beneath it. Looking at where opinions split for and against shows what needs to be resolved first in the adoption debate.
• KISA, “Trends in Domestic Cyber Threats, First Half of 2026,” July 30, 2026. ··· It breaks down 1,236 breach incidents by type. The section on the rise in ransomware and distributed denial-of-service (DDoS) attacks is especially useful.
• KISA Information Security Disclosure Portal (https://isds.kisa.or.kr) ··· You can look up each company’s information security investment and headcount directly. The figures cited in the piece — ₩134.9 billion (~$97.3M) for Coupang and ₩412.1 billion (~$297.1M) for Samsung Electronics — come from here.
• Anthropic, “Disrupting the First Reported AI-Orchestrated Cyber Espionage Campaign,” November 2025. ··· This is the source for the claim that 80–90% of the operation was carried out by the model alone. It even specifies how many points required human intervention.

Background

• VulnCheck, “2025 Known Exploited Vulnerabilities Report” ··· This is independent support for the claim that time-to-exploitation has dropped into negative numbers. Its methodology differs from the JPMorgan report, so the figures are slightly different too.
• SK Shieldus, “Logging In Without a Password? Passkey Security and Precautions for Enterprise Adoption,” March 2026. ··· This isn’t just a piece concluding that companies should switch on passkeys — it lays out the real adoption barriers that arise in legacy environments.

---

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

📝 Glossary

각주

1. Connecting Information (CI): An 88-digit value created to identify the same person across different services in place of a resident registration number. Regardless of which service is used, the same person always produces the same value. It serves as the reference point for identity verification procedures, so if this value leaks alongside a name, date of birth, and mobile phone number, everything needed to impersonate that person is in place. ↩

2. Credential Stuffing: An attack that automatically tries username-and-password combinations leaked from one service against other services. It preys on the habit of reusing the same password across multiple sites. It requires no hacking skill at all — just a list and an automation tool — which is why it’s typically the first attack to hit right after a leak. ↩

3. Passkeys: A login method that uses a private key stored on the device together with fingerprint or facial recognition, instead of a password. Only a verification public key is stored on the server rather than a password, so even if the server is breached, no information usable for logging in is exposed. ↩

4. Base Fine Amount: Not the final fine, but the starting point of the calculation. After weighing the nature of the violation and the scale of the harm to set a base amount, the final figure emerges after investment-based mitigation and first- and second-round adjustments. The 40% mitigation is applied to this base amount. ↩

5. ISMS-P Certification: A domestic Korean certification that reviews information security and personal data protection management systems together. It’s a system that checks whether documentation and procedures are in place, so holding the certification doesn’t mean actual attacks were successfully prevented. ↩

6. Step-Up Authentication: Instead of requiring extra authentication on every single login, this method demands an additional step only when a risk signal is detected — such as an unfamiliar device or an unusual access location. Most users keep the same experience as before. ↩