Partilhar códigos TOTP sem partilhar o segredo

O segredo e a hora atual são as únicas entradas de um código TOTP: não se pode, portanto, calcular um sem o segredo. O truque não é partilhar o segredo de outra maneira, é fazer com que o aparelho de cada um deixe de precisar dele: alguma coisa detém o segredo e distribui os códigos a pedido. Essa distinção é todo o assunto de como partilhar códigos 2FA em equipa com segurança; este artigo fala de mecânica.

Porque a diferença conta tanto

Um código vale uns trinta segundos. Enviá-lo a um colega é mais ou menos tão sensível quanto ler um número de seguimento de uma encomenda: quando fugir já está inválido, e teria de qualquer forma servido apenas para uma tentativa de início de sessão.

Um segredo vale tudo o que a conta vale, enquanto a 2FA continuar configurada. Costuma ter 16 a 32 carateres, é o que o código QR contém, e as suas cópias são invisíveis: nada na página de segurança da conta lhe dirá alguma vez que quatro pessoas leram o ecrã de configuração em 2024.

É essa assimetria que faz com que «partilhamos os códigos» e «partilhámos o código QR uma vez» descrevam duas posturas de segurança completamente diferentes, mesmo que ambas se pareçam com partilhar 2FA.

Três formas de distribuir códigos, não segredos

Um cofre partilhado que mostra os códigos

O segredo é introduzido uma vez, pela pessoa que administra a conta, e guardado cifrado. Os colegas a quem foi dado acesso abrem a entrada e veem o código atual com a sua contagem decrescente. Nunca veem a cadeia por trás, e não conseguem inscrever a sua própria aplicação a partir daí.

É a resposta polivalente, e a que sobrevive às entradas e às saídas, porque o acesso é uma lista que se altera em vez de um segredo que não se pode chamar de volta.

Sob a forma de produto, é uma aplicação de autenticação partilhada: o cofre detém o segredo, as pessoas não detêm nada.

Uma chamada de API a partir das suas próprias ferramentas

Se o início de sessão for feito por um script, uma exportação noturna, um job de CI ou um robô que publica numa conta de cliente, o código não precisa de chegar a um humano. As suas ferramentas pedem o código atual no momento de entrar, e o segredo fica do lado do servidor.

A regra: o identificador que o seu script usa para pedir o código deve estar tão protegido como a própria conta, e limitado à única conta de que precisa.

Lê-lo em voz alta, deliberadamente

Alguém com acesso lê o código a um colega ao telefone. Merece ser nomeado, porque é o que a maioria das equipas já faz, e porque não está errado. Partilha-se exatamente a coisa efémera, e mais nada.

Os seus limites são práticos e não criptográficos: são precisas duas pessoas acordadas ao mesmo tempo, não deixa qualquer rasto de quem entrou, e faz de uma pessoa o estrangulamento de todas as outras.

O que se perde ao partilhar o segredo em vez disso

Se o segredo sair, colado num canal, capturado em imagem ou depositado numa nota partilhada, três coisas tornam-se verdadeiras de uma vez, e assim ficam até à reposição da 2FA:

• Perde-se a contagem. Impossível saber quantos aparelhos o detêm.
• Perde-se a revogação. Retirar alguém de um canal não retira o segredo da sua aplicação de autenticação.
• Perde-se a independência do segundo fator. Onde quer que o segredo esteja ao lado da palavra-passe, um atacante que chegue a esse sítio tem os dois fatores.

Nada disto é teórico, e nada aparece numa auditoria da própria conta. Vê-se meses depois, quando alguém que saiu da empresa continua a dispor de um gerador de códigos funcional.

Uma lista de verificação curta

• O segredo é introduzido uma vez, num só sítio, por um administrador da conta.
• Todos os outros têm acesso aos códigos, concedido pessoa a pessoa e conta a conta.
• As consultas são registadas, para que «quem entrou na terça-feira» tenha resposta.
• Os códigos de recuperação são guardados com o segredo, não distribuídos com ele.
• Qualquer segredo que tenha sido publicado nalgum sítio é considerado queimado: repor a 2FA nessa conta e reinscrever.