APRENDER. PRATICAR. EVOLUIR.Ler os bytes que a assinatura protege
O exercício produz uma chave EC P-256 temporária e dados de asserção sintéticos. Os 37 bytes de authenticatorData usados no subconjunto incluem hash do RP ID, flags e contador. A mensagem assinada combina esses bytes com SHA-256 dos clientDataJSON originais. O OpenSSL executa a assinatura e a verificação ECDSA; a aplicação Python controla o contexto esperado e interpreta os resultados. Não existe um browser a chamar navigator.credentials, um autenticador a autorizar fisicamente a operação ou uma cerimónia de registo validada. Observa o caso em que o JSON é reformatado mantendo valores equivalentes. A representação binária muda e, por isso, muda o hash protegido. Verificar uma reconstrução em vez dos bytes recebidos pode quebrar o contrato criptográfico. O laboratório recusa essa versão com a assinatura antiga. A lição não é proibir formatação de todos os documentos; é identificar qual representação faz parte da mensagem autenticada. Os comandos e hashes de saída são registados, enquanto chaves e ficheiros temporários são removidos. Estes artefactos permitem repetir o mecanismo, mas não comprovam proteção física da chave, conformidade FIDO ou segurança de um produto completo.
Separar validade criptográfica de aceitação
Uma assinatura válida responde a uma pergunta sobre a mensagem e a chave. A aceitação exige ainda que essa mensagem corresponda à operação e à política. No exercício, o registo local liga registered-a à conta operator-a. Tentar usar essa credencial para operator-b falha antes da aceitação, mesmo sem qualquer problema matemático na assinatura. Um desafio diferente, uma origem não autorizada ou outro RP ID também invalidam o contexto pretendido. Não derives o titular da credencial de um campo de proprietário apresentado pelo cliente. Executa primeiro o exemplo legítimo e depois cada alteração isolada. Compara o motivo de rejeição e confirma que o controlo observado é o pretendido. O modelo suporta apenas UP e UV e rejeita formatos fora do subconjunto; não deve ser promovido a implementação completa de WebAuthn. Flags de backup, extensões, attestation e frames exigem trabalho adicional. Esta fronteira é relevante para um gestor técnico: um teste local pode sustentar a aceitação de uma correção específica sem sustentar uma declaração de prontidão de toda a solução. Regista o que foi executado, o que foi apenas lido e o que continua por ensaiar com componentes reais.
PKCE liga a troca do código ao pedido
No fluxo de código de autorização, PKCE acrescenta uma ligação entre o pedido inicial e a troca posterior. Com S256, o cliente mantém um code_verifier e envia um desafio derivado. O servidor que aceitou esse desafio tem de exigir correspondência na troca do código. Um verifier diferente não passa a ser legítimo porque o código ainda é recente ou porque o parâmetro tem o tamanho correto. A BCP atual também trata ataques de downgrade: a relação entre presença do desafio original e aceitação do verifier deve ser consistente. Num projeto de integração, inclui critérios sobre suporte efetivo do servidor, geração por transação, correlação com o cliente e comportamento perante parâmetros em falta. Evita concentrar toda a avaliação no ecrã de consentimento. Para clientes web com URI de redireção registado, a comparação exata limita destinos admissíveis; a exceção específica das portas localhost de aplicações nativas não autoriza correspondência genérica por prefixo. Estes mecanismos são complementares e têm papéis diferentes. O laboratório de assinaturas deste bloco não executa um authorization server nem uma troca OAuth: as perguntas e esta análise são baseadas nas normas consultadas, exigindo validação posterior na integração escolhida.
Finalidade dos tokens e privacidade da ligação
Um ID Token comunica ao cliente informação sobre autenticação; um access token serve o contrato de acesso a um recurso. Não uses a semelhança de formato ou o mesmo emissor como autorização para trocar um pelo outro. Uma API que exige um access token destinado a si não deve aceitar o ID Token do frontend apenas porque a assinatura verifica. Identifica, no desenho, quem é o destinatário de cada artefacto, que validação aplica e onde é tomada a decisão de autorização da operação de negócio. A identificação da pessoa entre serviços também precisa de um contrato. Identificadores pseudónimos pairwise podem ser deliberadamente diferentes entre RPs para limitar correlação. Uma migração que força igualdade por email pode desfazer essa propriedade ou criar ligações sem evidência suficiente. Define necessidade, autoridade, prova de vinculação e tratamento de alterações antes de reconciliar contas. O mesmo atributo apresentado em dois contextos não é uma autorização implícita para fundir dados. Em APS, a consequência prática é manter inventário de integrações e responsáveis pela ligação, com testes de separação entre contas e uma forma de corrigir associações erradas sem confundir identidade, sessão e permissões.
Produzir um registo verificável do ensaio
O relatório do laboratório conserva a versão de Python e OpenSSL, o hash do script, os comandos executados, os resultados esperados e observados e a limpeza dos artefactos temporários. Há dois tipos de observação: operações criptográficas reais e decisões do modelo local. Os hashes ajudam a relacionar o registo com uma versão do exercício, mas não transformam um relatório editável em evidência imutável. O avaliador continua a precisar de compreender o método e a fronteira do mecanismo executado. A pequena seleção de desktop/mobile e v1/v2 demonstra uma regra dirigida. A população completa produz quatro objetos distintos; retirar v2 reduz os estratos observados para dois. Inverter a ordem das linhas não muda os IDs escolhidos. Repetir a seleção também não aumenta os objetos distintos. Liga estas saídas ao plano de avaliação, em vez de as apresentar como qualidade estatística medida. Na comparação das duas execuções, espera diferenças nos valores aleatórios e assinaturas, preservando os critérios e resultados semânticos. Um hash binário diferente de uma assinatura ECDSA não significa, por si, regressão. Identifica o que deve ser estável e o que pode variar antes de automatizar a comparação.
Preparar a aceitação e o suporte da integração
Converte a análise numa lista de decisões que os responsáveis conseguem executar. Para uma integração fictícia de autenticação, identifica origem e RP ID esperados, titularidade das credenciais, política de verificação do utilizador, frescura exigida, versões suportadas e percurso de recuperação. Associa cada critério a evidência positiva, negativa e a uma limitação conhecida. Define quem decide perante divergências e que operações podem continuar quando um requisito de maior garantia não é satisfeito. O objetivo é evitar uma passagem para produção em que a equipa de suporte só conhece a mensagem genérica “login falhou”. Durante a revisão, distingue falha do controlo, falha do teste e ausência de cobertura. Uma operação recusada porque o ambiente não iniciou não valida a sua política. Uma operação legítima aceite também não prova rejeição das combinações indevidas. Guarda os resultados inconclusivos e planeia a sua resolução, sem os contar como sucessos. O handover deve incluir condições de rollback, contactos e critérios de nova avaliação após mudanças relevantes. Estes exemplos não descrevem procedimentos internos de um banco específico. A documentação e a execução local preparam melhores decisões, mantendo pendentes os ensaios empresariais, a revisão especializada independente e qualquer inferência psicométrica sobre preparação para o exame.
python3 content/labs/cissp-assurance-contracts/run.py --output content/labs/cissp-assurance-contracts/learner-run.jsonUma asserção assinada de uma origem indevida é recusada; remover só a comparação de origem expõe uma lacuna na suíte antiga.
Armadilhas comuns
Tratar assinatura válida como autorização completa; contar repetições como novas amostras; chamar implementação FIDO ao subconjunto didático.
Tópicos relacionados: WebAuthn e federação · Testes negativos e amostragem
Aceitação exige assinatura, contexto e evidência proporcionais à afirmação; a força da conclusão depende do que foi observado.
Referência: Web Authentication Level 3 · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29