Implementando Autenticação com Chave de Segurança de Hardware

Quando Usar

• Implementando autenticação multifator (MFA) resistente a phishing usando chaves de segurança de hardware FIDO2 para contas de alto valor (administradores, desenvolvedores, usuários privilegiados)
• Construindo um servidor de parte confiável (relying party) WebAuthn que suporte tanto autenticadores itinerantes (chaves de segurança USB/NFC) quanto autenticadores de plataforma (Windows Hello, Touch ID, biometria Android)
• Migrando um sistema de autenticação existente baseado em senha para suportar senhas (credenciais detectáveis) como um fator de autenticação primário ou secundário
• Registrando dispositivos YubiKey para a força de trabalho de uma organização, incluindo configuração de PIN, registro de credenciais e provisionamento de chaves de backup
• Implementando fluxos de autenticação sem senha que estejam em conformidade com os requisitos NIST SP 800-63B AAL3 (nível de garantia do autenticador 3)

Não use sem HTTPS em produção (WebAuthn requer uma origem segura), para sistemas onde os usuários não podem acessar fisicamente uma porta USB/NFC, ou como o único fator de autenticação sem um mecanismo de recuperação para chaves perdidas.

Pré-requisitos

• Python 3.10+ com fido2 (python-fido2 >= 2.0.0), flask e cryptography bibliotecas instaladas
• Servidor web com HTTPS ativado (API WebAuthn requer contexto seguro; localhost é isento para desenvolvimento)
• Chave de segurança de hardware compatível com FIDO2 (YubiKey Série 5, SoloKeys, Titan Security Key) ou autenticador de plataforma
• Navegador web moderno que suporte a API WebAuthn (Chrome 67+, Firefox 60+, Safari 14+, Edge 79+)
• Compreensão de criptografia de chave pública, protocolos de desafio-resposta e gerenciamento de sessão HTTP

Fluxo de Trabalho

Etapa 1: Configuração do Servidor da Parte Confiável

Configure a identidade e o servidor da parte confiável (RP) WebAuthn:

• Definir identidade da RP: Crie uma PublicKeyCredentialRpEntity com o nome da parte confiável (nome de exibição mostrado aos usuários) e o ID da RP (o domínio efetivo do aplicativo). O ID da RP deve ser um sufixo de domínio registrável da origem -- por exemplo, example.com é válido para https://auth.example.com, mas other.com não é.
• Inicializar Fido2Server: Instancie a classe Fido2Server da biblioteca python-fido2 com a entidade RP. O servidor lida com a geração de desafios, verificação de atestado e validação de asserção.
• Configurar preferência de atestado: Defina a preferência de transporte de atestado para controlar se o servidor solicita prova da identidade do autenticador:
  • none: Nenhum atestado solicitado (mais simples, recomendado para a maioria das implementações)
  • indirect: O atestado pode ser fornecido, mas a CA pode anonimizá-lo
  • direct: Cadeia completa de atestado do fabricante do autenticador
  • enterprise: Atestado que identifica o dispositivo para ambientes gerenciados
• Gerenciamento de sessão: Configure sessões do lado do servidor para armazenar o estado WebAuthn entre as fases de início e conclusão das cerimônias de registro/autenticação. Use cookies seguros, httponly com SameSite=Strict.
• Armazenamento de credenciais: Projete o esquema do banco de dados para armazenar registros de credenciais: credential_id (binário), public_key (chave COSE), sign_count (uint32 para detecção de clone), user_id, created_at, last_used, display_name e transports (USB, NFC, BLE, interno).

Etapa 2: Cerimônia de Registro (Criação de Credencial)

Implemente o fluxo de registro WebAuthn para criar novas credenciais:

• Iniciar registro: Chame server.register_begin() com a entidade do usuário (PublicKeyCredentialUserEntity contendo ID do usuário, nome de usuário e nome de exibição), a lista de credenciais existentes para o usuário (para evitar registro duplicado) e opções para user_verification e authenticator_attachment.
• Critérios de seleção do autenticador:
  • authenticator_attachment: cross-platform restringe a autenticadores itinerantes (chaves USB/NFC)
  • authenticator_attachment: platform restringe a autenticadores integrados (Touch ID, Windows Hello)
  • Omitir este campo permite ambos os tipos
  • resident_key: required força a criação de uma credencial detectável (senha) armazenada no autenticador
  • user_verification: required impõe PIN ou verificação biométrica no autenticador
• Cerimônia do lado do cliente: O navegador chama navigator.credentials.create() com as opções do servidor. O autenticador gera um novo par de chaves, armazena a chave privada em seu elemento seguro e retorna a chave pública, o ID da credencial, o objeto de atestado e o JSON dos dados do cliente.

…