MFA · ProofFlow

Não aprove «alguém a entrar». Aprove esta operação.

O ProofFlow é a MFA do AuthGuard para o que importa. A confirmação fica ligada à operação exata que a pessoa vê, com passkey ou no telemóvel com o código de comparação, é decidida uma única vez e fica num recibo assinado que se verifica offline. Para o dia a dia, passkeys, telemóvel, TOTP e HOTP chegam ao browser, ao Windows e à VPN.

Ver o ProofFlow numa demonstração Ver como funciona

Pedido canónico · SHA-256
Código de comparação
Decidida uma vez
Recibo assinado

ProofFlow · pedidoexemplo ilustrativo

Operação: Pagar fatura INV-42
Montante: 1 250,00 €
Destino: PT50 •••• •••• 4417
Pedido por: ERP Financeiro
Digest SHA-256: 9f3c 51a0 … 7be2 e21a

Código de comparação 205 731 o mesmo código no ecrã e no telemóvel

Recibo assinadoML-DSA-65 (+ Ed25519 em modo híbrido) · verificável offline

Pedido canónico
Código conferido
Decidida uma vez
Recibo assinado

Em vídeo

Aprove esta operação.

Locução em inglês, com legendas em português e em inglês. Ecrãs reais do produto; pessoas, organizações e montantes são fictícios.

ProofFlow · como funciona

A prova fica presa à operação.

Uma tecnologia própria do AuthGuard, usada na consola, na entrada em aplicações, no acesso privilegiado e nos pedidos de outros sistemas.

01 · Pedido canónico
Fixe o que vai ser aprovado

O servidor escreve o pedido numa forma canónica, com a operação, os campos e o prazo. Um digest SHA-256 cobre o pedido inteiro.
02 · Código de comparação
O mesmo código nos dois ecrãs

Os seis dígitos são derivados do digest. No telemóvel, a pessoa escreve o código que o ecrã mostra; três códigos errados recusam o pedido. Se o pedido for trocado, os códigos deixam de coincidir.
03 · Confirmação
Passkey ou telemóvel

A passkey assina aquele digest e só aquele. A aprovação no telemóvel é confirmada com biometria ou PIN.
04 · Uma vez, com recibo
Decidida uma vez, provada para sempre

Na consola, a autorização expira em dois minutos e é consumida uma só vez, com a política reavaliada nesse momento. A decisão fica num recibo assinado com ML-DSA-65, mais Ed25519 em modo híbrido.

MFA comum vs ProofFlow

Aprovar uma entrada não é aprovar uma operação.

O padrão genérico de MFA por notificação confirma que alguém está a entrar. O ProofFlow confirma o que vai ser feito, e deixa prova.

Critério	MFA comum (notificação push)	ProofFlow
O que a pessoa vê	Um aviso de que alguém está a entrar, por vezes com a aplicação e a localização.	A operação. Na consola, todos os campos: montante, destino, referência. No telemóvel, a operação, quem a pediu e a referência.
A que fica ligada a aprovação	À sessão que está a entrar.	Ao pedido canónico e ao seu digest SHA-256. Uma confirmação dada a outro pedido não serve.
Phishing e aprovação por cansaço	Um sim/não simples pode ser aceite por cansaço; a correspondência de números reduz esse risco.	Com passkey, resiste a phishing. No telemóvel, a pessoa escreve o código de seis dígitos do ecrã e três erros recusam o pedido.
A prova depois	Em regra, um registo de entrada no fornecedor.	Um recibo assinado com ML-DSA-65 (e Ed25519 em modo híbrido), que se verifica fora do serviço com as chaves públicas da instalação.
Onde se usa	Sobretudo na entrada.	Entrada em aplicações, pagamentos, alterações de acesso, ações administrativas e pedidos de outros sistemas pela API de intents.

Comparação com o padrão genérico de MFA por notificação; cada produto implementa-o à sua maneira.

Exemplo ilustrativo

Uma pessoa, várias portas, a mesma app.

A Marta liga o portátil Windows: escreve a palavra-passe e, no telemóvel, o número que o ecrã mostra. A meio da manhã liga a VPN e aprova o pedido Ligar à VPN Lisboa.

À tarde, o ERP pede-lhe que aprove o pagamento da fatura INV-42. Ela confere o montante e o destino na consola, confirma com a passkey e o ERP recebe um recibo assinado antes de pagar.

Os outros fatores

O fator certo em cada porta.

ProofFlow

Ações críticas

A pessoa vê a operação e os seus valores
Passkey ou telemóvel com código
Recibo assinado, verificável fora do serviço

Ver detalhe: Ações críticas

Passkeys

Resistentes a phishing

Windows Hello, telemóvel ou chave FIDO2 com PIN
A política pode exigir passkey por aplicação
Duas passkeys por pessoa recomendadas

Ver detalhe: Passkeys

Telemóvel

Aprovação com código de comparação

App de aprovação para Android 14 ou posterior
Código escrito ou comparado, conforme o pedido
Três códigos errados recusam o pedido
Ligação ao telemóvel por código QR

Códigos

TOTP, HOTP e recuperação

Aplicações autenticadoras TOTP
Tokens HOTP e OCRA
Códigos de recuperação e ligação por email
Sem SMS nem chamadas de voz

Windows

Entrada, desbloqueio e remoto

Número no ecrã, aprovado no telemóvel
Modo sem ligação com códigos por computador
Distribuição por GPO ou Intune

Ver detalhe: Windows

VPN e Wi-Fi

RADIUS e RadSec

Código ou aprovação no telemóvel
Recusas iguais para qualquer erro
Cada decisão na auditoria

Ver detalhe: VPN e Wi-Fi

O que convém saber

A aprovação no telemóvel existe só para Android 14 ou posterior. No iPhone, use passkey.
No modo de comparação, em que a pessoa só confirma que o código é igual, não há proteção contra aprovações por cansaço. Use-o apenas quando a pessoa não consegue ver o código.
Nos pedidos de outros sistemas, o sistema que pede tem de mostrar o código de comparação, e é ele que executa a operação depois de verificar o recibo.
Não há códigos por SMS nem por chamada de voz.
A aprovação no telemóvel não funciona nos domínios personalizados de uma organização; aí, use passkey.
Só a passkey resiste a phishing. A aprovação no telemóvel com código é multifator, mas não trava um site que retransmite em tempo real.

No centro de ajuda

Piloto

Escolha uma operação crítica.

Um pagamento, uma alteração de acessos ou uma tarefa administrativa com ProofFlow, e passkeys ou telemóvel para o resto da equipa. Definimos consigo a política e o caminho de recuperação.

geral@authguard.pt