Proteger senhas, contas e projetos: hashing, gerenciadores e rotação de segredos

Proteger senhas envolve duas frentes distintas: as suas, como profissional, e as dos usuários da aplicação que você desenvolve. As duas falham por motivos diferentes e exigem soluções diferentes. Este guia cobre gerenciamento pessoal, armazenamento correto no servidor, políticas de senha segundo recomendações atuais e gestão de segredos em projetos.

Parte 1 — Suas contas

O maior risco individual é reutilização de senha. Quando um serviço qualquer sofre vazamento, atacantes testam automaticamente a mesma combinação em dezenas de outros serviços, técnica conhecida como credential stuffing. Um gerenciador de senhas elimina a raiz do problema ao permitir uma senha diferente em cada lugar sem esforço de memória.

Uma frase de quatro a cinco palavras aleatórias supera em entropia a maioria das senhas curtas com símbolos, e é muito mais fácil de digitar corretamente. Evite frases de músicas ou citações conhecidas, que aparecem em listas de ataque.

Parte 2 — Senhas dos seus usuários

Senha nunca é armazenada em texto puro nem criptografada de forma reversível. Ela passa por uma função de hash lenta, projetada para tornar a tentativa em massa cara. As opções recomendadas hoje são Argon2id, scrypt e bcrypt, nessa ordem de preferência.

import { hash, verify } from "@node-rs/argon2";

const PARAMETROS = {
  memoryCost: 19456, // ~19 MiB, mínimo sugerido pela OWASP
  timeCost: 2,
  parallelism: 1,
};

export async function criarHashDeSenha(senha: string): Promise<string> {
  // O salt é gerado automaticamente e embutido no hash resultante
  return hash(senha, PARAMETROS);
}

export async function conferirSenha(hashArmazenado: string, senha: string) {
  try {
    return await verify(hashArmazenado, senha);
  } catch {
    return false; // hash corrompido ou formato inválido
  }
}

Políticas de senha que ajudam (e as que atrapalham)

As diretrizes atuais do NIST inverteram várias práticas antigas. Regras de composição rígidas e troca periódica obrigatória produzem senhas previsíveis, com incremento de número no final. O que funciona é comprimento mínimo, verificação contra listas de senhas vazadas e troca apenas quando há suspeita de comprometimento.

// Verificação contra vazamentos usando k-anonimato: apenas 5 caracteres
// do hash SHA-1 saem do servidor; a senha nunca é transmitida.
export async function senhaJaVazou(senha: string): Promise<boolean> {
  const dados = new TextEncoder().encode(senha);
  const digest = await crypto.subtle.digest("SHA-1", dados);
  const sha1 = [...new Uint8Array(digest)]
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("")
    .toUpperCase();

  const prefixo = sha1.slice(0, 5);
  const sufixo = sha1.slice(5);

  const resposta = await fetch(`https://api.pwnedpasswords.com/range/${prefixo}`);
  const texto = await resposta.text();

  return texto.split("\n").some((linha) => linha.split(":")[0] === sufixo);
}

Proteções no fluxo de autenticação

• Limite de tentativas por conta e por endereço de origem, com atraso progressivo em vez de bloqueio permanente.
• Mensagem de erro genérica no login: revelar que o e-mail existe facilita enumeração de usuários.
• Comparação em tempo constante ao verificar tokens; a própria biblioteca de hash já cuida disso para senhas.
• Token de redefinição de senha aleatório, com validade curta e uso único, armazenado como hash.
• Invalidação de todas as sessões após troca de senha.
• Notificação por e-mail em login de novo dispositivo e em alteração de credenciais.

Parte 3 — Segredos em projetos

Chave de API em repositório é um dos vazamentos mais comuns e mais fáceis de evitar. Segredos ficam em variáveis de ambiente ou em um cofre gerenciado, com escopo mínimo e prazo de validade sempre que a plataforma permitir.

# Estrutura recomendada
.env                 # local, NUNCA versionado
.env.example         # versionado, apenas nomes das variáveis, sem valores

# .env.example
DATABASE_URL=
STRIPE_SECRET_KEY=
SMTP_PASSWORD=

# Verificar histórico antes de tornar um repositório público
git log --all -p -- .env | head -20

# Se uma chave vazou: revogue primeiro, limpe o histórico depois
# 1) revogar no painel do provedor
# 2) gerar nova chave e atualizar o ambiente
# 3) reescrever o histórico e forçar atualização em todos os clones

Conclusão

Nas suas contas, o essencial é senha única por serviço, gerenciador confiável e segundo fator resistente a phishing. Na aplicação, é Argon2id com parâmetros adequados, política baseada em comprimento e verificação de vazamento, além de proteções no fluxo de login. Nos projetos, é segredo fora do repositório, escopo mínimo e rotação planejada. São poucas decisões, mas cada uma delas remove uma classe inteira de incidentes.

Perguntas frequentes

Fontes consultadas

• OWASP — Password Storage Cheat Sheet
• NIST SP 800-63B — Digital Identity Guidelines
• MDN — Web Authentication API