O National Institute of Standards and Technology finalizou uma publicação voltada a ajudar organizações a evitar a exposição de tokens de identidade e acesso online a atacantes. De acordo com o comunicado da agência, o documento finalizado foi elaborado para ajudar organizações a adotar medidas eficazes para manter esses tokens fora das mãos erradas.

Isso é tudo o que o resumo do comunicado do NIST diz. Ele não nomeia, no material disponível no momento da redação deste texto, formatos específicos de token, não lista controles obrigatórios, não estabelece prazos nem impõe obrigações de conformidade. Leitores em busca de um checklist precisarão abrir a própria publicação. O comunicado está disponível em nist.gov.

A razão pela qual isso é importante não é nenhum mistério para quem já passou tempo em um canal de resposta a incidentes. Tokens são o que comprova que um login já aconteceu. Cookies de sessão, tokens de acesso OAuth, refresh tokens, asserções SAML e ID tokens OIDC permitem que o portador pule a porta da frente. Roube um deles e o atacante não precisa da senha, não precisa do segundo fator e não aciona aquele prompt de MFA reluzente que todos passaram o ano passado implantando. A fechadura da porta é excelente. A chave está no local storage do navegador, ou em um arquivo de log, ou na captura de tela de um engenheiro de suporte.

Essa é a piada incômoda da identidade moderna. As organizações melhoraram de forma mensurável no momento da autenticação e ficaram comparativamente descuidadas com tudo o que acontece depois. O token é a prova do trabalho realizado, e prova de trabalho é portátil.

O fato de o NIST publicar orientações finalizadas sobre o tema sinaliza que a proteção de tokens é agora uma preocupação de primeira ordem para um órgão de normalização dos EUA, não uma nota de rodapé em um documento mais amplo sobre autenticação. Para agências federais americanas e os prestadores de serviço que seguem as publicações do NIST por política ou por contrato, isso tende a ter peso. Para todos os demais, as orientações do NIST têm o hábito de se tornarem o ponto de referência que auditores, seguradoras e clientes passam a exigir, geralmente um ou dois anos depois e quase sempre às vésperas de uma renovação.

O que o comunicado não diz merece ser exposto claramente, porque a tentação de preencher lacunas com suposições é grande:

• Ele não indica se a publicação é uma Special Publication, um Interagency Report ou outra série de documentos, nem fornece seu número.
• Ele não indica quais tipos de token ou protocolos estão no escopo.
• Ele não estabelece nenhum prazo de implementação, mecanismo de enforcement ou mapeamento para as diretrizes de identidade digital existentes do NIST.
• Ele não inclui declarações de funcionários do NIST sobre o conteúdo ou o processo de elaboração.

Nenhum desses pontos é uma crítica. Resumos de comunicados são curtos por design. São simplesmente aspectos que devem ser confirmados no texto do documento, em vez de reportados como fato.

O lado encorajador é que esta é uma das raras áreas em que a história defensiva é genuinamente boa. O roubo de tokens é um problema bem compreendido com mitigações bem compreendidas, e a maioria dos provedores de identidade já disponibiliza os recursos relevantes. Tokens de acesso de curta duração, rotação de refresh token, tokens vinculados ao remetente, atributos de cookie que impedem scripts de ler material de sessão e avaliação contínua que revoga uma sessão quando o dispositivo ou a rede deixa de parecer confiável. A parte difícil nunca foi a tecnologia. A parte difícil foi convencer alguém a ativar esses recursos quando a página de login já funcionava e ninguém estava reclamando.

Uma publicação finalizada do NIST oferece às equipes de identidade algo que frequentemente lhes falta: um documento com o selo do governo que pode ser apresentado a product owners que consideram um timeout de sessão de 24 horas um ato de crueldade. Isso não é pouca coisa. Metade da engenharia de identidade consiste em ter o documento certo na reunião certa.

Na prática, as equipes devem baixar a publicação completa e compará-la com seu tratamento atual de tokens, em vez de confiar neste resumo ou em qualquer outro. Verifique por quanto tempo tokens de acesso e sessões vivem em cada provedor de identidade e aplicação, se os refresh tokens rotacionam e são revogados em caso de reutilização, e se os cookies de sessão carregam os atributos HttpOnly, Secure e SameSite. Depois, olhe para os lugares entediantes onde tokens vazam: logs de aplicação, query strings de URL, relatórios de crash e ferramentas de suporte. Encontrar um bearer token ativo em um arquivo de log é constrangedor, mas encontrá-lo antes que um atacante o faça é uma boa semana. Então, vá ter uma boa semana.