Descobri em vários casos, forçar os usuários a alterar sua senha regularmente torna-se mais uma pressão sobre a manutenção do que uma ajuda para a segurança. Além disso, vi usuários anotando suas novas senhas, pois eles não têm tempo suficiente para lembrar suas senhas e não podem se incomodar em aprender outra.
Que benefício de segurança existe para forçar uma alteração nas senhas?
Respostas:
Aqui está uma visão diferente do diário do SANS:
Regras de senha: Altere-as a cada 25 anos
Há um benefício prático. Se alguém tiver sua senha e tudo o que eles quiserem for ler seu e-mail e permanecer sem ser detectado, eles poderão fazer isso para sempre, a menos que você acabe alterando seu segredo de login. Assim, alterar regularmente a senha não ajuda muito contra alguém invadir e fugir com suas mercadorias, mas dá a você a chance de afastar qualquer perseguidor ou bisbilhoteiro que você possa acessar sua conta. Sim, isso é bom. Mas se esse benefício por si só vale o aborrecimento e as desvantagens mencionadas de forçar os usuários a alterar sua senha a cada 90 dias, tenho minhas dúvidas.
Forçar uma alteração de senha quando você adivinhar (executando um programa de adivinhação de senha em todos os seus usuários o tempo todo).
É difícil argumentar com "você precisa alterar sua senha" quando a resposta para "por quê?" é "porque conseguimos adivinhar cegamente". Ele recompensa automaticamente aqueles que escolhem senhas difíceis de adivinhar e ensina aos usuários quais senhas são fracas. Se eles escolherem "senha1", ela expirará antes que eles possam fazer login uma vez. Se um usuário escolher uma senha alfanumérica de 16 caracteres, aleatória, com letras maiúsculas e minúsculas, você nunca vai adivinhar - e nem mais ninguém. Vamos mantê-lo por muito tempo, e eles poderão memorizá-lo.
É uma troca. Exigir alterações frequentes de senha resulta em senhas de qualidade inferior. Houve até pesquisas para esse efeito.
Dito isto, a única maneira confiável que encontrei para impedir que os usuários compartilhem senhas é exigir alterações periódicas de senha. Minha experiência mostra que 90 dias parecem ser um compromisso decente entre usabilidade e segurança. Se você demorar mais, as pessoas começarão a confiar em senhas compartilhadas - mais cedo e você terminará com "November09", "December09".
A pior coisa sobre forçar uma alteração nas senhas não é que você está realmente fazendo as pessoas mudarem suas senhas. É que geralmente vem com pouco ou nenhum aviso, e eles são imediatamente atingidos por um problema com o qual precisam lidar imediatamente, então, em vez de dar tempo a alguém para pensar em uma boa senha, é mais provável que seja uma menos segura mais fácil de lembrar ou mais seguro, mas é anotado, negando a vantagem de segurança.
Se as senhas forem de complexidade suficiente, não são fáceis de adivinhar e não são compartilhadas entre sistemas, e é improvável que tenha sido comprometida, a alteração de uma senha provavelmente não é tão importante.
No entanto, se alguma dessas situações ocorrer, e as duas primeiras são provavelmente mais comuns do que não, forçar as pessoas a alterar a senha periodicamente significa que elas têm menos probabilidade de compartilhar senhas, pelo menos.
Dito isso, eu escolheria educar seus usuários sobre o que significa uma boa senha e por que é muito ruim compartilhá-los. Anotá-las é comum, não importa o que você faça.
Eu recomendo que as pessoas escolham uma senha de um livro que conhecem, lembrando-se de uma citação não tão familiar dele ou inventando uma frase. Use a primeira letra de cada palavra e adicione dois números em algum lugar. A maioria das pessoas se lembra disso depois de digitá-lo algumas vezes.
Não vejo nenhum benefício nessa prática.
Senha forte é muito mais importante. Por forte, refiro-me a 9+ símbolos alfanuméricos + especiais ou uma senha / frase não-dicionário de mais de 15 [az] - apenas (isso é baseado em um estudo recente do custo de senhas de força bruta usando o EC2 da Amazon).
Os sistemas acessados remotamente devem ter um software de detecção e prevenção de força bruta (por exemplo, fail2ban) em todos os serviços expostos. Isso é muito mais importante do que a política regular de alteração de senha.
A questão básica é que as senhas, como mecanismo de segurança, fede.
Se você pedir às pessoas para alterá-las frequentemente, elas as anotam. Se você solicitar que eles usem senhas de 30 letras com pelo menos 3 números, 4 letras maiúsculas e um caractere de controle, elas as esquecem, as anotam ou fazem outras coisas tolas. Se forem simples, os usuários usarão uma senha estúpida como bunny7 ou Bunny7. E eles usarão a mesma senha incorreta para tudo, incluindo a conta pornô e a conta do hotmail.
Gosto de ferramentas como o Mobile OTP , que permitem que os usuários usem o celular como uma ferramenta de autenticação de dois fatores.
A longo prazo, é provável que aterrissemos de alguma forma em um mundo com certificados criptografados como mecanismo de identificação do usuário. Coisas como OpenID e CAS simplificam a autenticação do usuário e permitem a conexão única conveniente.
A longo prazo, a melhor aposta é reduzir o número de vezes que os usuários precisam emitir credenciais - livrar-se da senha "HR" e da senha "folha de ponto" e da senha "CRM". Unifique-os em uma infraestrutura de autenticação comum que exija que os usuários emitam suas credenciais uma vez. Depois, peça que eles usem algo como MobileOTP ou um RSA SecurID que usa autenticação de dois fatores.
No curto prazo, as políticas de senha serão o tema das guerras religiosas. Basta fazer o que seu chefe pedir e, se você for o chefe, use seu julgamento com base na sua base de usuários e no perfil de segurança esperado.
Boa sorte!
Essa prática, que não é totalmente inútil, era muito mais importante há muito tempo. Debater esta política é realmente contraproducente, pois desvia a atenção das ameaças atuais que são muito mais graves.
Considerar:
Se você usa o Windows / AD e uma conta não tem a caixa marcada como "A conta é sensível e não pode ser delegada", essa conta pode ser usada por representação, e nenhuma senha é necessária. O código para fazer isso é trivial.
Se a estação de trabalho do Windows de uma pessoa estiver comprometida por uma vulnerabilidade de segurança, seu token de segurança do Windows na memória poderá ser usado para acessar outros computadores. Novamente, nenhuma senha é necessária.
A segunda, a propósito, é por que você deve acessar apenas servidores usando uma conta diferente da sua conta de usuário normal do dia-a-dia. Observe também que os dois cenários derrotam completamente até os mecanismos de autenticação de dois fatores mais robustos.
A melhor coisa que pode ocorrer com relação à segurança da senha é parar de debatê-la e se concentrar nas ameaças mais contemporâneas e sérias.
Mais Informações:
Confira a apresentação de Luke Jennings, "Um token para governar todos":
http://eusecwest.com/esw08/esw08-jennings.pdf
Insomnia Shell - exemplo do código necessário para comprometer tokens em um servidor ASP.Net:
http://www.insomniasec.com/releases/tools
Como: Usar transição de protocolo e delegação restrita no ASP.NET 2.0
http://msdn.microsoft.com/en-us/library/ms998355.aspx
Procure por "sem senha".
Quanto mais tempo uma senha permanecer inalterada, maior a probabilidade de que ela seja comprometida, simplesmente porque haverá mais oportunidades para situações nas quais ela pode ocorrer (desde que uma quantidade infinita de tempo seja possível). Também dificulta a mudança no futuro, pois o usuário se acostuma com o antigo. Um risco adicional é que, se for comprometido e o usuário não estiver ciente do fato, é possível que ocorra algum uso indevido e grave da conta do usuário. Alterações periódicas pelo menos atenuam que, à medida que a próxima alteração de senha aplicada tornará a senha comprometida inútil.
De acordo com minha experiência, o cenário que provavelmente fará com que os usuários escrevam senhas é a falta de pensamento unido em sua infraestrutura de segurança, como ter vários sistemas diferentes, todos os quais exigem seu próprio nome de usuário e senha. Jogue 5 deles em um usuário e você obterá a síndrome da nota pegajosa amarela com uma vingança.
Uma política de senha razoável que permita que os usuários escolham senhas fáceis de lembrar, mas difíceis de decifrar, juntamente com uma boa educação do usuário, alguma autenticação integrada sólida e políticas decentes de bloqueio e expiração, todas com backup de uma AUP que proíbe explicitamente o compartilhamento de senhas, é a melhor maneira.
Se você estiver armazenando em cache credenciais (o que a maioria das pessoas faz por disponibilidade), isso é obrigatório. Se um computador for fisicamente roubado e o cache de credenciais estiver ativado, o ladrão poderá forçar a máquina a sair da rede sem medo de que a política de bloqueio de conta seja ativada. Eles então têm credenciais válidas para os recursos da sua rede. Alterar essas senhas em intervalos regulares pode ajudar a minimizar esse dano.
Esse é o motivo exato pelo qual você nunca faz login com uma conta privilegiada, sempre faz login como um usuário limitado e eleva solicitações individuais, o que impede que credenciais privilegiadas sejam brutas e forçadas no caso de roubo / invasão.
Estou bem no campo de nunca exigir alterações de senha. Ou como o artigo diz - a cada 25 anos - sim, eu vou estar morto então. Boa. Aqui está o porquê ... Eu tenho 12 senhas para lembrar no meu trabalho. A maioria deles muda e os que mudam estão em horários totalmente diferentes. Todos eles têm diferentes requisitos de força. Como um humano fraco pode lidar com isso? Várias maneiras que já vi: escreva-as em um quadro branco. Escreva-os em um papel e mantenha-os em uma gaveta destrancada. ou meu método preferido: armazene-os em uma planilha do Google Doc bastante insegura. Não há como você me convencer de que qualquer um desses métodos (MUITO comuns) não compensa totalmente nenhum pequeno benefício de segurança obtido ao exigir alterações.
Tenho tempo para escrever esta postagem porque estou esperando alguém no suporte de TI desbloquear uma das minhas contas. Aparentemente, não atualizei minha planilha corretamente da última vez. Existe um estudo que calcula os BILHÕES de $ $ perdidos por esse absurdo?