Privacidade na Verificação por Número de Telefone: O Que Todo Desenvolvedor Precisa Saber
Isto se aplica a todas as linguagens. A maioria dos projetos não faz isso. Sua linguagem não importa aqui.
Você pensa no que acontece após seu usuário confirmar o código de verificação que insere?
A maioria dos sistemas que já vi, e que você irá construir, inclui:
Armazenamento em texto simples do número de telefone sem criptografia, em alguma coluna de telefone de alguma tabela de usuários.
Sem política de retenção para os dados de verificação.
Sem implicações de privacidade além de: "são os dados de cadastro do usuário."
Este não é um artigo de JavaScript. Trata-se de princípios de privacidade para todos os sistemas, em todas as stacks e linguagens. É sobre criar sistemas que se importam com a forma como os números de telefone dos usuários são tratados.
Números de telefone são especiais. Os projetistas de sistemas precisam se importar com isso. Quanto mais cedo você perceber isso, mais fácil será desenhar sistemas melhores.
Por que o Número de Telefone é Diferente de Outros Dados
Dados têm uma hierarquia informal de sensibilidade, e para a maioria dos usuários e desenvolvedores esses dados têm uma ordem de sensibilidade que mais ou menos assim:
Alta sensibilidade: senha, dados de cartão de crédito, documentos de identidade
Sensibilidade média: email, endereço, data de nascimento
Baixa sensibilidade: nome, foto de perfil, preferências
Na maioria dos sistemas, o número de telefone está na categoria de sensibilidade média ou até baixa, e essa classificação está incorreta, tendo consequências reais.
Números de telefone hoje são como senhas. Não são realmente como emails. Em alguns aspectos, são ainda piores. Veja alguns pontos.
Eles são a chave mestra de tudo. WhatsApp, Instagram, bancos, até seu email principal e corretoras de investimento. Uma senha comprometida permite que pessoas acessem sua conta, mas um número de telefone comprometido permite acesso às suas contas e muito mais. Isso é bem pior.
Estão ligados ao seu CPF no Brasil. Para brasileiros, números de telefone são uma conexão direta à identidade física e rastreável de alguém. Não são anônimos.
São permanentes como seu CPF, mas não como seus emails. Não é fácil trocar de número de telefone. Pessoas trocam emails, mas podem ser identificadas pelos seus números de telefone daqui a dez ou mais anos.
Números de telefone são a ponte entre as principais plataformas. São uma das informações mais utilizadas por corretores de dados para cruzar informações. Você talvez não saiba, mas adicionar um telefone pode virar parte de uma ferramenta de cruzamento de dados.
A Pergunta Que Vem Antes de Codificar
A equipe deve responder uma questão de decisão de arquitetura e produto sobre a implementação de um fluxo de verificação por telefone. Essa questão deve ser resolvida antes de qualquer linha de código.
A questão é: “Após a verificação, ainda queremos manter o número de telefone?”
A maioria dos aplicativos opta por não responder a essa questão, e mantém o número, independentemente de precisar ou não dele.
Alguns casos de uso:
Sim, você precisará do número se planeja usar sua implementação de SMS como login na 2FA. Nesse caso, será necessário o número de SMS para enviar a mensagem, e ele deve ser capturado com cuidado.
Sim, o aplicativo precisará do número de SMS do usuário se planeja enviar notificações ou alertas via SMS. Novamente, o mesmo cuidado na coleta e uso do número.
Se o objetivo da verificação é apenas confirmar que o usuário tem acesso a um dispositivo real, provavelmente não é necessário manter o número. Um token ou hash da verificação será suficiente.
Provavelmente, você não precisa guardar o número se o objetivo é evitar múltiplos cadastros com o mesmo número. Um hash criptográfico do número será suficiente e atenderá ao requisito de verificação.
Princípios de Implementação Responsável
Princípio 1: Minimização de Dados
Esse princípio também está na LGPD (Artigo 6º, III). É uma boa prática minimizar a coleta de dados, mesmo quando a lei não exige.
Na prática: armazenar um número apenas para enviar um SMS depois é desnecessário. Se o número precisar ser verificado, pode-se usar um hash para verificar se um número já foi utilizado. Se for necessário usar o número para completar uma verificação em duas etapas, então ele pode ser criptografado.
Como você nunca armazenou o número, ele não pode vazar. Também não precisa procurar uma resposta para perguntas sobre possíveis vazamentos.
Princípio 2: Os Dados Mais Seguros São Dados Inexistentes
Na segurança de dados, os dados mais seguros são aqueles que você não possui.
Cada ponto de dado representa um risco e uma obrigação. Números de telefone são os dados de maior risco.
Ao optar por não armazenar o número ou apenas armazenar seu hash, simplifica-se o sistema e elimina-se risco de ataque completo.
Princípio 3: Separação entre Prova e Dados
Esse é o princípio mais poderoso, mas o menos utilizado.
Quando um usuário verifica seu número, tudo que você precisa é de uma prova de que a verificação ocorreu, e não precisa armazenar o número.
Com duas informações distintas, separar a gestão delas proporciona mais controle.
Pense assim: após verificar o telefone, você poderia enviar esse número a um serviço de mensagens que dele precisa para enviar mensagens. Você enviaria o número ao serviço de mensagens, enquanto o restante do sistema recebaria um token dizendo: “Este usuário verificou seu telefone,” e esse token não conteria o número. O número não precisa estar fora do serviço de mensagens.
Separar o número dessa forma também significa que uma vulnerabilidade no sistema principal não vazaria os números de telefone. Você poderia até deletar o número e isso não afetaria a verificação do usuário. Desenvolvedores que não precisam do acesso ao número nunca precisariam vê-lo.
A criptografia é uma exigência ao armazenar
Se você chegar à conclusão de que não pode evitar armazenar o número de telefone do usuário, então deve saber que não pode permitir que números de telefone sejam armazenados sem criptografia após 2025.
O que isso significa na prática, independentemente da linguagem ou pilha de tecnologia que você estiver usando?
Você deve implementar criptografia simétrica autenticada. AES-256-GCM é o padrão atual para criptografia. Não use modos de criptografia mais antigos que não forneçam criptografia autenticada, pois eles estão vulneráveis a múltiplas ameaças.
A chave de criptografia deve ser gerenciada externamente. Se a chave estiver no mesmo sistema que os dados, muitas vezes a criptografia não fornece tanta proteção quanto parece. AWS, GCP e HashiCorp Vault são soluções padrão.
Planeje a rotação de chaves desde o início — a rotação de chaves é difícil de implementar posteriormente. Planejar antecipadamente é muito mais fácil. Para isso, mantém-se um registro de qual chave foi usada para criptografar um registro.
Crie um hash para buscas e deduplication — não é possível pesquisar um campo criptografado. Para contornar isso, é armazenado um hash que ainda é secreto, mas é determinístico, e permite verificar se um registro existe.
Princípio 5: Seus Logs Nunca Devem Conter Números de Telefone
Este é um dos erros mais comuns e ainda subestima frequentemente o risco.
Os logs de aplicativos são alguns dos dados mais facilmente acessíveis no sistema. Eles estão disponíveis para toda a equipe de desenvolvimento, enviados para serviços externos de monitoramento, possuem uma política de retenção de dados prolongada e raramente são criptografados.
Um único console.log ou print descuidado com um número de telefone pode permitir que esse número apareça em:
Logs de aplicativo acessíveis a todos os desenvolvedores
Ferramentas de monitoramento como Datadog, New Relic e Splunk
Logs de erros enviados ao Sentry, Bugsnag, e similares
Logs em aplicações que são menos seguras que o banco de dados de produção
O número de telefone nunca deve estar nos logs. Se precisar rastrear um caso específico, registre os últimos quatro dígitos ou um identificador aleatório do caso.
Princípio 6: Limitação de Taxa Protege a Privacidade Além do Custo do SMS
É comum justificar a limitação de taxa de verificação por SMS pelo custo da mensagem. No entanto, também é uma forma de proteger a privacidade.
Sem limitação de taxa, atacantes podem fazer várias ações maliciosas com seu endpoint. Eles podem:
Enumeração de números — verificar quais números estão no sistema comparando as diferenças de respostas (como, se o número está registrado ou não).
Abuso de SMS — confirmar se os atacantes podem enviar mensagens para um número e causar uma situação de assédio.
Análise de comportamento — em sistemas que possuem mensagens diferentes para usuários ativos ou não, podem analisar o comportamento e descobrir quando os usuários estão ativos.
Boa limitação de taxa aplica duas dimensões: por IP e por número de telefone. A primeira aplica-se ao atacante e a segunda protege o usuário de muitas tentativas. A segunda dimensão geralmente é negligenciada.
Princípio 7: Respostas de Erro Não Devem Confirmar Existência
Este princípio é para proteção contra enumeração.
Se houver respostas diferentes para os códigos como "número não registrado", "número já verificado" ou "número localizado", seu endpoint está vazando informações. Atacantes podem automatizar sistemas para verificar números e não precisam de técnicas sofisticadas. A única forma de responder ao usuário é: "Se este número for válido, você receberá um código em breve", e tudo mais deve ser processado em segundo plano.
O Ciclo de Vida do Número: Registro até Descarte
Uma implementação deve definir o que significa o ciclo completo do número de telefone no sistema.
Aqui está a abordagem passo a passo que adotamos para lidar com informações sensíveis.
Coleta: Geraremos informações apenas quando tivermos uma razão específica para isso, e o sujeito tiver fornecido consentimento informado. O sujeito deve saber para que sua contribuição será usada.
Verificação: A informação existsirá apenas no cache de sessão temporária. Ela nunca será mantida em cache permanente desnecessariamente.
Pós-verificação: Tomaremos uma decisão informada sobre o que armazenar. Armazenaremos a informação em formato de hash para deduplicação. Se precisarmos relacionar essa informação para comunicação futura, encryptaremos a informação. Nada será armazenado em texto simples.
Uso ativo: A informação só será acessada pelo serviço que precisa dela por uma razão específica e particular. A informação não estará acessível como dados gerais do usuário para toda a aplicação.
Inatividade: Teremos uma política de retenção definida. Após um número predeterminado de meses sem uso relevante, a informação será removida ou anonimizada automaticamente.
Exclusão sob solicitação: O sujeito tem o direito (LGPD Art. 18, IV) de solicitar a remoção de suas informações. O processo será implementado e não ficará como uma promessa vazia.
O que isso tem a ver com Números Virtuais?
Se você está trabalhando na integração de verificação por SMS — que todo desenvolvedor precisa fazer em algum momento — há uma prática que incentiva o uso de um número virtual dedicado para ambientes de teste e homologação.
Por que você deve se preocupar?
Quando você usa seu número pessoal para testar o fluxo de verificação por SMS do seu produto, está adicionando seus dados pessoais reais a um ambiente de teste que provavelmente possui menos segurança rigorosa e registros de auditoria do que o ambiente de produção. Isso vai totalmente contra tudo que discutimos até agora.
Uma olhada no pacote random-sms-number disponível no npm nos dá uma maneira limpa de lidar com o problema apresentado anteriormente.
Esse número é temporário, útil apenas para o teste, e nem pertencerá ao membro da equipe nem ajudará o membro. Se o projeto for considerado concluído, esse número pode facilmente ser descartado junto com o ambiente.
Aqueles que trabalham no Brasil podem optar pelo NumeroVirtual.net, que é adequado para fornecer números virtuais de alta qualidade e compatíveis para SMS, o que elimina a necessidade de pedir aos membros da equipe que forneçam seu número de celular para o trabalho.
Isso demonstra respeito pelos números de celular privados das pessoas, e o princípio por trás disso é o mesmo respeito pelos dados pessoais.
Implementando os Conceitos Acima
Você pode aplicar os princípios descritos nas seções anteriores com qualquer linguagem de programação com a qual trabalhe. Go, Python, Ruby, PHP, Java, Rust. Além das bibliotecas disponíveis, as opções de design permanecerão as mesmas.
O que Saber Antes de Adicionar Verificação de Número de Telefone
Reúna sua equipe e responda às seguintes perguntas.
Por que precisamos de um número verificado? Para que propósito? Quanto tempo precisamos dele?
Se decidirmos salvá-lo, como planejamos mantê-lo seguro? Onde colocaremos a trava de segurança? Como evitaremos que a trava de segurança seja utilizada em excesso?
Se estamos salvando números, tudo bem que eles nunca apareçam nos logs? Checamos tudo para ver se eles são registrados?
Quando planejamos eliminar os números dos usuários? Como planejamos fazer isso? Realmente vamos remover os números se o usuário pedir?
Quem planejamos deixar usar os números para testar isso? Existe um número virtual especial para isso ou planejamos usar números pessoais?
Você responderá a essas perguntas antes de adicionar qualquer código de verificação de telefone, e seu código será melhor por isso, independentemente do estilo de programação que usar ou do tamanho do projeto.
Respeitando a Privacidade dos Usuários
Respeitar a privacidade dos usuários não é algo que você deve planejar fazer depois. É algo que você deve decidir durante as fases de planejamento de um projeto.
Os números de telefone que você decidir salvar não desaparecerão. As pessoas migrarão os números salvos. Backups precisarão ser feitos. Normas mudarão, e números antigos se tornarão novos novamente.
Cuidar dos dados dos usuários faz parte de uma construção de produto responsável. Descobrimos que usuários e reguladores gostariam de ver isso feito em todos os produtos criados no Brasil e além. Já passou da hora de essa prática ser adotada em todas as línguas e todos os produtos.
Qual desses princípios você acha que os desenvolvedores mais ignoram no mundo real? Coloque nos comentários. Esse é o tipo de crítica construtiva que une a comunidade de desenvolvedores.
Top comments (0)