As credenciais de acesso dos usuários de um aplicativo são armazenadas em um banco de dados e são utilizadas unicamente para acesso às funcionalidades do aplicativo. A equipe de desenvolvimento definiu como requisito não funcional que o sistema deve evitar que as senhas sejam obtidas por um invasor mesmo que o aplicativo ou banco de dados esteja comprometido. Para implementar o requisito não funcional, um modo de proteger as senhas dos usuários é:
- A)ocultar o algoritmo utilizado para proteção das senhas;
Errada, porque ocultar o algoritmo não protege de verdade as senhas, já que segurança por obscuridade não é uma garantia confiável.
- B)armazenar as senhas cifradas por meio de um algoritmo de chaves assimétricas;
Errada, porque criptografia assimétrica não é a abordagem usual para armazenar senhas e continua sendo reversível com a chave privada.
- C)utilizar um algoritmo hash com salt antes de persistir as senhas no banco de dados;
Certa, porque hash com salt é a técnica adequada para armazenar senhas de forma resistente a vazamentos e ataques de recuperação.
- D)codificar um algoritmo próprio para cifrar as senhas com base em uma chave randômica segura;
Errada, porque algoritmo próprio e chave randômica segura não são boas práticas para proteção de senhas e ainda criam risco de reversibilidade.
- E)usar uma chave randômica gerada pelo aplicativo para cifrar as senhas por meio de um algoritmo de chave simétrica.
Errada, porque criptografia simétrica com chave gerada pelo aplicativo depende da proteção dessa chave e, se ela vazar, as senhas podem ser recuperadas.
Gabarito: C
Quando o assunto é senha, a ideia não é apenas "esconder" o valor no banco, mas torná-lo impraticável de recuperar mesmo se a base vazar. Em engenharia de software, a proteção correta de credenciais não usa criptografia reversível como solução principal, porque se a chave for descoberta, tudo volta a ficar legível. O caminho seguro é tratar a senha com hash, de preferência com salt, antes de armazená-la. O hash é uma função de mão única: você gera uma saída a partir da senha, mas não consegue voltar à senha original a partir do resultado. O salt, por sua vez, é um valor aleatório acrescentado à senha antes do hash para evitar ataques com tabelas pré-calculadas, como rainbow tables, e também para impedir que senhas iguais produzam o mesmo hash. Por isso, a alternativa C está correta: usar um algoritmo hash com salt antes de persistir as senhas no banco atende ao requisito de evitar que elas sejam obtidas por um invasor mesmo se o aplicativo ou o banco forem comprometidos. Em termos práticos, isso significa que o sistema não guarda a senha, guarda apenas um derivado seguro dela. Esse entendimento é o padrão de boas práticas da área e aparece de forma recorrente em guias de segurança como o OWASP, que recomenda hash forte e salt para armazenamento de senhas. Em prova, desconfie de soluções com criptografia reversível, chave secreta guardada no sistema ou algoritmos próprios: senha gosta de truque simples, não de mágica arriscada.