hashing
4 articles with this tag
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: leaked, they were immediately usable and fed account-takeover on other sites via password reuse. 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.
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.
What is a salt? The per-user 'seasoning' added to a password hash
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.