Secure passwords for portfolio apps
A recent social post reminded developers that portfolio projects must never store plain‑text passwords and recommended bcrypt/argon2/scrypt with salt rounds as the baseline for real‑world apps. The post included a Node.js example to illustrate proper handling for demo and production projects (x.com).
A password database is supposed to work like a coat-check ticket, not like a key rack. If your portfolio app saves `hunter2` as `hunter2`, anyone who gets the database gets the real password in one read, with no cracking step at all. (owasp.org) A password hash is the coat-check ticket. The server stores a scrambled result instead of the original password, then hashes the login attempt again and compares the two results. (nist.gov) That only works if the scrambling is deliberately slow. The National Institute of Standards and Technology says password hashing schemes take a password, a salt, and a cost factor so each guess becomes expensive for an attacker who steals the file. (nist.gov) A salt is a random extra value added before hashing, like giving every lock its own custom key pattern. The Open Worldwide Application Security Project says modern password-hashing libraries usually generate and store that salt automatically, so two users with the same password still end up with different stored hashes. (owasp.org) That is why security guides keep naming Argon2id, bcrypt, and scrypt instead of Secure Hash Algorithm 256. Secure Hash Algorithm 256 was built to be fast for integrity checks, while password hashers are built to be slow enough to punish bulk guessing. (owasp.org) Argon2id is the modern favorite in the Open Worldwide Application Security Project cheat sheet because it uses both time and memory, which makes graphics-card cracking rigs less efficient. Bcrypt is older and still widely used, which is why many Node.js examples reach for it first. (owasp.org) Bcrypt’s “salt rounds” are its work dial. Raise the rounds and each hash takes longer, which also means your login server does more work for every sign-in attempt. (owasp.org) Node.js gives developers the raw cryptography tools through the `node:crypto` module, but safe password storage usually comes from dedicated libraries that wrap the hard parts. The Open Worldwide Application Security Project notes that most implementations handle salt generation internally, which is exactly the kind of footgun demo apps should avoid. (nodejs.org, owasp.org) The trap with portfolio projects is that “just a demo” often turns into a live app with real email addresses and reused passwords. The moment a recruiter, friend, or first customer can create an account, that toy database stops being fake. (owasp.org) The social post landed because it pushed against a common beginner shortcut: shipping authentication that looks finished from the front end but stores secrets like a spreadsheet on the back end. In 2026, the baseline is simple: never store plaintext, use a password hasher built for login systems, and set the cost high enough that guessing gets expensive on your actual hardware. (owasp.org, nist.gov)