Falhas criptográficas: senha e dado sensível guardados do jeito errado

Falhas criptográficas englobam qualquer situação em que um dado sensível — senha, dado financeiro, informação pessoal identificável — é armazenado ou transmitido de forma que não protege adequadamente sua confidencialidade.

Senha não deveria ser criptografada, deveria ser transformada em hash

Existe uma confusão comum: criptografia é reversível (com a chave certa, o dado original pode ser recuperado); hash, quando bem implementado, não é. Senha deveria sempre passar por uma função de hash específica para esse fim — como bcrypt ou Argon2 — que, mesmo se o banco de dados for comprometido, torna a recuperação da senha original extremamente custosa.

Por que hash genérico (como MD5 ou SHA-1 sozinho) não é suficiente

Funções de hash genéricas foram desenhadas para velocidade, não para resistência a ataque de força bruta contra senhas — o que as torna, na prática, insuficientes para esse uso específico, mesmo sendo tecnicamente "hash". Funções específicas para senha são deliberadamente lentas e usam salt (um valor aleatório único por senha) para impedir ataques baseados em tabelas pré-computadas.

Dado sensível que não é senha

Para dados como número de documento, informação de saúde ou dado financeiro que, diferente de senha, eventualmente precisam ser recuperados em sua forma original, o mecanismo correto é criptografia — com gestão adequada de chaves, separada do próprio dado armazenado.

O erro mais comum na prática

Não costuma ser "não usar nenhuma proteção" — costuma ser usar o mecanismo errado para o tipo de dado errado, ou implementar corretamente em uma parte do sistema e esquecer de aplicar o mesmo padrão em uma funcionalidade adicionada depois, como um sistema de importação de usuários em massa ou uma integração legada.