How should passwords be stored, and what would you flag in a review if you saw an existing implementation?

Hash with a slow, memory hard function: Argon2id is the current recommendation, with bcrypt and scrypt acceptable. Each password gets a unique salt, which these algorithms generate and store in the output, and parameters should be tuned so hashing takes a meaningful fraction of a second on your hardware. Never use a plain fast hash such as SHA-256 or MD5, never encrypt passwords reversibly, and rehash on login when you raise the parameters.

Argon2id is what I reach for, with bcrypt as the fallback if the platform library is better supported. The point is that it is deliberately slow and memory hard, so an attacker with the dump cannot test billions of candidates per second on a graphics card. Each password gets its own random salt, which those algorithms embed in the encoded output, so identical passwords produce different hashes and precomputed tables are useless. I tune the parameters against real hardware, aiming for a few hundred milliseconds per hash, and I store them with the hash so I can raise them later and rehash transparently the next time a user logs in successfully. In a review, the things I flag are a bare SHA-256 or MD5, anything reversible, a single global salt, and with bcrypt specifically the fact that it silently ignores input past 72 bytes, which quietly weakens long passphrases. Beyond the hash I want rate limiting on login, a check against known breached passwords, and a reset flow with single use expiring tokens.