Como funcionam os segredos TOTP (e porque não se devem partilhar)

Um segredo TOTP é uma cadeia aleatória, de 16 a 32 carateres base32, que o fornecedor gera uma vez e nunca muda. Não deriva da sua palavra-passe, não está ligado a nenhum aparelho, e não tem validade. Qualquer cópia produz códigos válidos para sempre, e nada na conta lhe consegue dizer quantas cópias existem.

Está aqui todo o processo contra a sua partilha. Cada uma destas proposições merece o seu detalhe, e há que acrescentar o que se faz de uma conta cujo segredo já circulou, uma vez que a pergunta chega quase sempre tarde demais.

O que é um segredo, ao certo

A mecânica que transforma um segredo em seis dígitos é tratada no guia completo do TOTP em equipa. O que conta aqui é o que o segredo é enquanto objeto.

É simétrico. Os dois lados detêm o mesmo valor. Não há metade pública: não há, portanto, nada que possa distribuir sem risco.

Tem muita entropia e não se adivinha. De 80 a 160 bits de aleatoriedade. Nenhum ataque prático consiste em calculá-lo, e é precisamente por isso que qualquer incidente real é uma cópia.

Não tem ciclo de vida. Sem validade, sem versão, sem lista de revogação, sem rotação. O protocolo não tem qualquer vocabulário para «esta cópia já não é válida», apenas para «este segredo já não está configurado na conta».

É independente da palavra-passe. Repor uma não faz nada à outra. As equipas mudam as palavras-passe depois de uma saída e deixam o segundo fator no lugar, que é a metade errada se o segredo viajou.

Os sítios onde acaba uma cópia

Esta lista merece ser lida devagar. O argumento contra a partilha não é que uma cópia seja perigosa, é que as cópias se acumulam onde ninguém olha.

• A base de dados do fornecedor, no seu lugar.
• A aplicação de autenticação de todos os que leram o código QR.
• A cópia de segurança do aparelho de cada um desses telemóveis, onde quer que viva.
• A sincronização na nuvem das aplicações que a propõem, ou seja, a maioria hoje.
• A captura de ecrã tirada durante a configuração, num álbum de fotografias, ele próprio sincronizado.
• A mensagem de conversa onde foi publicado, mais o índice de pesquisa e a retenção dessa plataforma.
• A entrada de cofre partilhada, exportada um dia para um ficheiro que ninguém apagou.
• A variável de ambiente num executor de CI ou num servidor, se um automatismo iniciar sessão.

Duas coisas são verdadeiras para todos os elementos depois do primeiro. Nenhum aparece em qualquer parte das definições de segurança da conta, e nenhum é apagado por uma ação que possa fazer dentro da conta.

Porque «só o partilhámos uma vez» nunca é uma vez

Um segredo partilhado uma vez não fica num só sítio, porque os sistemas onde aterra estão concebidos para copiar coisas.

Um telemóvel é copiado e depois restaurado no seu substituto. Uma aplicação de autenticação acrescenta a sincronização na nuvem numa atualização, e o segredo está agora numa conta em que não tinha pensado. Um cofre é exportado antes de uma migração. Uma plataforma de conversa conserva o histórico e torna-o pesquisável por todos os que chegam depois, incluindo os que não estavam na equipa no momento da mensagem. O portátil de um prestador vai-se embora com o prestador.

Nada disto supõe que alguém se comporte mal. É o funcionamento corrente do software de consumo, e é por isso que o número de cópias de um segredo partilhado nunca deixa de crescer.

O que a sua partilha lhe custa

Contagem. Não consegue saber quantas cópias existem.

Revogação. Não consegue retirar uma. Só consegue invalidá-las todas reconfigurando a conta.

Independência. Um segredo guardado ao lado da palavra-passe faz com que um único comprometimento entregue os dois fatores, o que equivale a um fator único com passos a mais.

Atribuição. Qualquer das cópias pode ter produzido o código usado às 03h12. Nenhum registo, em lado nenhum, dirá qual.

Tudo o que uma equipa espera da 2FA numa conta partilhada, da disponibilidade sem estrangulamento a uma saída que funciona, passando por uma resposta a «quem entrou», decorre de não distribuir o segredo. A mecânica para lá chegar está em partilhar códigos TOTP sem partilhar o segredo.

Se já foi partilhado

A maioria das equipas que lê isto já partilhou um segredo nalgum sítio. A pergunta útil não é saber se foi um erro, mas que contas merecem o trabalho de uma reposição.

1. Decida o que repõe

Reponha as contas onde um antigo detentor do segredo poderia fazer estragos verdadeiros: tudo o que toca no dinheiro, nos domínios, nos dados de clientes, nos direitos de publicação ou na infraestrutura cloud. Para uma conta sem importância cuja palavra-passe pode mudar e cuja lista de acesso é curta, mudar a palavra-passe e apertar a partilha pode ser proporcionado. O que conta é decidir deliberadamente; decidir por inércia é o que deixa uma conta de pagamentos exposta durante dois anos.

2. Reponha por esta ordem

A ordem conta, porque dois destes passos podem trancá-lo do lado de fora se os fizer primeiro.

1. Certifique-se de que tem códigos de recuperação atualizados, ou de que os consegue obter, antes de mexer em seja o que for.
2. Desative a 2FA na conta. Todas as cópias existentes do segredo morrem aqui.
3. Volte a ativá-la, e ponha o novo segredo em exatamente um sítio.
4. Conceda o acesso às pessoas que precisam dos códigos, sem distribuir o novo segredo.
5. Regenere e arrume os códigos de recuperação, fora da conta que eles recuperam.

3. Depois limpe o que a reposição não tocou

É o passo que se salta. Repor o segundo fator em geral não põe fim a nada do que já está em curso:

• Encerre a sessão em todos os aparelhos e em todas as sessões. Um atacante com uma sessão viva não precisa de códigos.
• Mude a palavra-passe, já que as duas credenciais em geral viajaram juntas.
• Passe em revista as chaves de API, os tokens e as aplicações ligadas. Autenticam-se sem o segundo fator por conceção, e sobrevivem à sua reposição.
• Veja o histórico de acessos e de início de sessão da conta, à procura do que venha de um período ou de um lugar que não deveriam existir.

4. Anote onde vive o novo segredo

Uma linha por conta: onde está o segredo, quem o administra, onde estão os códigos de recuperação. É a ausência dessa nota que torna as equipas relutantes em repor seja o que for, porque ninguém tem a certeza do que vai partir.

Onde um segredo deve viver

Num só sítio, alcançável por pelo menos dois administradores, separado dos códigos de recuperação, e separado da conta que protege. Que seja uma entrada restrita do seu gestor de palavras-passe ou uma ferramenta feita para isso importa menos do que a parte do «um só».

A Share Auth é uma resposta: o segredo é introduzido uma vez, cifrado em repouso, e nunca mais mostrado. Os membros veem códigos e contagens decrescentes, o acesso é concedido por pessoa e por conta, e cada consulta fica registada. O que elimina é a razão pela qual as equipas distribuem segredos à partida, ou seja, que a pessoa que tem o telemóvel nem sempre está disponível.

Em resumo

• Um segredo TOTP é permanente, simétrico e irrevogável tomado isoladamente.
• Partilhá-lo custa-lhe a contagem, a revogação, a independência dos fatores e a atribuição.
• As cópias multiplicam-se pelas cópias de segurança, pela sincronização, pelas exportações e pelos históricos de conversa, sem que ninguém faça nada de mal.
• Se foi partilhado, decida conta a conta, reponha por ordem, e limpe as sessões e os tokens que a reposição deixa atrás de si.
• Depois guarde exatamente uma cópia, e dê antes às pessoas acesso aos códigos.