¿Cómo deberían guardarse las contraseñas y qué señalarías en una revisión si vieras una implementación existente?

Aplica un hash con una función lenta y con uso intensivo de memoria: Argon2id es la recomendación actual, y bcrypt y scrypt son aceptables. Cada contraseña lleva su propia sal, que estos algoritmos generan y guardan en la salida, y los parámetros deben ajustarse para que el hash tarde una fracción apreciable de segundo en tu hardware. Nunca uses un hash rápido como SHA-256 o MD5, nunca cifres contraseñas de forma reversible, y rehashea al iniciar sesión cuando subas los parámetros.

Argon2id es lo que uso, con bcrypt como alternativa si la librería de la plataforma está mejor soportada. La idea es que es deliberadamente lento y consume memoria, así que un atacante con el volcado no puede probar miles de millones de candidatas por segundo en una tarjeta gráfica. Cada contraseña lleva su propia sal aleatoria, que esos algoritmos incrustan en la salida codificada, así que contraseñas idénticas producen hashes distintos y las tablas precalculadas no sirven. Ajusto los parámetros contra hardware real, apuntando a unos cientos de milisegundos por hash, y los guardo junto al hash para poder subirlos después y rehashear de forma transparente la próxima vez que el usuario inicie sesión con éxito. En una revisión, lo que señalo es un SHA-256 o un MD5 a pelo, cualquier cosa reversible, una sal global única y, con bcrypt en concreto, el hecho de que ignora en silencio la entrada más allá de 72 bytes, lo que debilita sin avisar las frases de paso largas. Más allá del hash quiero límite de tasa en el login, una comprobación contra contraseñas ya filtradas y un flujo de restablecimiento con tokens de un solo uso que caducan.