Por que uma senha guardada gerou duas mensagens de erro sem relação

Ler o original em inglês

debuggingsecuritymigrationdata-model

Imagem de capa: Por que uma senha guardada gerou duas mensagens de erro sem relação

Minutos antes, uma senha tinha passado sem problemas quando a usamos para confirmar que um processo novo funcionava. Aí tentamos a mesma senha, na mesma conta, no sistema que um cliente realmente usaria. Vieram duas rejeições seguidas, com textos sem nada em comum:

Sistema um: “a senha é inválida.” Sistema dois: “não conseguimos verificar quem você é.”

Dois sistemas deram duas reclamações diferentes sobre uma senha que tínhamos acabado de ver funcionar. Essa contradição era o quebra-cabeça inteiro.

Dois escritórios, duas cópias

Dois locais diferentes guardam, cada um, a sua própria cópia dessa senha, ambas ligadas ao mesmo nome de conta. Foi isso que deixou tudo tão desorientador. Um escritório tinha a senha atual. O outro tinha uma cópia antiga, de antes da última troca de senha, e ninguém tinha percebido que as duas haviam se separado.

Essa cópia desatualizada alimentava dois sistemas no segundo local, um mais antigo e um mais novo. Os dois conferiam a mesma senha guardada a cada requisição. Ou seja, uma cópia ruim, conferida duas vezes, gerou duas reclamações que pareciam não ter relação, vindas de dois lugares ao mesmo tempo. Por um tempo pareceu que eram dois bugs separados, cada um pedindo a sua investigação. Não eram. Os dois levavam à mesma cópia desatualizada.

Descobrir isso demorou mais do que corrigir. Quando soubemos a causa, havia uma escolha, e nenhum dos lados saía de graça.

Correção rápida ou verificação completa

Podíamos corrigir só o local que tínhamos acabado de ver quebrado. Levaria poucos minutos e resolveria o problema do cliente que estava ali na nossa frente.

Ou podíamos presumir que todos os outros locais com uma cópia dessa senha tinham a mesma versão desatualizada e verificar cada um antes de dar o assunto por encerrado. Isso significava tempo de verdade, vários lugares em vez de um, e nenhum cliente esperando por isso hoje.

Fizemos primeiro a correção rápida, porque tinha alguém esperando. Mas não demos o assunto por encerrado ali. O que anotamos para a próxima verificação era menos do que “corrigido”: corrigido neste local, ainda não verificado em todos os outros lugares que guardam a sua própria cópia da mesma senha.

Uma cópia desatualizada num lugar raramente é a única. Os outros locais continuam por aí, com a versão que receberam da última vez, até alguém ir conferir.

O que eu faria depois de qualquer troca de senha

Quando uma senha é guardada separadamente em mais de um local, corrigir o local que falhou não prova que os outros estão saudáveis. Liste quais lugares mantêm a sua própria cópia de cada senha e peça para conferi-los depois de qualquer mudança. Enquanto essa verificação não for feita, registre a correção como não verificada em todos os outros.

Receba a próxima história de IA no dia a dia

Histórias em linguagem simples sobre usar IA para facilitar o trabalho do dia a dia. Um e-mail curto quando sair uma nova, sem jargão.