hashing
5 articles with this tag
Hana-cupid Member Data Breach (Up to 4,238,242 Records): User IDs, Encrypted Passwords and Email Addresses Leaked, and What Members Should Do
Hana-cupid Co., Ltd. announced on October 28, 2026 that unauthorized access by a third party to its online florist services, Internet Hana-cupid and Business Hana-cupid, had leaked some member information. According to the company, a third party accessed its management system without authorization between October 14 (Wed) and October 15 (Thu), and the company confirmed the leak of member information on October 19 (Mon) during its investigation. The count is 4,238,242 (customers who may be affected). The leaked items are: user ID (login ID), password (an encrypted form that cannot be used as it is; the FAQ calls it hashed), PC email address and mobile email address. The company says name, gender, date of birth, address, phone number, credit card number, company name, department name and delivery destination information did not leak. Only members who registered an email address on the company's official online shop (i879.com, i879.com/biz/) are covered; orders through external shopping malls, phone orders without an email address, and purchases at Hana-cupid member florists are not. The company says it does not hold credit card information and that there is no need to stop or reissue a card. It has not confirmed any secondary harm, began emailing affected members individually on October 28, and has reported to the Personal Information Protection Commission and the police. The cause is not stated, and the company is investigating with an external specialist organisation. It says it does not plan monetary compensation or refunds. This site's conclusion: if you could be affected, change your password and any other service where you reused the same ID and password. Check anything claiming to be from Hana-cupid or a financial institution by opening the official site yourself, not through its links.
Takufile-bin Data Leak (2019) — Why Plaintext Password Storage Is Fatal, and the Hashing Defense
A server vulnerability was exploited for unauthorized access, and ~4.8 million records (names, emails, login passwords, dates of birth, including withdrawn customers) leaked. The decisive failure was that login passwords were stored unencrypted, in plaintext. Once leaked, they were immediately usable and could be used for account takeover on other sites where people reused them. Defend by storing passwords as a one-way salted hash, holding no data you don't need, patching vulnerabilities, and preparing for reuse (2FA).
What is password hashing? Storing passwords safely with a one-way transform
Password hashing means storing a password as a one-way, non-reversible transform. Never store plaintext. Unlike encryption you can't decrypt it back — that's the point. But plain MD5/SHA-256 falls to rainbow tables and brute force. The fix: a per-user salt plus a deliberately slow hash (bcrypt/Argon2/scrypt). Don't roll your own — use the standard function.
What is a salt? The random per-user value added when hashing passwords
A salt is a random, per-user value added before hashing a password. The same password then stores differently for every user, which defeats precomputed rainbow tables and stops one cracking run from breaking many accounts. A salt is not secret — store it alongside the hash. bcrypt/Argon2 add one automatically.
How to store passwords safely: the right way to hash and salt
A practical guide to storing passwords safely on the server. Understand why plaintext, encryption, and raw hashes all fail, then converge on one answer: a per-user salt plus a deliberately slow hash (Argon2id recommended, bcrypt/scrypt as alternatives). Don't roll your own — use the standard function, raise the cost over time, and migrate weak hashes by re-hashing on login.