Como as senhas devem ser armazenadas, e o que você apontaria numa revisão se visse uma implementação existente?

Faça hash com uma função lenta e intensiva em memória: Argon2id é a recomendação atual, com bcrypt e scrypt aceitáveis. Cada senha recebe um salt único, que esses algoritmos geram e guardam na saída, e os parâmetros devem ser ajustados para que o hash leve uma fração perceptível de segundo no seu hardware. Nunca use um hash rápido simples como SHA-256 ou MD5, nunca criptografe senhas de forma reversível, e refaça o hash no login quando você aumentar os parâmetros.

Argon2id é o que eu escolho, com bcrypt como alternativa se a biblioteca da plataforma tiver suporte melhor. O ponto é que ele é deliberadamente lento e intensivo em memória, então um atacante com o dump não consegue testar bilhões de candidatos por segundo numa placa de vídeo. Cada senha recebe o próprio salt aleatório, que esses algoritmos embutem na saída codificada, então senhas idênticas produzem hashes diferentes e tabelas pré-computadas ficam inúteis. Eu ajusto os parâmetros contra hardware real, mirando algumas centenas de milissegundos por hash, e guardo esses parâmetros junto com o hash para poder aumentá-los depois e refazer o hash de forma transparente no próximo login bem-sucedido. Numa revisão, o que eu aponto é um SHA-256 ou MD5 puro, qualquer coisa reversível, um salt global único e, no caso do bcrypt especificamente, o fato de ele ignorar em silêncio a entrada além de 72 bytes, o que enfraquece discretamente frases longas. Além do hash, eu quero limitação de taxa no login, uma checagem contra senhas sabidamente vazadas e um fluxo de redefinição com tokens de uso único e expiração.