0.7 — Autenticação × Autorização (não confunda)

Dois conceitos que parecem iguais e não são — e confundi-los causa falhas reais:

  • Autenticação (authN): "quem é você?" — provar identidade (login com senha, biometria, token).
  • Autorização (authZ): "o que você pode fazer?" — permissões (um usuário comum não pode acessar o painel de admin).

Passar na autenticação não te dá autorização para tudo. Um erro clássico (seu Ex. 7): o sistema verifica se você tem um token válido, mas não verifica se o token diz que você é admin. Aí um usuário comum forja role: "admin" e entra. Autenticou, mas a autorização estava quebrada.

Senhas e hashing — por que o banco não guarda sua senha

O servidor nunca deve guardar sua senha em texto puro. Ele guarda um hash: uma "impressão digital" irreversível da senha.

  senha "gato123"  ──[função de hash]──▶  "a1b2c3d4..."  (guardado no banco)
  • É de mão única: dá pra gerar o hash a partir da senha, mas não a senha a partir do hash.
  • No login, o servidor calcula o hash da senha digitada e compara com o guardado. Nunca compara a senha em si.

A parte de segurança: qual função de hash importa muito.

  • SHA-256 é rápido — feito para velocidade. Uma GPU testa bilhões por segundo → se sua senha for fraca, é quebrada em segundos (achado do Ex. 28).
  • bcrypt / argon2 são deliberadamente lentos e ajustáveis. Testar bilhões vira testar milhares. É a escolha correta para senhas.

Além disso: salt (um valor aleatório único por senha) impede que duas senhas iguais tenham o mesmo hash, e derruba tabelas pré-calculadas de ataque.

Token / JWT — o crachá que carrega informação

Um JWT (JSON Web Token) é um crachá assinado que carrega informação dentro dele (quem é você, seu papel, quando expira). Ele tem 3 partes separadas por ponto: cabeçalho.dados.assinatura.

  • A assinatura é feita com um segredo que só o servidor conhece. Ela prova que o token não foi adulterado.
  • Se o atacante descobre o segredo (ex.: ele estava vazado no código — Ex. 4/12), ele forja qualquer token, inclusive um de admin eterno. Por isso o segredo é sagrado.
  • O campo exp (expiração) tem que ser obrigatório e validado. Se o servidor aceitar token sem exp, o crachá vale para sempre (achado do Ex. 12.2).

entre para marcar esta aula como concluída.

PurpleLab // plataforma de treino ofensivo + defensivo // Fase 1 — portal dinamico