rate limiting
3 articles with this tag
Baitoru breach (up to about 3.89 million email addresses): only emails leaked — how members can spot fake interview messages and job scams
On October 9, 2026, dip Corporation announced that on October 6 it had confirmed unauthorized third-party access to Baitoru and Baitoru NEXT, the job sites it runs in Japan, and that some member email addresses had leaked. The number of addresses that may have leaked is up to 3,885,771. The company says only email addresses leaked and that names, phone numbers, passwords and credit card details were not included. It attributes the cause to unauthorized access from overseas that exploited a flaw in the specification of part of its system. It blocked all access from overseas and modified the program. It has not confirmed any posting of the data online or any misuse. Affected members were told on the services on October 6 and are being contacted individually by email and other means. There was no follow-up notice as of October 10. This site's take: even if only email addresses leaked, they are known to belong to job-site members. Do not open links in messages about interview schedules or application confirmations; check in the official app you open yourself. Do not move to other messaging apps or answer offers of 'high pay, paid the same day'.
Japan's Four Major 2026 Data Breaches (KDDI, Aflac, Digital Agency, Sakura): Different Ways In, the Same Fix — Better Detection
KDDI (ISP mail platform, about 12.23 million people), Aflac Japan (about 4.4 million), Japan's Digital Agency (about 246,000 records) and Sakura Internet (up to about 1.36 million accounts). The ways in had nothing in common, yet KDDI, Aflac and Sakura all listed stronger detection in their remediation plans, and the Digital Agency case was caught through an anomaly in volume. This site's view: stop assuming intrusions can be fully prevented, and invest in watching volume and time, the only signals left when an attack looks like legitimate use.
Rate limiting and abuse control: designing limits that stop brute force and runaway costs
Rate limiting usually fails not because the limit was too loose but because the wrong question was asked. Three questions: who you count (IP can be forged and is shared by real users, so identity comes first), what you count (requests alone miss expensive single operations — cost, size, record counts), and what happens at the ceiling (blunt lockout is a denial of service against legitimate users). NIST caps consecutive failures at 100 and asks for delays and CAPTCHA instead of shutting people out; OWASP includes third-party spending limits, the final control against financial damage.