Ações críticas: por que algumas operações pedem seus dois dispositivos de novo

·6 min de leitura·Por SSP Editorial Team
Capa da SSP Academy: ações críticas e reassinatura na SSP Enterprise

Ações críticas: por que algumas operações pedem seus dois dispositivos de novo

Você está logado. Você tem papel de admin. Você clica em "remover membro" — e a SSP pede que assine com os seus dois dispositivos, exatamente como se estivesse entrando do zero.

Isso não é atrito por atrito. É uma linha traçada de propósito entre operações que um token de sessão deveria poder autorizar e as que não deveria, e o raciocínio por trás dessa linha vale ser entendido, você usando a SSP ou não.

Sessões servem à conveniência, não às consequências

Um token de sessão é uma credencial ao portador. Quem o tiver é você, no que diz respeito ao servidor. É exatamente isso que torna sessões convenientes — você se autentica uma vez e depois age livremente — e exatamente isso que as torna base ruim para decisões irreversíveis.

Sessões são roubadas. Por um bug de cross-site scripting, um notebook destravado, malware, um backup vazado, ou simplesmente um navegador deixado aberto num escritório compartilhado. O guia de gerenciamento de sessões da OWASP trata o roubo de sessão como condição esperada, não como caso extremo, e qualquer projeto que suponha o contrário é otimista.

Para a maioria das ações isso é risco aceitável, porque a maioria das ações é reversível. Renomear um cofre, adicionar um observador, ajustar uma preferência de notificação: se um atacante com sessão roubada faz isso, você desfaz.

Algumas ações não são assim. Transferir a propriedade de uma organização entrega o controle a outra pessoa. Remover um membro corta o acesso dele. Excluir uma organização é definitivo. Para essas, a SSP exige prova de que quem age ainda tem os dois dispositivos neste momento — não de que os tinha em algum instante mais cedo no dia.

As treze ações

Treze operações exigem assinar de novo. Elas se dividem em quatro grupos.

Controle da organização

  • Transferir a propriedade
  • Excluir a organização

Participação e papéis

  • Remover um membro
  • Promover um membro a admin
  • Rebaixar um admin

Identidade da conta

  • Mudar o e-mail empresarial
  • Remover o e-mail empresarial

Ciclo de vida e administração de cofres

  • Arquivar um cofre e desarquivá-lo
  • Congelar um cofre e descongelá-lo
  • Promover um admin de cofre e rebaixá-lo

O que as une não é moverem dinheiro — nenhuma move, e nenhuma pode, porque só signatários podem mover fundos. O que as une é que elas mudam quem poderá fazer coisas depois. São as operações que um atacante quereria para consolidar acesso, trancar os verdadeiros donos do lado de fora, ou preparar em silêncio um roubo posterior.

Repare que as ações ligadas a e-mail estão na lista. Mudar o e-mail empresarial de uma conta parece administrativo, mas é o clássico lance de abertura num sequestro de conta: redirecionar o canal de recuperação e depois trabalhar com calma. Exigir os dois dispositivos para isso fecha esse caminho.

Por que o servidor escreve o desafio

O mecanismo importa tanto quanto a exigência, e uma decisão de projeto faz quase todo o trabalho.

O servidor gera a mensagem que você assina. O cliente, nunca.

Uma ação crítica, passo a passo

Se o cliente compusesse o próprio desafio, um cliente comprometido poderia compor um conveniente: uma mensagem descrevendo uma ação inofensiva, assinada por alguém que acreditava fazer algo inofensivo, e então reproduzida contra um endpoint perigoso. Ter o servidor redigindo a mensagem significa que o que você assina é o que será executado, porque o servidor confere a assinatura contra a mensagem que ele emitiu e nenhuma outra.

É o mesmo padrão que a SSP usa no login, e o mesmo padrão que torna segura a autenticação por assinatura em geral: nunca assine algo que você não recebeu da parte que vai verificá-lo.

A que o desafio está vinculado

A mensagem não é um "sim" genérico. É uma string específica contendo quatro coisas que, juntas, tornam uma assinatura capturada inútil em qualquer outro lugar.

A ação exata. remove_member e transfer_ownership produzem mensagens diferentes. Uma assinatura para uma não pode autorizar a outra.

O alvo exato. A organização, o cofre quando cabível, e a pessoa alvo estão nomeados na mensagem. Ações com escopo de cofre incluem explicitamente o ID do cofre, para que uma assinatura para congelar um cofre não possa ser reproduzida para congelar outro.

Um carimbo de tempo. Ele ocupa os treze primeiros caracteres da mensagem — posição fixa, porque o SSP Wallet valida esse formato antes de exibir qualquer coisa. Desafios expiram em quinze minutos.

Um nonce aleatório. Doze bytes de aleatoriedade criptográfica, que tornam cada desafio único mesmo para uma ação idêntica contra um alvo idêntico no mesmo segundo.

E o desafio é de uso único. Quando é resgatado, o servidor o marca como usado na mesma operação atômica que o valida — então uma assinatura reproduzida é rejeitada com "já usado" em vez de vencer em silêncio duas vezes. Desafios expirados são limpos automaticamente por um índice TTL.

Toda tentativa fica registrada, inclusive as que falham

Ações críticas são gravadas num log permanente, e há aqui um detalhe fácil de passar batido: a entrada de log é escrita quando o desafio é solicitado, e não apenas quando a ação se conclui.

Isso quer dizer que o log inclui tentativas abandonadas, tentativas em que a assinatura falhou e tentativas recusadas. Uma única ação crítica malsucedida costuma ser alguém que mudou de ideia. Um punhado delas às 3 da manhã é uma história.

Como o resto da trilha de auditoria da SSP, esses registros não têm expiração nem rotina de limpeza. O valor de um log de auditoria vive inteiramente nas partes de que ninguém previu precisar.

Como isso é na prática

Tenha os dois dispositivos com você antes de começar. Ações críticas não se concluem com um dispositivo só, e o desafio expira em quinze minutos. Se o celular está em outro cômodo, vá buscá-lo primeiro.

Leia a ação no celular, não só no painel. A mensagem que seus dispositivos mostram nomeia a ação e o alvo. Essa é sua chance de notar que o alvo não é quem você esperava — o mesmo hábito que protege você ao revisar uma transação. Ataques de phishing mirando usuários de cripto explica por que essa segunda olhada no segundo dispositivo vale os segundos que custa.

Não agrupe. Cada ação crítica ganha o próprio desafio e a própria assinatura. Se você está removendo três funcionários que saem, são três assinaturas. Isso é deliberado: agrupar significaria uma assinatura autorizando várias mudanças, que é exatamente a propriedade que queremos evitar.

Espere por elas nos piores momentos. Ações críticas se concentram justamente quando alguém está saindo, uma conta foi comprometida ou um cofre precisa ser congelado — ou seja, nos momentos em que as pessoas estão sob pressão e querem correr. Saber de antemão que elas exigem os dois dispositivos transforma uma surpresa num passo.

O quadro maior de o que impõe o quê — e por que a reassinatura fica na camada do meio e não na mais forte — está em o que de fato barra uma transação. Para como a organização e seus cofres se encaixam, comece por SSP Enterprise: cofres multisig para equipes.

Compartilhar este artigo

Artigos relacionados