Resumo

  • Nos ataques da RFC 10027, o usuário é autenticado de verdade, mas aprova um fluxo iniciado no dispositivo do invasor. O elo ausente é a prova de que o pedido visto no telefone pertence ao equipamento que o usuário pretende habilitar.
  • QR code, código de usuário ou notificação podem ser válidos e ainda circular por um canal de contexto não autenticado. Validade não prova apresentação, intenção, proximidade nem destino do token.
  • Daniel Fett escreveu a BCP com Pieter Kasselman e Filip Skokan. O documento combina escolha de protocolo, proximidade, confiança de dispositivo, escopo limitado, detecção e recuperação, sempre registrando os limites de cada controle.

Fluxos entre dispositivos resolvem um problema real. Uma televisão, um quiosque ou uma lousa digital pode ter teclado ruim, enquanto o celular já guarda credenciais e fatores fortes. O primeiro equipamento mostra um código; o segundo autentica a pessoa e devolve a autorização.

A aparência de continuidade esconde duas decisões. O dispositivo de consumo inicia e recebe a capacidade. O dispositivo de autorização identifica o usuário e coleta o consentimento. Entre eles, um QR code, um código curto ou uma notificação transporta a referência da transação — muitas vezes sem autenticar o contexto em que essa referência chegou ao usuário.

É nessa fresta que atua o invasor descrito pela RFC 10027. Ele abre o fluxo no próprio computador, obtém um código oficial e o envia à vítima com uma narrativa convincente. A pessoa escaneia, entra no provedor de identidade verdadeiro, conclui a MFA e aceita. O servidor sabe quem ela é. Pode não saber diante de qual tela ela acredita estar.

A autenticação cumpriu sua função estreita

Dizer que a MFA foi burlada confunde identidade com autorização. Os fatores podem ter confirmado corretamente o titular da conta. O sistema falhou em ligar essa identidade ao iniciador correto, à finalidade compreendida e ao cliente que receberá o resultado.

Na modalidade chamada Cross-Device Consent Phishing, o usuário concede acesso ao cliente do invasor. No Cross-Device Session Phishing, entrega um artefato capaz de mover uma sessão já autenticada. A recompensa pode ser um token de acesso, um token de atualização ou uma sessão pronta para uso. Trocar a senha não necessariamente elimina nenhum deles.

O código ainda prova alguma coisa. Pode demonstrar que o servidor criou uma operação pendente, que o formato está correto e que o prazo não terminou. Não demonstra por si só quem o apresentou, se o usuário esperava aquela tarefa, se os dispositivos estão próximos, se o escopo é necessário ou se o beneficiário é a tela à sua frente. Um dado autêntico pode sustentar um enredo fraudulento.

A contribuição de Daniel Fett é uma disciplina de escopo

Em seu site, Fett se define como consultor de segurança especializado em identidade e protocolos web, com atuação em OAuth e OpenID Connect na OpenID Foundation e no IETF. Seu registro no IETF inclui trabalhos sobre identificação do emissor, prova de posse e segurança OAuth. A RFC 10027 tem três autores; essa trajetória não o torna dono isolado do texto nem operador de qualquer sistema.

Ela ajuda, porém, a entender a forma correta de formular a prova. A análise formal consegue excluir ataques dentro das camadas, capacidades do adversário e objetivos definidos pelo modelo. Não certifica detalhes abstraídos nem erros de implementação. Uma etapa criptográfica bem-sucedida não pode falar por uma relação que não foi modelada.

“Autenticado” precisa de complemento: quem, perante quem e para qual transação? Identidade do usuário, dispositivo iniciador, contexto, intenção, concessão, destinatário do token e acesso ao recurso são fatos separados. O servidor pode ser legítimo e o pedido pertencer ao invasor. Um token pode estar ligado a uma chave, e essa chave ser justamente a do equipamento hostil.

Defesas em camadas, sem selo absoluto

Códigos curtos, únicos e de uso limitado reduzem repetição e escala. Um invasor interativo pode esperar a resposta da vítima antes de criar o código. Limites de taxa atrapalham campanhas, não uma abordagem paciente. Educação ajuda, mas um fluxo malicioso que reutiliza interfaces verdadeiras pode ser quase indistinguível do cotidiano.

Proximidade por BLE, NFC, UWB, rede compartilhada ou localização torna a substituição remota mais difícil. VPN, posição simulada, NAT, dados móveis e aprovações remotas legítimas impedem transformar essa sinalização em prova de intenção. O servidor valida observações; não enxerga diretamente a distância física.

Restringir a iniciação a equipamentos gerenciados e redes confiáveis diminui quem consegue obter códigos. Essa confiança exige cadastro, atestação, correções e revogação. Um dispositivo confiável comprometido continua perigoso. Escopos e tokens curtos reduzem o dano posterior. Tokens vinculados ao emissor dificultam exportação e revenda, mas não impedem o cliente do invasor de usar a própria chave.

Por isso a RFC trata protocolo como escolha de risco. FIDO é recomendado quando origem e proximidade podem ser ligadas por recursos compatíveis. CIBA pode ser melhor quando o servidor já possui um canal com o usuário, desde que solicitações inesperadas sejam controladas. O OAuth Device Authorization Grant funciona no menor denominador de hardware; deve ser reservado aos casos em que alternativas mais fortes não são viáveis e evitado para recursos sensíveis ou críticos sem mitigações adicionais.

A evidência que começa depois do “autorizar”

A ideia de Running-Code Primacy de Heng Lu oferece um teste operacional: uma declaração na tela não é o resultado. O evento “aprovado” precisa ser unido ao equipamento que recebeu a capacidade e ao uso feito depois.

Um recibo defensável relaciona cliente iniciador e seu estado, dispositivo de autorização, método, contexto exibido nos dois lados, escopo, sinais de proximidade, decisão, destino e restrições dos tokens, primeiro uso, anomalias, revogação e recuperação. Privacidade exige minimização e acesso controlado. Responsabilidade exige algo mais preciso que um ícone verde.

Os donos dos controles também precisam aparecer. Produto decide se a conveniência justifica o fluxo. Identidade escolhe protocolo, cliente e permissões. Dispositivo e rede administram confiança. Antifraude observa iniciações e consentimentos anômalos. Servidores de recursos aplicam restrições. Suporte e resposta removem concessões e confirmam a recuperação. Não é razoável pedir ao usuário que autentique sozinho um canal que o sistema decidiu não autenticar.

O ensinamento de Fett e seus coautores não é demonizar o QR code. É impedir que uma transferência visível seja promovida, sem prova, a uma relação confiável.

Fontes