Links mágicos: JWT vs sequência aleatória

Oct 08 2020

Tutoriais que descobri sobre a implementação de autenticação de link mágico (no Node) recomendam um mecanismo como este:

  1. o usuário acessa seu endpoint com seu endereço de e-mail
  2. você gera um JWT assinado a partir do e-mail e da data usando uma chave constante (se você for um pouco mais experiente, você usa o RS256esquema assimétrico em vez do simétrico HS256usado na maioria dos tutoriais (sendo o padrão, eu acho))
  3. envie o e-mail com o token como um parâmetro de consulta
  4. o usuário clica, o endpoint é atingido, você verifica o JWT, o e-mail e a data dentro

Desculpas pela questão do cérebro possivelmente muito pequeno , mas por que realmente precisamos de hash ou criptografia aqui?

  1. Não seria mais prudente apenas gerar uma string alfanumérica grande (como 50 caracteres), única, aleatória (vamos chamá-la LURA), em seguida, armazenar o e-mail e a data e enviar para o usuário? Quando os pontos de extremidade de verificação são atingidos, podemos dizer, "sim, eu tenho isso no arquivo e emiti 2 minutos atrás, em você ir" . O objetivo de usar o JWT seria verificar se fui eu quem criou o token (com minha chave), mas também posso verificar se apenas ver se tenho a LURAstring no arquivo, certo? Além disso, o JWT tem problemas . Tenho a sensação de que o JWT foi projetado para ser usado quando a máquina que o está validando é diferente daquela que o está emitindo e que seu uso é prejudicial à segurança neste caso.

  2. Pergunta bônus : eu li várias vezes sobre criptografar senhas , que SHA256é muito fraco em 2020 e que deve ser escolhido Argon2. Por que então é RS256uma boa escolha se "deve ser entendido como SHA 256 com chaves RSA 2048 bits".

Respostas

2 Sjoerd Oct 08 2020 at 18:15

Não seria mais prudente apenas gerar uma grande ... string

Sim, seria. Um token geralmente é uma solução direta e mais fácil de acertar. As soluções criptográficas frequentemente apresentam armadilhas ou precisam ser implementadas de forma totalmente correta para serem seguras. Os tokens aleatórios são mais seguros porque são mais simples.

Os JWTs são especialmente úteis quando há vários sistemas: se um sistema fornece o token para acessar outro sistema e eles não têm acesso ao mesmo banco de dados.

SHA256 é muito fraco em 2020

SHA256 ainda é considerado uma função hash de uso geral segura. O problema é que as funções hash de propósito geral não são adequadas para criptografar senhas, pois são muito rápidas. Como um computador normal pode calcular bilhões de hashes SHA256 por segundo, é possível quebrar a senha usando bilhões de suposições por segundo.

No entanto, no JWT, o SHA256 não é usado para senhas, mas para integridade da mensagem, portanto, não é um problema que seja rápido. Não há nada para adivinhar.

1 AlphaD Oct 08 2020 at 13:45

É verdade que você pode usar uma string aleatória para o link mágico e funcionará perfeitamente. No entanto, existem alguns benefícios em escolher implementá-lo usando JWTs:

  1. A validação JWT não requer uma chamada para o banco de dados. Este é talvez o principal benefício de usar JWTs. Dependendo do número de usuários, isso pode significar uma diferença significativa de desempenho.
  2. É mais fácil integrar com mecanismos de login existentes, como provedores de identidade (possivelmente terceiros) que já lidam com a criação / verificação / armazenamento de tokens. Isso é útil, por exemplo, se seu aplicativo já estiver usando tokens para fazer login de usuários com a combinação tradicional de nome de usuário / senha e quiser adicionar links mágicos como uma opção adicional.

Quanto à sua pergunta sobre os algoritmos, para RS256 / HS256 em JWT a finalidade não é criptografar, mas assinar . Os requisitos do algoritmo para criptografia e assinatura seguras são diferentes (e ainda mais diferentes se estivermos falando sobre hashing de senha).

Como uma observação adicional, a razão para escolher entre RS256 e HS256 é se você pretende ou não permitir que outros verifiquem seu token.

Para RS256, você cria um par de chaves pública / privada. Você gera a assinatura usando a chave privada, enquanto um terceiro pode verificar um token que você criou usando sua chave pública. Para HS256, a chave para assinatura e verificação é a mesma, então normalmente você a mantém em segredo, o que significa que apenas você pode verificar o token.