Existe algum benefício de segurança para uma política de alteração de senha?

Question

Constatei que, em vários casos, forçar os usuários a alterar a senha regularmente torna-se mais uma questão de manutenção do que uma ajuda para a segurança. Além disso, vi usuários escreverem suas novas senhas, pois não têm tempo suficiente para lembrar de suas senhas e não podem ser incomodadas para reaprender outra.

Qual benefício de segurança existe para forçar uma alteração nas senhas?

    

Answer 1

Aqui está um resumo diferente do diário da SANS:
Regras da senha: altere-as a cada 25 anos

There is one practical benefit. If someone has your password, and all they want is to read your email and remain undetected, they can do so forever, unless you eventually change your sign-in secret. Thus, regularly changing the password doesn't help much against someone breaking in and making it off with your goods, but it DOES give you a chance to shake off any stalkers or snoopers you might have accessing your account. Yes, this is good. But whether this benefit alone is worth the hassle and mentioned disadvantages of forcing users to change their password every 90 days, I have my doubts.

    

Answer 2

Force uma mudança de senha quando você a adivinha (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 é "por quê?" é "porque fomos capazes de adivinhar cego". Ele recompensa automaticamente aqueles que escolhem senhas difíceis de adivinhar e ensina a seus usuários quais senhas são fracas. Se eles escolherem "senha1", ela expirará antes de poderem efetuar login uma vez. Se um usuário escolher uma senha alfanumérica, de 16 caracteres, aleatória e de letras maiúsculas e minúsculas, você nunca irá adivinhar - e ninguém mais o fará. Deixe-os por muito tempo, e eles poderão até memorizá-lo.

    

Answer 3

É um trade off. Exigir alterações frequentes de senha resulta em senhas de menor qualidade. 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ê for mais longe, as pessoas começam a confiar em senhas compartilhadas - mais cedo e você acaba com "November09", "December09".

    

Answer 4

O pior de forçar uma mudança nas senhas não é que você esteja realmente fazendo com que as pessoas mudem 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 descobrir uma boa senha, é mais provável que seja menos segura. mas mais fácil de lembrar, ou mais seguro, mas apenas é anotado, negando assim a vantagem de segurança.

    

Answer 5

Se as senhas são de complexidade suficiente para que não sejam facilmente adivinhadas, e não sejam compartilhadas entre sistemas, e é improvável que tenham sido comprometidas, a mudança de uma senha provavelmente não é tão importante.

No entanto, se algum deles ocorrer, e os dois primeiros forem provavelmente mais comuns do que não, forçar as pessoas a alterar a senha periodicamente significa que, pelo menos, é menos provável que compartilhem senhas.

Dito isso, gostaria de instruir seus usuários sobre o significado de uma boa senha e por que é muito ruim compartilhá-los. Escrevê-las é comum, não importa o que você faça.

Recomendo que as pessoas escolham uma senha em um livro que conheçam, lembrando-se de uma frase não tão familiar ou criando uma frase. Use a primeira letra de cada palavra e adicione dois números dentro de algum lugar. A maioria das pessoas consegue se lembrar disso depois de digitá-lo algumas vezes.

    

Answer 6

Não vejo nenhum benefício nessa prática.

A senha strong é muito mais importante. Por strong eu quero dizer 9 + alfanuméricos + símbolos especiais, ou uma senha / frase não-dicionário de 15 + [a-z] -only (isso é baseado em um estudo recente do custo de forçar as senhas usando o EC2 da Amazon).

Os sistemas acessados remotamente devem ter software de detecção e prevenção de força bruta (por exemplo, fail2ban) em todos os serviços expostos. Isso é muito mais importante, IMO, do que a política regular de mudança de senha.

    

Answer 7

A questão básica é que as senhas, como um mecanismo de segurança, fede.

Se você pedir às pessoas para mudá-las com frequência, elas as anotam. Se você pedir que eles usem senhas de 30 letras com pelo menos 3 números, 4 letras maiúsculas e um caractere de controle, eles os esquecem ou escrevem ou fazem outras coisas bobas. Se forem simples, os usuários usarão senhas estúpidas como bunny7 ou Bunny7. E eles usarão a mesma senha incorreta para tudo, incluindo a conta pornográfica e a conta do hotmail.

Eu gosto de ferramentas como Mobile OTP , que permitem que os usuários usem o celular como uma ferramenta de autenticação de dois fatores.

No longo prazo, é provável que, de alguma forma, chegaremos a um mundo com certificados criptografados como o mecanismo de identificação do usuário. Coisas como OpenID e CAS simplificam a autenticação do usuário e permitem signon único 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", da senha "time-sheet" e da senha "CRM". Unifique-os em uma infra-estrutura de autenticação comum que exige que os usuários emitam suas credenciais uma vez. Em seguida, faça-os usar algo como o MobileOTP ou um RSA SecurID que usa a autenticação de dois fatores.

A curto prazo, as políticas de senhas serão o tópico das guerras religiosas. Basta fazer o que seu chefe lhe pedir e, se você for o chefe, use seu julgamento com base em seu perfil de segurança esperado e na base de usuários.

Boa sorte!

    

Answer 8

Esta prática, que não é totalmente inútil, foi muito mais importante há muito tempo. Debater essa política é, na verdade, contraproducente, pois desvia a atenção das ameaças atuais que são muito mais sérias.

Considere:

• Se você usa Windows / AD e uma conta não tem a caixa marcada "Conta é sensível e não pode ser delegada", essa conta pode ser usada por meio de 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 for comprometida por uma vulnerabilidade de segurança, o token de segurança do Windows na memória poderá ser usado para acessar outros computadores. Novamente, nenhuma senha é necessária.

Esse segundo, por sinal, é por que você só deve acessar os servidores usando uma conta diferente da sua conta de usuário regular do dia-a-dia. Observe também que ambos os cenários derrotam completamente até mesmo os mecanismos de autenticação de dois fatores mais robustos.

A melhor coisa que pode ocorrer com relação à segurança de senha é parar de debatê-la e focar nas ameaças mais contemporâneas e sérias.

Mais informações:

Confira a apresentação de Luke Jennings, "Um símbolo para governar todos eles":

link

Insomnia Shell - exemplo do código necessário para comprometer os tokens em um servidor ASP.Net:

link

Como: Usar Transição de Protocolo e Delegação Restrita no ASP.NET 2.0

link

Pesquise "sem senha".

    

Answer 9

Quanto mais uma senha permanecer inalterada, maior a probabilidade de comprometimento, simplesmente porque haverá mais oportunidades para situações em que ela possa ser comprometida (dado um tempo infinito, tudo é possível). Também torna mais difícil mudar no futuro, já que o usuário se acostumou com o antigo. Um risco adicional é que, se estiver comprometido e o usuário não tiver conhecimento do fato, há potencial para um uso incorreto sério e sério da conta do usuário. Alterações periódicas pelo menos atenuarão isso, pois a próxima alteração de senha forçada tornará a senha comprometida inútil.

Na minha experiência, o cenário com maior probabilidade de levar os usuários a escrever senhas é a falta de pensamento conjunto em sua infraestrutura de segurança, como ter vários sistemas diferentes, todos exigindo seu próprio nome de usuário e senha. Jogue 5 desses em um usuário e você terá uma síndrome de nota amarela-pegajosa com uma vingança.

Uma política de senhas razoável que permite aos usuários escolher senhas de fácil memorização, mas difíceis de decifrar, juntamente com uma boa educação do usuário, algumas autenticações integradas sólidas e políticas decentes de bloqueio e expiração, tudo feito por um AUP que proíbe explicitamente a senha compartilhar, é o melhor caminho.

    

Answer 10

Se você estiver armazenando credenciais em cache (o que a maioria das pessoas faz por disponibilidade), isso é obrigatório. Se um computador for fisicamente roubado e o cache de credencial estiver habilitado, o ladrão poderá forçar a máquina a desligar a rede, sem medo de que a política de bloqueio de conta seja ativada. Eles, então, possuem credenciais válidas para seus recursos de 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 prompts individuais, o que impede que as credenciais privilegiadas sejam forçadas a brutear no caso de roubo / invasão.

    

Answer 11

Estou no meio do campo de nunca exigir alterações de senha. Ou como o artigo diz - a cada 25 anos - sim, eu estarei 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 requisitos de força diferentes. Como pode um humano fraco lidar com isso? Várias maneiras que vi: escreva-as em um quadro branco. Escrevê-los em um papel e mantê-los em uma gaveta desbloqueada. ou o 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 (que são MUITO comuns) não compensa totalmente qualquer pequeno benefício de segurança obtido ao exigir alterações.

Eu tenho tempo para escrever este post porque estou esperando alguém em suporte de TI para desbloquear uma das minhas contas. Aparentemente, não atualizei minha planilha corretamente da última vez. Existe um estudo que calcula o BILLION $$$ perdido com este absurdo?