Questão de Segurança da Informação — Ataques a Senhas — VUNESP 2024

Salt em Senhas — Armazenamento Seguro

Gabarito: letra B. Quando um salt aleatório e único é gerado para cada senha, ele precisa ser armazenado no banco de dados junto com o hash resultante, pois sem o salt é impossível recalcular o hash para verificar a senha no login. Essa é a prática correta e segura de armazenamento de senhas com salt.

O salt é um valor aleatório adicionado à senha antes do cálculo do hash, com o objetivo de tornar cada hash único, mesmo para senhas idênticas. A função hash é unidirecional: transforma uma entrada de tamanho variável em uma saída de tamanho fixo, e não é possível reverter o processo para obter a entrada original. O salt não precisa ser secreto — ele pode ser armazenado em texto claro no banco de dados —, mas precisa ser único para cada usuário e suficientemente longo para ser eficaz.

O principal benefício do salt é neutralizar ataques baseados em tabelas pré-computadas, como as rainbow tables. Sem salt, um atacante que obtém o banco de dados de hashes pode comparar os hashes com uma tabela pré-computada de hashes de senhas comuns. Com salt, cada senha gera um hash diferente, tornando a rainbow table inútil, pois seria necessário pré-computar hashes para cada combinação de salt e senha — algo impraticável se o salt for longo e aleatório.

Outro benefício importante é impedir que dois usuários com a mesma senha tenham o mesmo hash, dificultando a análise de padrões e a reutilização de senhas entre sistemas. O salt também dificulta ataques de dicionário em massa: sem salt, o atacante calcula hash(tentativa) uma vez e compara com todos os hashes do banco; com salt, ele precisa calcular hash(salt_do_usuario + tentativa) para cada usuário individualmente, multiplicando o esforço computacional.

É importante distinguir o que o salt faz do que ele não faz. O salt não protege contra ataques de força bruta ou dicionário em uma única senha, pois o atacante tem acesso ao salt e pode usá-lo para testar tentativas. O salt também não protege contra ataques man-in-the-middle, que ocorrem durante a transmissão da senha pela rede — para isso, usa-se criptografia de canal (TLS/SSL). E o salt não é o que impede a "inversão" do hash: a função hash é unidirecional por natureza, com ou sem salt, e a segurança contra a obtenção da senha original vem dessa propriedade, não do salt.

A pegadinha desta questão está em confundir o papel do salt: ele protege contra ataques offline ao banco de dados (rainbow tables, reutilização de hashes), mas não contra ataques online à transmissão (man-in-the-middle) nem é o mecanismo que torna o hash unidirecional. A alternativa correta é a que reconhece a necessidade de armazenar o salt junto com o hash.

Alternativa A — ❌ Incorreta

Afirma que se pode usar um salt fixo e geral para todas as senhas, sem riscos, e que não é necessário armazená-lo. Isso é incorreto: um salt fixo para todas as senhas não impede que senhas iguais gerem hashes iguais, e não protege contra rainbow tables pré-computadas para aquele salt específico. O salt deve ser único e aleatório para cada senha, e precisa ser armazenado para permitir a verificação no login.

Alternativa B — ✅ Correta ⟵ GABARITO

Afirma que, se gerado um salt aleatório único para cada senha, ele também precisa ser armazenado no banco de dados, além do hash. Isso é exatamente o que a prática correta exige: o salt é necessário para recalcular o hash na autenticação, e como é único por usuário, não há como derivá-lo — ele deve ser guardado em texto claro (não precisa ser secreto) junto com o hash.

Alternativa C — ❌ Incorreta

Recomenda salts curtos de até 3 caracteres por questões de desempenho. Isso é incorreto: salts curtos reduzem drasticamente a eficácia contra rainbow tables, pois o espaço de combinações possíveis é pequeno. A recomendação é usar salts longos (geralmente 16 bytes ou mais) e aleatórios; o custo computacional de um salt mais longo é desprezível frente ao ganho de segurança.

Alternativa D — ❌ Incorreta

Afirma que o salt ajuda a mitigar ataques man-in-the-middle, mas não ataques baseados em tabelas de hashes pré-computados. É exatamente o inverso: o salt protege contra ataques offline ao banco de dados (rainbow tables, reutilização de hashes), mas não tem efeito sobre ataques man-in-the-middle, que ocorrem durante a transmissão da senha pela rede e são mitigados com criptografia de canal (TLS/SSL).

Alternativa E — ❌ Incorreta

Afirma que o uso de salts impede que a senha original seja obtida via cálculo da função hash inversa, e que esse impedimento não existe sem salts. Isso é incorreto: a função hash é unidirecional por natureza, com ou sem salt — não existe "função hash inversa" viável. O salt não é o mecanismo que impede a reversão; ele protege contra ataques de tabelas pré-computadas e reutilização de hashes, não contra a propriedade unidirecional do hash.

Gabarito: letra B