On Sunday morning around nine, a nimoca user got an email he did not recognise. Instead of clicking it, he called the company, and that call uncovered the breach.
I run AliasFleet, an email-alias service where every site gets its own address, so one leak cannot follow you around.
Two days later, nimoca's operator confirmed that its usage-history inquiry service had been hit by unauthorized access. Five hundred and twenty-one users' email addresses, card numbers and dates of birth had leaked. This one is small. It is still worth your attention, because of how it was found, and because of what the company had to say next.
nimoca is the transit IC card of Fukuoka and Kyushu, run by Nimoca Co., Ltd., a Nishi-Nippon Railroad group company. The card you tap at the gates is untouched; the company says cards work normally. The hit system is the usage-history inquiry service, a web service where registered users check their card usage history online. Only people who registered for that service are in the file, 521 of them, and since the evening of October 4 the service has been suspended while the company investigates. Online history checks are down until further notice. The gates keep working; the website does not.
A file with no names in it
Here is what was confirmed leaked:
| Leaked | Not leaked |
|---|---|
| nimoca card number | Name |
| Date of birth | Home address |
| Email address | Phone number |
The missing column is the interesting part. Most breach files are built for phishing because they pair a name with an email, which makes the fake message look personal. This file is a card number plus a date of birth plus an email. An odd combination. Not the one a scammer would design, but exactly the one a web service would store for login and lookup. That tells you the attacker reached whatever the service kept, not whatever they went shopping for.
Still, do not talk yourself out of caring about this file. The email address is the valuable item in it. It is the address that will receive every phishing message about this breach, the "your nimoca registration" scams, the account-recovery attempts against other services tied to it. And the card number plus the date of birth is the standard pair for identity checks on support calls. Whoever holds this file can plausibly claim to be you to the person behind a help desk. A date of birth, unlike a password, never rotates. You cannot change it, and you cannot take it back.
Two days from a phone call to a public notice
The timeline here is unusually fast, and the company deserves the credit before the criticism. Sunday, around 9am: the customer calls the call center about the strange email. That same evening, the usage-history service goes dark. Two days later, the public announcement names the service, the data types, and the count.
No weeks of silence. No vague first notice followed by a number weeks later.
Compared with the multi-week disclosure gaps that keep showing up in breach coverage, this is close to how it should work. The cause, though, is still missing. The announcement does not say how the attacker got into the service, and the investigation is ongoing. Two days is fast for a disclosure. As of the announcement, no misuse of the leaked data had been confirmed. It says nothing about how long the intruder was inside before a customer happened to notice something odd. That remains the open question, and the one that decides how bad this gets.
"It wasn't the attacker"
The strangest detail in the announcement is the one the company had to deny. Some users received emails, sent to their registered addresses, that contained part of their registered information. Your first thought on getting one of those would be that the attacker was doing reconnaissance. The company says it was not. The emails were sent automatically by the service itself.
Think about the position those 521 people are in. They learn their data leaked, then get an email with some of their own data in it, and the company tells them the email was not from the attacker. Who do you trust, the breach notice or the feeling in your gut?
This is the failure mode that matters beyond the numbers. Security advice says "do not click suspicious links," but during a breach, the company's own messages look exactly like the threat. A company that has to spend its disclosure explaining that its own emails were safe has a communications problem. Not just a security problem.
Users cannot be expected to tell the attacker's mail from the company's mail when both arrive in the same afternoon, both containing their own details.
What to do if you are one of the 521
- Verify through channels you open yourself. Never click a link in a message about this breach, no matter who it claims to be. Type the company's address yourself or use the call center number you already have.
- Treat the card-number-and-birth-date pair as compromised identity evidence. If any service asks you to confirm who you are with that combination, use a different verification method for a while.
- Expect phishing that references nimoca by name. The file has real email addresses and real card context, so the fakes will not be generic spam. They will mention the usage-history service.
- Turn on multifactor authentication on your email account. Your inbox is the recovery address for everything else you own, and it is in this file.
- Check Have I Been Pwned once the breach is listed. One address, one search, and you know which of your accounts sit in the file.
The full ordered version of the standard response lives in our breach-response guide.
The customer who called is the whole lesson
Step back from the file for a moment. The breach was not found by a monitoring tool. It was found by one person who got an email he did not recognise and, instead of ignoring it, picked up the phone. That single call turned into a confirmed breach disclosure two days later.
Now consider the reverse. He only knew the email was suspicious because it arrived at an address he expected nimoca mail on, about a service he used. Imagine the address he gave nimoca was used only for nimoca. Any message about the breach arriving anywhere else would be instantly wrong, and a strange email on the nimoca address would be the whole signal, no guesswork needed. That is what a per-service address buys you: every message that arrives on it names the company that lost it, which is the leak-tracing mechanism doing exactly what it is for.
If you have never used one: this is what an email alias is. The set-up guide takes about two minutes.
What the announcement left out
The announcement does not say whether the leaked data was actually taken or only viewed, and that decides the shape of what comes next. It also does not say whether reports were filed with the regulator or police. The company's own notice could not be found in search results during this run, so everything above traces to TNC Television Nishinippon's reporting; if the Japanese original differs on any detail, the original wins.
Watch for phishing posing as nimoca. And if you get an email you do not recognise, do what the Sunday morning caller did: close it, and pick up the phone.
Top comments (0)