- Políticas que exigem autenticação frequente acabam causando apenas incômodo ao usuário, sem efeito real de reforço de segurança
- Com o aumento de ameaças modernas como ataques de fadiga de MFA, a autenticação repetida pode acabar se tornando uma vulnerabilidade
- O bloqueio de tela do sistema operacional e atualizações em tempo real das políticas de acesso são meios de proteção mais eficazes
- Autenticação adicional só é necessária imediatamente antes de ações sensíveis; ciclos arbitrariamente curtos de login são desnecessários
- Métodos modernos de controle de acesso aplicam políticas de forma automática e rápida, sem atrapalhar o usuário
Por que a autenticação frequente não fortalece a segurança
Problemas causados pela reautenticação repetida
- Quando a sessão expira no meio do fluxo de trabalho e o usuário precisa redigitar com frequência a senha e o MFA (autenticação multifator), há queda de produtividade
- No início, bastava redigitar a senha, mas com a adição da etapa de MFA, aumentaram o tempo perdido e a insatisfação dos usuários
- Quanto maior a frequência das solicitações de MFA, maior também a chance de sucesso de ataques de fadiga de MFA (MFA fatigue attacks)
- No passado, trocas frequentes de senha ou tempos curtos de expiração de sessão eram vistos como medidas eficazes de segurança, mas as diretrizes mais recentes passaram a considerá-los contraproducentes
- A segurança não depende da frequência de login, e sim de quão rapidamente a gestão de permissões de acesso e as mudanças de política são refletidas
A essência dos métodos de autenticação
- A autenticação normalmente comprova uma de duas coisas
- Comprovação de posse do dispositivo: confirmação de que a pessoa possui fisicamente o dispositivo, como Windows Hello PIN, YubiKey e smart card
- Comprovação de identidade: identificação de que se trata do próprio usuário, como senha, Face ID e Touch ID
- O papel principal de um Identity Provider (IdP) é se concentrar na verificação de identidade
- Face ID, Touch ID e Windows Hello são sistemas integrados que lidam ao mesmo tempo com comprovação de posse do dispositivo e comprovação de identidade, oferecendo maior segurança
- Muitos administradores definem expiração de sessão curta por receio de que mudanças de política não sejam aplicadas imediatamente
Ameaças reais de segurança e o papel da autenticação
- A maioria dos invasores tenta atacar por meio de phishing remoto, e o roubo de senha é extremamente fácil
- Para se defender de ataques remotos, o uso de segundo fator de autenticação (por exemplo, YubiKey) é uma medida importante
- Em ataques físicos, como perda ou roubo de dispositivo, normalmente a tela já está bloqueada
- Na prática, quanto mais vezes o usuário faz login, mais oportunidades o invasor tem de roubar credenciais, o que piora a segurança
O papel do sistema operacional e dos serviços web
- Sistemas operacionais modernos protegem automaticamente o sistema com a função de bloqueio de tela quando o usuário se afasta
- Em vez de aumentar o incômodo ao usuário com mais autenticações, o ideal é aplicar políticas de bloqueio automático
- Exceto em computadores compartilhados, a expiração curta de sessão web não passa de um resquício da época das antigas lan houses
- Fora de serviços sensíveis (como internet banking), políticas inadequadas de tempo de expiração de sessão acabam prejudicando tanto a segurança quanto a usabilidade
Um modelo de segurança eficiente e amigável ao usuário
- A autenticação imediata sob demanda (on-demand authentication) antes de ações sensíveis é o ideal
- O modo check do Tailscale SSH e o Slack Accessbot oferecem verificação imediata do usuário quando necessário
- Combinando isso com a imposição de bloqueio de tela do sistema operacional, é possível manter o equilíbrio entre segurança e conveniência
- Verificações contínuas do estado de segurança (device posture check) e controle de acesso em tempo real acontecem automaticamente, independentemente do comportamento do usuário
- Exemplos:
- Se o dispositivo estiver offline, perdido ou falhar na verificação de segurança, o acesso é revogado imediatamente
- Em caso de mudança de função ou identidade, a política de acesso é atualizada automaticamente
- Em vez de obrigar o usuário a se autenticar repetidamente, a automação em tempo real é muito mais inteligente e segura
Conclusão
- Fazer login com frequência não aumenta a segurança de forma eficaz e pode, ao contrário, levar a reutilização de senhas, phishing e fadiga de MFA
- Um sistema de segurança silencioso e automatizado é a melhor proteção
- A Tailscale busca uma segurança adaptativa, inteligente e realmente útil
- Mesmo sem o usuário ajustar manualmente a frequência de login, o sistema é projetado para gerar o mínimo possível de atrito de autenticação apenas nos momentos necessários
- Os recursos de verificação de segurança em tempo real da Tailscale também podem ser estendidos a outros apps, protegendo até sistemas legados com segurança
Links de referência
4 comentários
Como também apareceu nos comentários do HN, há um grande problema no fato de inspeções/regulamentações de segurança baseadas em padrões engessados e antigos acabarem atrapalhando, em contraste com um ambiente de TI que muda rapidamente. Talvez isso já seja algo que quem está na linha de frente conhece bem... haha
Muitos serviços na Coreia exibem alertas incômodos pedindo para redefinir a senha uma vez a cada 30 dias.
Como isso foi imposto por anos como uma obrigação de proteção de dados pessoais, é bem incômodo mesmo... buá buá
Comentários no Hacker News
Acho que políticas obrigatórias de troca periódica ou expiração de senha são um problema ainda maior; elas frequentemente acabam bloqueando as pessoas para fora da conta (por exemplo, se a senha expira durante as férias), e daí vem a burocracia de ter que ir pessoalmente ao TI, passar horas no telefone pedindo redefinição ou entrar em contato por meio de um colega que ainda não esteja bloqueado.
Muitas empresas (a maioria?) ainda aplicam esse tipo de política, mas o NIST já não recomenda mais mudanças arbitrárias de senha.
Documento oficial do NIST
A Microsoft também não recomenda expiração de senha, dizendo que faz mais mal do que bem.
Documento oficial da Microsoft
Mesmo assim, parece que no TI ou na segurança essas recomendações ainda não são vistas como suficientemente “autoritativas”, e ainda existem guias que continuam recomendando essas políticas.
Às vezes, quando entro em algum site aleatório e ele me força a redefinir a senha, penso que talvez não seja por expiração baseada em tempo, mas porque a conta vazou ou foi comprometida.
Se o operador do site souber que certas contas apareceram em uma lista de vazamento de dados, acho razoável exigir troca forçada de senha no próximo login.
Falei disso com o responsável por cibersegurança, e ouvi que o padrão PCI exige troca periódica de senha, então acaba dependendo de qual auditoria você considera mais importante.
Antigamente eu ficava tão irritado com esse tipo de política que só acrescentava uma letra de a a z no fim da senha a cada vez.
Felizmente, na empresa em que estou agora uso a mesma senha há 3 anos e estou bem satisfeito.
Acho sem sentido provedores mandarem eu trocar a senha periodicamente se ela não vazou.
É absurdo que isso ainda seja aplicado como se fosse um padrão oficial.
No fim, todas as minhas contas acabam usando só o padrão 1234abcd@.
Acho isso realmente incômodo por causa dos produtos da Apple.
Confirmo que esse padrão aparece em todos os produtos da Apple.
Configuro o Touch ID no Mac, faço login na conta Apple na App Store e, quando tento instalar um app, continua aparecendo uma janela pedindo a senha; poderia autenticar com Touch ID, mas pede a senha toda vez.
Até para instalar app gratuito acontece a mesma coisa, e acho isso totalmente desnecessário.
Esse padrão também aparece de vez em quando no iPhone da minha esposa.
Especialmente ao resetar o telefone e configurar tudo de novo, ele pede repetidamente para reinserir a senha da Apple.
Mesmo em situações em que o Touch ID já protege suficientemente, continua assim e é bem frustrante.
Quando você acessa serviços da Apple em um dispositivo que não é da Apple, o incômodo é ainda pior.
Toda vez que faço login no icloud.com, mesmo clicando em “confiar neste dispositivo”, no dia seguinte ele de novo exige senha + código de uso único em 2FA.
Se o Face ID falha durante um pagamento ou instalação de app, ele não deixa usar o PIN como alternativa e obriga a digitar a senha completa da conta Apple, num fluxo em que nem dá para abrir o gerenciador de senhas.
Passar por isso no caixa é uma experiência bem desagradável.
Vale a pena confirmar se a aprovação de compras com Touch ID está realmente ativada.
(É preciso configurar em Settings > Touch ID & Password.)
Se isso não estiver habilitado, ele pode continuar pedindo senha.
Pela minha experiência, depois de reiniciar ele só exige autenticação uma vez e, depois disso, o Touch ID funciona para a maior parte das autenticações.
Sempre que conecto o iPhone ao Mac para sincronizar, aparece “Confiar neste dispositivo?” tanto no Mac quanto no iPhone, e mesmo clicando em “Sim” toda vez, na próxima conexão ele pergunta de novo.
Acho natural pedir reautenticação em tarefas que exigem privilégios de
sudo.Nesses casos, dá para reduzir a quantidade de reautenticações agrupando as tarefas relacionadas para autenticar só uma vez.
Meu filho usa um iPad muito antigo, com iOS 10.3, então nem dá para rodar app de gerenciador de senhas, e o navegador também é um app 32-bit, então nem abre direito sites modernos.
Por isso, sempre que vou usar a App Store tenho que digitar manualmente uma senha com mais de 50 caracteres, o que é muito irritante.
Acho que quem precisa ler artigos assim são os auditores que fazem auditoria de segurança.
Enquanto o padrão que eles esperam não mudar, muitas empresas vão continuar seguindo políticas que chamam de padrão da indústria, mas que na prática são tolas.
Especialmente pequenas empresas de certos setores também precisam tirar nota alta em auditorias de segurança, então acabam adotando vários procedimentos inúteis.
Temos pelo menos 6 controles de segurança aplicados à força que sabemos, na prática, que não funcionam, e os auditores ainda relutam bastante em mudar.
Quando passamos por auditoria SOC2, sempre mostramos consistentemente as diretrizes do NIST.
Quando você mostra o link, a maioria acaba aceitando o padrão do NIST.
Tanto Apple quanto Microsoft oferecem configurações corporativas que permitem ao time de segurança da empresa desativar opções como “lembrar deste dispositivo” e “confiar neste dispositivo”.
Auditores ou o CISO fazem auditoria totalmente orientados por checklist, então o que importa não é se a segurança realmente melhora, mas sim conseguir aprovação na auditoria.
Essas configurações só aumentam o incômodo para o usuário e, na prática, acabam piorando a segurança real.
Acho que a Microsoft também estragou os jogos de PC desse jeito.
Só de saber que vai aparecer uma janela aleatória pedindo reautenticação toda vez que eu abrir jogos como Minecraft ou Master Chief Collection, já fico adiando.
Por causa desse incômodo, eu até desativei o 2FA da conta.
É só um jogo, não é autenticação bancária; eu só queria poder jogar em paz.
Ouvi dizer que recentemente passaram a oferecer autenticação por QR code, mas parece que quem projetou esse sistema está completamente desconectado da experiência real do usuário.
Há um ponto que quase não aparece no texto.
Se a UX é ruim, isso por si só pode virar uma vulnerabilidade de segurança.
Se o sistema se comporta de forma irracional no dia a dia, aumenta a chance de os usuários não perceberem mudanças ou comportamentos anormais quando surgir um problema real.
Por exemplo, se ele pede senha com frequência demais, as pessoas acabam digitando no automático, e assim fica mais difícil filtrar riscos como phishing.
Além disso, se o SO não gerencia bem programas de inicialização ou código suspeito rodando em segundo plano, isso também facilita abuso.
Também é um problema o fato de especialistas comuns em segurança quase não considerarem a “psicologia humana” como variável importante, e tudo tender a ser desenhado de forma centrada em checklist ou no ponto de vista da empresa.
São erros que poderiam ser evitados com bom design de produto, mas fornecedores de produtos e serviços são muito mais ativos que consumidores quando se trata de mudanças regulatórias, então as melhorias acabam não acontecendo.
Por isso, na prática, acho que fortalecer regulações ajuda a segurança, mas existe essa situação estranha em que, do ponto de vista das empresas, ninguém quer regulações sobre seus próprios produtos e serviços.
Sistemas que exigem reautenticação frequente não melhoram a segurança de forma efetiva (exceto talvez em casos de expiração bem longa).
Num sistema de autenticação decente, o essencial é a capacidade de revogar acesso imediatamente por meio de expiração de sessão ou gerenciamento explícito de sessão.
Na prática, quando uma sessão é revogada, o mais importante não é o intervalo de reautenticação, mas sim a “latência” até que aquela sessão realmente expire por completo e perca todo o acesso.
Isso fica ainda mais complexo quanto maior for a arquitetura do sistema de autenticação e o número de sistemas envolvidos.
É para isso que serve refresh token.
O token em si expira periodicamente, mas o cliente recebe separadamente a chance de renovar um novo token.
A revogação do token é controlada bloqueando a emissão de novos tokens.
Penso de forma parecida.
Na empresa usamos autenticação em duas etapas.
Uma ou duas vezes por dia eu faço login no keycloak com ADFS + MFA, e a maioria dos sistemas usa o keycloak como OIDC provider, com renovação de token a cada 10~15 minutos.
Assim, na maior parte do tempo basta passar pelo processo mais chato de autenticação uma vez por dia, e quando necessário dá para bloquear completamente, em até 15 minutos, o acesso aos serviços acessados por VPN.
A vantagem é que, no uso normal, essa mudança quase nem é perceptível.
Não é reautenticação que precisa ocorrer periodicamente, e sim só a renovação do token existente.
O ideal é separar o tempo de expiração da autenticação (
auth) do tempo de expiração da autorização (authorization).Se você força reautenticação frequente, as pessoas acabam buscando jeitos de contornar.
Elas anotam a senha em papel, salvam no Google Docs, prendem um Arduino + servo motor na Yubikey, encaminham SMS para o e-mail ou mandam código TOTP pelo WeChat — surgem todo tipo de “gambiarra”.
No fim, quanto mais pesada fica a política inconveniente de autenticação, mais os usuários procuram soluções inseguras de contorno só para conseguir usar o computador minimamente do jeito que querem.
O artigo traz uma ideia do tipo “agora a maioria dos SOs permite desbloqueio por impressão digital ou reconhecimento facial, então não há motivo para não bloquear a tela ao se afastar”, mas na prática isso se aplica muito pouco a workstations (desktops).
Em 30 anos de suporte de campo, só vi um único desktop com leitor de impressão digital.
Também quase não há câmeras; entre os PCs de 5 filiais que administro hoje, menos de 2% têm câmera.
Reconhecimento facial também traz um fator extra de desconforto para o usuário.
Já temos grande desconfiança por causa de reconhecimento facial sem consentimento e feito às escondidas (câmeras de vigilância, escolas/empresas/polícia etc.), e acho esse desconforto totalmente legítimo.
Mesmo quando o equipamento é meu, as empresas de software na prática projetam sistemas que invadem minha autonomia sem qualquer limite moral real.
Por isso acho que chaves de segurança são mais adequadas para workstations.
As políticas de segurança de TI da indústria seguem muito a lógica de “ninguém é demitido por comprar IBM”: todo mundo só faz o que os outros fazem.
Não importa se o sistema está quebrado ou não; o que importa é poder dizer que foi feito “como manda o livro”.
Só que esse livro (o padrão) é algo muito ruim, criado 30 anos atrás.
Por isso, convencer o responsável por segurança da informação de que não é preciso trocar a senha a cada 3 meses exige uma quantidade enorme de energia.
Em uma empresa cliente, todos os sistemas têm limite de sessão de 30 minutos.
Eu já não gostava do Jira por si só, mas ter que fazer login toda vez que vou olhar um ticket é insuportável.
No fim, isso só me leva a ficar no Hacker News em vez de trabalhar.
Hoje em dia, pelo menos, a maioria dos serviços salva o conteúdo em cache, então isso ameniza bastante.
O nome SSO é “SINGLE sign on”, mas na prática ele pede autenticação repetidamente sem fim.
Fico me perguntando por que preciso ver uma mensagem pedindo autenticação SSO centenas de vezes por dia.
Com celular, até dá para entender pelo risco de perda ou roubo, mas em desktops ainda é comum que sejam computadores compartilhados (por exemplo, em bibliotecas) e que as pessoas saiam sem fazer logout, algo que muitos usuários não percebem.
Pelo que eu me lembro, SSO queria dizer fazer login em vários sistemas com um único ID, não necessariamente que você só faria login uma única vez.