Blog

em uma postagem anterior, Zix | AppRiver discutiu como os responsáveis pelo ataque SolarWinds abusaram de tokens e certificados como parte de sua cadeia de infecção. Os agentes maliciosos passaram a abusar desses mesmos tipos de ativos em campanhas adicionais direcionadas a outras entidades. Isso resultou em um incidente de segurança de certificado confirmado em um provedor de segurança de E-mail.Reconhecendo essas atividades maliciosas, a Zix / AppRiver achou necessário fornecer aos seus clientes uma série de artigos que discutem os tipos afetados de métodos de autenticação e como eles funcionam. Começaremos com autenticação baseada em token.

autenticação baseada em Token: uma visão geral

a autenticação baseada em Token aborda algumas das limitações da autenticação baseada em sessão. Neste último, um servidor cria uma sessão para um usuário quando faz login. Ele armazena o ID da sessão em um cookie, que acompanha todas as solicitações subsequentes se o Usuário permanecer conectado. O servidor verifica a identidade de um usuário comparando o cookie com os dados da sessão armazenados na memória.

uma ilustração da autenticação baseada em sessão. (Fonte: Sherry Hsu)
uma ilustração da autenticação baseada em sessão. (Fonte: Sherry Hsu)

o problema aqui é que a autenticação baseada em sessão sofre de certas desvantagens. Primeiro, requer que o servidor armazene sessões em sua memória. Há também a questão dos cookies que funcionam em vários dispositivos de diferentes mídias (como web e mobile).

é aí que entra a autenticação baseada em token. Essa forma de autenticação envolve um aplicativo que fornece um token assinado ao cliente ao validar um conjunto de credenciais do Usuário. O cliente armazena esse token e o envia com cada solicitação, momento em que o servidor verifica o token e envia informações.

 uma ilustração de autenticação baseada em token usando um JSON Web Token (JWT). (Fonte: Sherry Hsu)
uma ilustração de autenticação baseada em token usando um JSON Web Token (JWT). (Fonte: Sherry Hsu)

nesse sentido, a autenticação baseada em token difere da autenticação baseada em sessão, pois não tem estado. Não envolve armazenar informações sobre um usuário em um servidor ou em uma sessão. Ele armazena esses dados no token do lado do cliente.

benefícios e desafios da autenticação baseada em Token

a autenticação baseada em Token vem com muitos benefícios. Chop-Chop observa que os tokens também funcionam em diferentes sites e mídias, o que cria uma oportunidade para uma maior diversidade de usuários—especialmente aqueles que usam dispositivos móveis. Além de tudo isso, os tokens representam as credenciais de um usuário no processo de concessão de acesso aos dados; alguém que comprometeu um token não teria acesso automático às credenciais da conta do usuário afetado.

dito isso, a autenticação baseada em token não está isenta de seus desafios. O grupo Devbridge observa que alguns tokens de sessão não são gerados de maneira segura, por exemplo. Isso torna possível para um invasor com uma amostra grande o suficiente de IDs de sessão descobrir um padrão e adivinhar os tokens para um grupo maior de usuários. Há também a questão de os invasores aproveitarem armazenamentos de token inseguros, vários logins e/ou longos tempos de validação de token para roubar segredos de autenticação.

como usar com segurança a autenticação baseada em Token

reconhecendo os riscos discutidos acima, Aqui estão algumas práticas recomendadas para usar com segurança a autenticação baseada em token:

  1. gere tokens fortes. Em particular, Devbridge recomenda que os símbolos apresentam um grande conjunto de valores possíveis, incorporar um grau de pseudorandomness e consistem de pelo menos 16 bytes de comprimento.
  2. dê aos tokens uma expiração. É importante definir condições para quanto tempo um token permanece válido, observa Auth0. Obviamente, se um usuário ainda estiver ativo, o token pode ser renovado automaticamente. Mas também há sabedoria em permitir que um token expire quando o usuário fizer logout e encerrar o token, não importa o que tenha decorrido um certo período de tempo.
  3. não permitir logins múltiplos. Conforme observado por Devbridge, é possível usar atributos-chave para evitar autenticações paralelas em que mais de uma pessoa está interagindo com a mesma conta de usuário simultaneamente.
  4. armazene tokens com segurança. O armazenamento Local não é o caminho a percorrer aqui. A DEV Community recomenda o uso de uma política de cookies chamada SameSite para especificar as condições sob as quais um cookie pode ser passado em uma solicitação entre domínios. Uma política estrita do SameSite, juntamente com o requisito de que as pessoas devem uma versão do navegador que suporte essa funcionalidade, ajudará a manter os tokens de sessão seguros.

Deixe uma resposta

O seu endereço de email não será publicado.