Good Smile Company Official Shop Breach (Full Card Data May Have Leaked for 2,800 People, Partial Card Data on 402,466 Cards, Up to 202 Orders Possibly Viewed): What Each Group Should Do

Group B may have had the cardholder name, full 16-digit card number, expiry date and security code captured. The company asks people to check statements and contact the issuer printed on the back of the card about any charge they do not recognize. It also advises considering reissue.

This site also recommends that you ask your issuer about changing the number even if no fraudulent charge has appeared. The security code may have leaked, and that combination stays usable until the number changes. You apply for reissue yourself. The company says it has asked issuers not to charge reissue fees to users; as of November 3, no outcome from the issuers has been announced.

Group B includes:

• People who ordered by card in the period (384 people)
• People who changed the card used for payment after a pre-order in the period (185 people)
• People who tried to pay but did not complete it
• People who logged in and added items to the cart but did not proceed to payment (the company believes nothing leaked for them, but includes them in its notices)

The company says it has no records that distinguish those who attempted payment from those who only used the cart. It also says people who tried to change the card after ordering and did not complete it may have had data leak, but it cannot identify them. If that sounds like you, read the notes in the company's official support notice.

Group A is anyone who ever registered card details on the official shop. Only the last four digits of the card number and the expiry date leaked. The company says the cardholder name and security code did not leak, and no linked member data leaked. It considers misuse based on this alone extremely unlikely.

The headcount is still being checked, so no individual emails have been sent. Not receiving an email does not mean you are out of scope. If you remember registering a card on the official shop, check your statements and contact the issuer about any charge you do not recognize.

Group C items are the delivery and billing name, address, phone number, email address, order contents, amount and payment method type. Card and bank account data are not included. The payment method does not matter: people who paid with PayPal or Amazon Pay can also be in scope if the order had not shipped.

The company says at most 202 of the 7,774 orders (placed by 5,356 people) may actually have been viewed, but it cannot tell which, so it emailed all 5,356 people. You cannot tell from the outside whether yours was viewed. Because a message could quote your real address and order, follow the caution in the next step.

The company asks people not to respond to suspicious emails, calls or text messages claiming to come from the company, public bodies or financial institutions, and not to click links in them. These are not examples the company gave; as this site's own assumption, messages about an apology procedure, re-registering your card or refunding reissue fees are plausible. Treat any message that asks for card details or passwords as fake and check through an official site you open yourself (how to tell: What is phishing?).

To check whether an email is genuine, do not use its links. Go to the company's official support notices instead.

The company says its Rakuten Ichiba store is out of scope because it runs on a separate system. It says no leak of PayPal or Amazon Pay payment data has been confirmed. Unshipped order data can still fall under Group C. Enquiries go through the company's customer support form, which runs on a separate system.

In the company's account, the unauthorized access came to light on October 23, and the program on the payment page was found on October 28. Tampering on the payment page was found separately, after viewing of customer data had been confirmed. Do not read this as a sign of a slow response; read it as an example that viewing of data and tampering with the payment page can happen separately.

On a site where administrator privileges were taken, while investigating what was viewed, also take a list of the scripts the payment page loads and compare it to the intended list. If you have no intended list, save today's list and compare from tomorrow.

The company published its contractor's report that the vulnerability believed to be the cause is not the recently reported PHP vulnerability. Patching the vulnerability everyone is talking about and calling the cause closed leaves other entrances open. Until the logs show how administrator privileges were obtained, keep checking as if other entrances remain.

The company's response included invalidating and renewing the full set of credentials between systems. When administrator privileges are taken, you need to replace not only the site's admin accounts but also the keys and passwords that connect to the payment processor, the database and outside services. Without a list of which credentials exist where, some get missed. Start today by making that list. If you outsource build or operation, ask whether the contractor can provide it (this includes checking that no backdoor remains).