Aprovar o ato, e não só a pessoa: o que um login forte não prova num pagamento

Um cliente entra no aplicativo com uma credencial forte, numa sessão legítima, e prepara um pagamento a um fornecedor conhecido. Entre a tela e o servidor, algo troca a conta de destino: um código malicioso na página, ou um golpista que, numa ligação, pede ao cliente para "confirmar a operação de segurança". O servidor recebe uma confirmação válida, do titular de verdade, para um ato que o titular nunca viu.

A pessoa certa aprovou. O que falhou foi a ligação entre a aprovação e o conteúdo do ato. Este guia trata dessa ligação: onde a autenticação para, como a regra europeia amarra valor e beneficiário ao código, e como dois padrões abertos levam o ato para dentro da assinatura. Serve a quem desenha fluxo de pagamento ou qualquer autorização de valor.

O que a autenticação prova, e onde ela para

A NIST SP 800-63B-4, diretriz de autenticação do NIST (o instituto de padrões dos Estados Unidos), define no resumo o seu objeto, voltado a sistemas do governo americano: estabelecer que quem se apresenta é um assinante previamente autenticado. É uma pergunta sobre a pessoa e a sessão, e as proteções mais fortes da norma seguem esse recorte. A seção 3.2.5, de resistência a phishing, reconhece dois métodos. Na vinculação ao canal (3.2.5.1), a saída do autenticador fica amarrada ao identificador do canal protegido. Na vinculação ao nome do verificador (3.2.5.2), ela fica amarrada à identidade autenticada do site, e a norma cita o WebAuthn, padrão por trás das passkeys, como exemplo.

Nenhum desses mecanismos, na forma descrita pela norma, amarra valor e destinatário à resposta: eles garantem que ela vale para aquele canal ou aquele site. Se o pagamento muda dentro da sessão autenticada, a autenticação continua válida. A passkey no cadastro tem outro limite, o de identidade civil, e a tomada de conta mostra por que a sessão legítima é onde o atacante quer estar.

A regra europeia: o código vale para um valor e um beneficiário

O Regulamento Delegado (UE) 2018/389 da Comissão, de normas técnicas de autenticação forte que complementa a Diretiva (UE) 2015/2366, chama essa amarração, na versão portuguesa oficial, de "ligação dinâmica". O artigo 5º, n.º 1, vale para os prestadores de serviços de pagamento que aplicam a autenticação forte nos termos do artigo 97.º, n.º 2, da diretiva, e exige quatro condições:

• o ordenante toma conhecimento do montante e do beneficiário;
• o código de autenticação gerado é específico do montante e do beneficiário aceitos pelo ordenante;
• o código aceito pelo prestador corresponde ao montante inicial e à identidade do beneficiário aceitos;
• qualquer alteração do montante ou do beneficiário invalida o código.

O n.º 2 vai além do código: exige confidencialidade, autenticidade e integridade do montante e do beneficiário em todas as fases da autenticação, e também das informações mostradas ao ordenante. Não basta assinar o dado certo; a tela precisa mostrar o mesmo dado. No lote de pagamentos remotos, diz o n.º 3, o código fica específico do montante total e dos beneficiários indicados.

O regulamento se aplica desde 14 de setembro de 2019. Em consulta ao EUR-Lex em 28 de setembro de 2026, constava em vigor, sem data de fim, e as alterações registradas tocam outros artigos: o 5º segue com a redação original.

Como a web e as carteiras levam o ato para dentro da assinatura

A especificação Secure Payment Confirmation (SPC), do grupo de pagamentos web do W3C, parte do mesmo diagnóstico. Na seção 1.1.1, ela observa que, com o WebAuthn puro, o dado do pagamento teria de ir no campo de desafio, o que os autores tratam como mau uso de um campo feito contra repetição, e que nada define como esse conteúdo é mostrado à pessoa. A seção 4.10.1 obriga o navegador a comunicar à pessoa o valor total com a moeda, o instrumento de pagamento e, quando informados, o nome e a origem do recebedor, e a colher o consentimento dela. Esses dados entram no registro assinado pelo autenticador, e a seção 9.1 obriga quem valida a conferir se o valor, o recebedor e o instrumento assinados batem com o que deveria ter sido mostrado.

A seção 11.2 traz um alerta prático: quando é o comerciante quem chama a SPC, é ele, e não o banco, quem fornece os dados exibidos, e ele pode dizer ao banco que a compra é de 100 e passar 1 para a tela. A defesa indicada é o banco conferir a asserção contra os dados da transação que recebeu. A assinatura só protege quem a compara com o ato que vai executar. Para citar direito: a SPC é Candidate Recommendation Draft, de 2 de julho de 2026, e pede para ser citada como trabalho em andamento.

Nas credenciais digitais, a OpenID for Verifiable Presentations 1.0 (OpenID4VP), especificação final da OpenID Foundation publicada em 9 de julho de 2025, define o parâmetro opcional transaction_data. A seção 8.4 explica o objetivo: ligar a identificação da pessoa à autorização de um ato, como um pagamento, assinando os dados da transação com a mesma chave que prova a posse da credencial. A carteira que recebe o parâmetro precisa incluir na apresentação uma representação ou referência aos dados, e a que não o suporta precisa recusar o pedido, em vez de ignorá-lo. Os tipos de transação concretos ficam fora da especificação.

O que isso muda no desenho de uma aprovação

Na prática, para qualquer aprovação de valor:

• A tela mostra o ato. Valor, moeda e destinatário, lidos do registro do servidor. "Confirme que é você" não serve.
• O que se assina é o ato. Valor e destinatário entram no dado autenticado, por um formato próprio como o da SPC ou o transaction_data, e não num desafio improvisado.
• Quem executa compara. Antes de liquidar, o servidor confere se o que foi assinado é exatamente a ordem que vai sair. Divergência é recusa.
• Mudou o ato, vale nova aprovação. Trocar destino ou valor depois da confirmação invalida a confirmação, a mesma lógica do artigo 5º, n.º 1, alínea d, do regulamento europeu.
• Guarde o que foi mostrado. A própria SPC lembra que a regulação pode exigir evidência de que a pessoa viu e aceitou os dados do pagamento.

É o que decide o desfecho no golpe do falso fornecedor: a pessoa aprova de boa-fé, e o que mudou foi a conta.

No Brasil, a Resolução BCB (Banco Central do Brasil) 403/2024 incluiu no artigo 89 do Regulamento do Pix, com efeito desde 1º de novembro de 2024, a exigência de dispositivo cadastrado, e a Resolução BCB 457/2025 deu nova redação a parte dela. Hoje o § 6º exige que a iniciação de Pix, exceto as devoluções, e os processos de chave pedidos por cliente pessoa natural venham de dispositivo de acesso previamente cadastrado. O § 7º permite o aparelho não cadastrado em valor e condições definidos pelo Banco Central, e o § 8º limita a exigência a aparelho que nunca tenha iniciado um Pix. É um controle sobre de onde parte o pedido; amarrar valor e destinatário à aprovação é outra camada, e as duas se somam, como discute o texto sobre cadastro de dispositivos no Pix.

Perguntas frequentes

Passkey já garante que o cliente aprovou aquele pagamento?

Não por si só. Na NIST SP 800-63B-4, a passkey vincula a resposta ao site e prova a posse da credencial. O valor e o destinatário só ficam amarrados se entrarem no dado assinado e forem mostrados à pessoa.

A Secure Payment Confirmation já é padrão do W3C?

Ainda não. Ela é Candidate Recommendation Draft, etapa anterior à recomendação, e o W3C avisa que essa publicação não implica endosso dele nem dos membros.

Fontes citadas

• Regulamento Delegado (UE) 2018/389 da Comissão, de 27 de novembro de 2017, arts. 5º e 38, com a ficha de vigência, no EUR-Lex: eur-lex.europa.eu
• W3C, Secure Payment Confirmation, Candidate Recommendation Draft de 2 de julho de 2026, seções 1.1.1, 4.10.1, 9.1 e 11.2: w3.org
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, resumo e seções 3.2.5, 3.2.5.1 e 3.2.5.2: pages.nist.gov
• OpenID Foundation, OpenID for Verifiable Presentations 1.0, especificação final de 9 de julho de 2025, seções 5.1 e 8.4: openid.net
• Resolução BCB nº 403, de 22 de julho de 2024, art. 2º (art. 89, §§ 6º a 8º, do Regulamento do Pix) e art. 4º, na API de normativos do Banco Central: bcb.gov.br
• Resolução BCB nº 457/2025, publicada no DOU de 7 de março de 2025, art. 1º (nova redação do art. 89, §§ 6º, 7º e 9º, do Regulamento do Pix), na API de normativos do Banco Central: bcb.gov.br