Várias pessoas podem usar o mesmo TOTP?

Sim. O TOTP não tem qualquer noção de quantas pessoas detêm um segredo, e qualquer número de aparelhos que detenham o mesmo mostrará os mesmos seis dígitos no mesmo instante. O que corre mal não é a aritmética. São os dois inícios de sessão que se chocam nos mesmos trinta segundos, o relógio que desliza num telemóvel, e o facto de que depois nada consegue dizer quem entrou.

Nessa pergunta escondem-se duas perguntas diferentes

«Várias pessoas podem usar o mesmo TOTP» quer quase sempre dizer uma de duas coisas, e elas têm respostas opostas.

Várias pessoas a deter o mesmo segredo. O segredo é a credencial permanente: não expira, não está ligado a nenhum aparelho, e não há qualquer registo a anular. Cada detentor a mais é uma cópia incontável e irrevogável do segundo fator da conta.

Várias pessoas a ler o mesmo código. O código são seis dígitos que valem uns trinta segundos, bons para uma tentativa de início de sessão. Passar um a um colega não cede nada que sobreviva à conversa.

As duas coisas parecem «partilhar a 2FA», e é por isso que as equipas acabam por fazer a permanente quando só precisavam da temporária. Esse compromisso, e as saídas que tem, são o tema de como partilhar códigos 2FA em equipa com segurança. Este artigo fica na pergunta estreita: o que vai realmente observar quando mais de uma pessoa trabalhar a partir do mesmo TOTP.

O que acontece mesmo com dois aparelhos

Os códigos coincidem, desde que os relógios coincidam

Dois aparelhos com o mesmo segredo não estão sincronizados entre si de forma alguma. Não precisam: o código deriva do segredo e da hora atual, e mais nada entra no cálculo. Entradas idênticas, saída idêntica. A mecânica está no guia completo do TOTP em equipa; o ponto prático é que uma segunda inscrição é invisível para toda a gente, para si incluído.

Dois inícios de sessão na mesma janela: o segundo pode ser recusado

É o sintoma que manda as pessoas procurar uma configuração avariada. Duas pessoas entram no mesmo passo de trinta segundos, ambas a ler o código certo, e a segunda tentativa é rejeitada.

A RFC 6238 pede aos verificadores que aceitem um dado código apenas uma vez por passo de tempo, e a maioria das implementações cumpre isso guardando o último passo usado numa conta. Do ponto de vista da conta há um só utilizador: o segundo início de sessão parece, portanto, a repetição de um código já gasto.

O remédio é esperar pelo código seguinte. Vale a pena sabê-lo de antemão, porque a reação natural, supor que se enganou a escrever e voltar a digitar o código, agrava o problema seguinte.

As novas tentativas acumulam-se contra o limite do fornecedor

Seis dígitos são um milhão de possibilidades: os fornecedores limitam por isso as tentativas. Esse limite conta por conta, não por pessoa.

Três pessoas a tentar duas vezes cada uma produziram seis falhas numa única conta, o que pode bastar para desencadear um bloqueio temporário, uma verificação adicional ou um email de segurança para quem detém o endereço registado. Cada comportamento individual é razoável; o agregado parece um ataque.

Um relógio desliza e só uma pessoa dá por isso

O desvio de relógio costuma ser descrito como uma avaria que atinge toda a conta, mas com vários aparelhos apresenta-se de outra forma: os códigos funcionam para toda a gente exceto para uma pessoa, sistematicamente, e apenas a partir do aparelho dela.

O telemóvel dessa pessoa calcula os códigos de um passo de tempo que o servidor já ultrapassou ou ainda não alcançou. O segredo não tem nada de anormal, e voltar a introduzi-lo não ajuda. O que é preciso verificar é o acerto automático da hora, no aparelho que falha.

Inícios de sessão simultâneos de vários sítios parecem uma intrusão

A deteção de abusos, do lado do fornecedor, reage a padrões, e uma conta que se autentica a partir de duas cidades em poucos minutos é exatamente o padrão que ela foi feita para detetar. Consoante o serviço, isso produz um passo de verificação adicional, um email de «novo aparelho», uma reposição forçada da palavra-passe, ou uma sessão que termina a meio de uma tarefa.

Nada disto é um problema do TOTP, e nada se resolve com configurações do seu lado. É simplesmente o aspeto que um identificador partilhado tem visto de fora, e torna-se mais frequente à medida que o número de utilizadores aumenta.

Nada regista que aparelho produziu o código aceite

O verificador compara seis dígitos. Não fica a saber de onde vêm, porque no código não há nada a saber, e porque inscrever um aparelho não enviou nada para lado nenhum logo de início.

Por isso, quando o registo da conta mostra um início de sessão às 14h12, a pista para aí. Se quatro pessoas conseguem produzir códigos, quatro pessoas podem ter entrado, e a conta não consegue reduzir mais. É a parte que conta depois de um incidente, e é a razão pela qual dar aos colaboradores acesso à 2FA sem lhes dar o segredo trata a atribuição como uma exigência e não como um extra simpático.

Portanto «sim, tecnicamente», a que preço

Tudo o que precede é atrito: irritante, diagnosticável, ultrapassável. O custo de várias pessoas deterem o segredo pertence a outra categoria, e não produz sintoma nenhum.

Não consegue contar as cópias. Nada nas definições de segurança da conta dirá alguma vez quantos aparelhos foram inscritos: o número vale o que valer a sua memória das inscrições passadas.

Não consegue retirar uma. O protocolo não prevê qualquer rotação nem qualquer registo por aparelho, o que quer dizer que a única revogação disponível consiste em desativar a 2FA na conta e voltar a configurá-la, para toda a gente ao mesmo tempo.

E o segundo fator deixa de ser independente onde quer que o segredo acabe ao lado da palavra-passe: uma nota partilhada, uma entrada de cofre, um documento. Um único sítio alcançado, e os dois fatores estão perdidos. Como funcionam os segredos TOTP (e porque não se devem partilhar) passa em revista os sítios onde as cópias se acumulam. Em resumo: acumulam-se em silêncio, e ficam.

O que a pergunta pede na verdade

O que as pessoas querem ao fazê-la é que vários colegas possam entrar numa mesma conta. Isso não exige que várias pessoas detenham o segredo. Exige três coisas.

Um único detentor do segredo. Introduzido uma vez, pela pessoa que administra a conta, guardado num só sítio conhecido a que pelo menos dois administradores chegam. Todos os outros participantes consomem códigos em vez de armazenar seja o que for.

Códigos distribuídos por pessoa. Cada pessoa autorizada obtém o código atual e a sua contagem decrescente quando precisa dele, concedido conta a conta, e retirável numa ação. O aparelho de ninguém detém o que quer que sobreviva ao seu acesso.

Um rasto das consultas. Uma vez que o registo do fornecedor nunca poderá mostrar mais do que a conta partilhada, o registo de quem pediu um código é a única coisa que põe um nome à frente de uma marca temporal.

Se a plataforma em causa puder dar a cada colega o seu próprio identificador, faça-o, é melhor do que partilhar seja o que for, e a 2FA de uma conta partilhada: como deve uma equipa lidar com ela? detalha que contas não têm mesmo nenhuma opção por pessoa. As três exigências acima valem para as que têm realmente um só identificador.

Onde se coloca a Share Auth

A Share Auth foi feita para este caso. O segredo é introduzido uma vez e cifrado em repouso; os membros convidados veem o código e a sua contagem decrescente, nunca o segredo por trás. As permissões regulam-se por membro e por conta, cada consulta de um código é escrita num registo de acessos, e retirar um membro retira-lhe o acesso em todo o lado numa ação. Os scripts que precisam de iniciar sessão podem pedir os códigos pela API em vez de envolver uma pessoa.

O plano gratuito cobre três segredos e três membros, sem cartão bancário, o que chega para ver se a forma descrita acima corresponde à maneira como a sua equipa trabalha na realidade.