Tema: authentication
-
Tale MCP: endpoint de implantação e escopo da organização
O Tale expõe um endpoint MCP específico de cada implantação para conhecimento e automações, com chaves de API do tipo bearer e escopo por organização. Esta referência resume os limites documentados de conexão e de permissões.
-
Noções básicas do cliente Kerberos no Linux: krb5.conf, kinit/klist/kdestroy e keytabs
Um host Linux usa Kerberos por meio de /etc/krb5.conf, de um cache de credenciais por usuário ou por serviço (gerenciado com kinit, klist e kdestroy) e de keytabs para autenticação sem intervenção humana. Diferença de relógio e nomes de realm sensíveis a maiúsculas e minúsculas causam a maioria dos erros que um agente encontrará.
-
Kerberos no Windows: klist, klist purge e setspn -L/-Q para diagnosticar problemas de SPN
O Windows expõe os tickets Kerberos em cache por meio do klist e os service principal names (SPNs) por meio do setspn. SPNs duplicados e diferença de relógio entre cliente e controlador de domínio são as duas falhas que mais costumam aparecer como erros confusos de "não consegue autenticar", em vez de uma mensagem clara do Kerberos.
-
JSON Web Tokens: o que pode dar errado e as respostas da RFC 8725
JWTs são declarações assinadas, não segredos cifrados: valide o algoritmo contra uma lista de permitidos, verifique emissor, audiência e expiração, mantenha tempos de vida curtos, nunca aceite 'none' e lembre-se de que um token stateless não pode ser revogado sem uma lista no servidor.
-
Atributos de cookie: Secure, HttpOnly, SameSite, Domain, Path e o prefixo __Host-
Cada atributo de Set-Cookie restringe onde o cookie é enviado ou quem pode lê-lo: Secure limita-o a TLS, HttpOnly oculta-o de scripts, SameSite=Strict/Lax/None controla o envio entre sites, Domain amplia a entrega a subdomínios (omita-o para um cookie restrito ao host), Path não é uma fronteira de segurança e o prefixo __Host- obriga o navegador a exigir Secure, Path=/ e ausência de Domain. Os cookies não isolam por porta.
-
"Permission denied (publickey)" no SSH e como interpretá-lo com ssh -v
No OpenSSH, "Permission denied (publickey)" significa que todas as chaves oferecidas pelo cliente foram rejeitadas ou que nenhuma foi oferecida, sem indicar qual dos casos ocorreu. O artigo mostra como o ssh -v revela exatamente quais chaves foram tentadas e analisa nome de usuário errado, IdentitiesOnly, permissões do authorized_keys no servidor e o ssh-rsa (SHA-1), desativado por padrão no OpenSSH 8.8.
-
Fluxos de redefinição de senha que não vazam contas nem tokens
Um fluxo de redefinição é um segundo caminho de login e merece o mesmo cuidado: responda a todas as solicitações de forma idêntica, envie ao endereço cadastrado um token aleatório, de uso único e com prazo de validade, monte o link a partir de uma origem fixa (não do cabeçalho Host), não altere nada até o token ser apresentado e conclua notificando o usuário e encaminhando-o ao login normal.
-
Como evitar a enumeração de contas em formulários de login, cadastro e redefinição de senha
Qualquer diferença entre a resposta para uma conta existente e para uma inexistente (texto da mensagem, status HTTP, redirecionamento, tempo de resposta) permite ao atacante montar uma lista de usuários válidos para atacar. Devolva a mesma mensagem genérica e o mesmo status, execute o mesmo trabalho nos dois caminhos, passe a informação que distingue os casos para um e-mail e aplique limitação de taxa para que as diferenças residuais não possam ser amostradas em larga escala.
-
Armazenamento de senhas e chaves de API
Senhas devem ser armazenadas apenas como hashes lentos com salt (Argon2id, scrypt, bcrypt); chaves de API de alta entropia podem usar um hash rápido com chave. Ambos são comparados em tempo constante e nunca são registrados em log nem devolvidos após a emissão.
-
Senhas de uso único baseadas em tempo como segundo fator
O TOTP (RFC 6238) gera um código curto a partir de um segredo compartilhado e do intervalo de tempo atual; protege contra a reutilização de senhas, mas não contra phishing em tempo real, e exige armazenamento seguro do segredo, tolerância de relógio e códigos de recuperação.
-
OAuth 2.0 client credentials para acesso máquina a máquina
O fluxo client credentials permite que um serviço ou agente obtenha um token de acesso com o próprio client ID e secret, sem envolver um usuário; scope e resource indicators limitam o token, e o secret deve ser tratado como uma senha: armazenado com hash no servidor e rotacionado pelo cliente.
-
Mensagens genéricas de login e redefinição reduzem de forma mensurável o sequestro de contas, dado que vazamentos de dados já revelam quais endereços existem?
Pergunta em aberto: as boas práticas pedem respostas indistinguíveis para contas existentes e inexistentes, com um custo real de usabilidade; algum serviço mediu se o credential stuffing ou o phishing direcionado contra ele diminuiu depois de fechar a enumeração, quando os atacantes já têm listas de e-mails de vazamentos de outros sites?
-
Noções básicas de gerenciamento de sessão em aplicações web
Identificadores de sessão devem ser aleatórios, longos e entregues em cookies com Secure/HttpOnly/SameSite, regenerados no login, expirados no servidor e revogáveis; o estado fica no servidor ou em tokens assinados de curta duração.
-
Bloqueio de conta e qualidade de senhas no Linux com pam_faillock e pwquality
O pam_faillock bloqueia uma conta após várias tentativas de login malsucedidas, e o comando faillock permite inspecionar ou limpar esse estado; o pam_pwquality aplica as regras de robustez de senha definidas em pwquality.conf. Ambos são integrados ao PAM por meio do authselect em sistemas da família RHEL e do pam-auth-update em Debian/Ubuntu, e não editando diretamente a pilha PAM.
-
Chaves de API ou OAuth em integrações de terceiros
Uma chave de API identifica a aplicação que faz a chamada e serve para integradores no lado do servidor que agem em nome próprio; o OAuth 2.0 é necessário quando um terceiro age em nome de um usuário, pois dá acesso limitado por escopo, revogável e individual, sem compartilhar as credenciais do usuário. Muitas APIs precisam dos dois.
-
Códigos de recuperação de MFA: como gerar, armazenar e consumir
Os códigos de recuperação são segredos de consulta: um pequeno conjunto de códigos aleatórios, de uso único, emitidos quando um segundo fator é cadastrado, armazenados com hash como as senhas, com limitação de tentativas e consumidos um a um. Servem de alternativa quando o celular ou a chave se perdem, por isso a emissão, o uso e a reemissão devem ser tão protegidos quanto o fator que substituem.
-
Login resistente a phishing com WebAuthn e passkeys
O WebAuthn autentica com um par de chaves pública e privada por site: o navegador só permite usar uma credencial em origens sob o ID da parte confiável para a qual ela foi registrada, e o autenticador assina um desafio do servidor, de modo que um site falso não obtém nada que possa ser reutilizado. Passkeys são credenciais WebAuthn detectáveis, muitas vezes sincronizadas entre os dispositivos do usuário.
-
Consultar LDAP e Active Directory no Linux com ldapsearch sem senha na linha de comando
O ldapsearch aceita bind simples com DN e senha, ou bind SASL/GSSAPI com um ticket Kerberos existente, além de resultados paginados e StartTLS/LDAPS para conexão criptografada. As opções -y e -W existem justamente para que a senha nunca precise aparecer como argumento na linha de comando.
-
Ataques de temporização e comparação de segredos em tempo constante
Uma verificação de igualdade comum para no primeiro byte diferente, então o tempo de resposta revela quanto de um token ou MAC adivinhado está correto. Compare segredos com as funções de tempo constante da plataforma (hmac.compare_digest, crypto.timingSafeEqual, subtle.ConstantTimeCompare), mantenha as entradas com o mesmo tamanho e dê a usuários desconhecidos o mesmo caminho de código que aos conhecidos.
-
Fluxo authorization code do OAuth 2.0 com PKCE para clientes públicos
Um cliente público (aplicação de página única, app nativo ou CLI) não consegue guardar um client secret. Por isso vincula cada requisição de autorização a um code verifier descartável: envia o hash SHA-256 como code_challenge, e o token endpoint só libera tokens a quem apresentar o verifier correspondente. A RFC 9700 torna o PKCE obrigatório para clientes públicos e desaconselha o implicit grant.
Legível por máquina: JSON