Políticas de expiração de senha [closed]

Question

Após receber um e-mail de um fornecedor nos informando que ele estaria nos obrigando a alterar nossa senha a cada seis meses, estou curioso para ver quais políticas de expiração de senha as pessoas usam e por que as usam.

    

Answer 1

Há uma linha tênue entre nunca mudá-lo e mudá-lo com muita frequência. Ter as mesmas senhas por anos geralmente não é uma boa solução, especialmente se estiver disponível publicamente. Mas forçar uma política rígida de mudança também tem efeitos colaterais ruins. Um lugar onde eu trabalhei, forcei todos os usuários na rede interna a alterar as senhas a cada 6 semanas e o passowrd não poderia ser o mesmo que as seis senhas anteriores. Três senhas erradas bloquearam a estação de trabalho e a equipe de TI teve que desbloqueá-la. O que resultou em todos escrevendo a senha em notas Post-It penduradas na tela ou colocadas em sua gaveta. Pesadelo.

Eu diria que alterar a senha uma vez a cada seis meses deve ser suficiente. Isso evitará as temidas notas do Post-It.

    

Answer 2

Eu sugeriria usar um pouco de matemática que leve em conta sua complexidade mínima de senha, a rapidez com que um invasor poderia adivinhar senhas, o número de contas desbloqueadas que você tem e algumas informações informadas sobre seus riscos.

Espero que você tenha algum tipo de limite de taxa para a adivinhação de senha. Normalmente, isso seria feito por meio de algo que bloqueia temporariamente as contas após um certo número de senhas incorretas.

E esperamos que você tenha algum tipo de requisito de complexidade de senha para que "A" e "senha" não sejam permitidos.

Vamos supor que, após 30 falhas de senha em 10 minutos, você bloqueará uma conta por 20 minutos. Isso limita efetivamente a taxa de estimativa de senhas para 174 por hora, ou 4176 por dia. Mas vamos supor que seja por usuário.

Vamos supor que você precise de senhas com mais de 8 caracteres contendo letras maiúsculas, minúsculas e um número, e que faça algumas verificações de dicionário para garantir que essas senhas sejam razoavelmente aleatórias. Na pior das hipóteses, todos os usuários colocam a parte superior e um número no mesmo local, e o invasor sabe disso, portanto, você tem 10 * 26 ^ 7 (80G) possíveis senhas. O melhor caso é 62 ^ 8 (218T).

Assim, um invasor que esteja tentando todas as senhas possíveis atingiria todas elas dentro de 50.000 anos no pior caso, e quase 600 milhões de milênios no melhor dos casos. Ou, para colocar de outra forma, dado um ano, eles teriam entre 1 em 50.000 e 1 em 52.000.000.000 de adivinhação. Se você tem uma base de usuários de 50.000, é quase certo que na pior das hipóteses eles entrariam em uma conta por ano e teriam 50% de chance de conseguir uma conta a cada 6 meses.

E se você não tivesse limite de taxa e um invasor pudesse adivinhar um bilhão de senhas por dia? Uma chance em 600 de entrar em uma conta em um ano, ou uma garantia virtual de receber cerca de 80 dos seus 50.000 usuários a cada ano.

Trabalhe nessa matemática e descubra onde está seu nível de risco aceitável. E lembre-se de que quanto mais curto você definir, mais difícil será para os usuários lembrarem e mais provavelmente eles serão escritos em algum lugar conveniente para um invasor no local.

Como um bônus adicional: se alguém está testando milhares de senhas por usuário por dia contra seus sistemas, eu realmente espero que você tenha algum tipo de monitoramento que o identifique.

EDITAR: Esqueci de mencionar: nossa política atual é de 90 dias, mas isso tem tudo a ver com descobertas de auditores de segurança equivocados e nada a ver com a realidade.

    

Answer 3

90 dias parece ser suficiente para a maioria dos cenários. Minha maior preocupação é a complexidade das senhas. Mais do que a questão do prazo na geração de notas post-it é a complexidade forçada. Uma coisa é evitar as palavras do dicionário e outra para ter caracteres especiais, mas quando você começa a dizer que nenhum personagem pode repetir ou estar em ordem crescente / decrescente, você dificultou a vida dos seus usuários. Acrescente isso a uma vida curta de senha e você acabou de receber mais problemas.

    

Answer 4

A expiração da senha é irritante e reduz a segurança.

A expiração de senha defende-se contra a situação em que um invasor já comprometeu a senha de um usuário, mas não possui um mecanismo para descobrir o que é em uma base contínua (por exemplo, keylogger)

No entanto, também torna mais difícil lembrar senhas, aumentando a probabilidade de que os usuários as anotem.

Como a defesa contra uma senha já comprometida não é realmente necessária (você espera), considero a expiração da senha inútil.

Faça com que os usuários escolham uma senha strong para começar; Encoraje-os a lembrarem-se disso, e não exija que eles o modifiquem, ou eles acabarão por escrevê-los em todos os lugares.

    

Answer 5

Se você tiver um dispositivo que precise de garantias de segurança "alta a ultra-alta", será melhor usar um token de hardware que gere senhas de uso único em vez de confiar em expirações de senha.

O principal "ganho" para um sistema de expiração de senha é que você eventualmente terá uma conta desabilitada se o proprietário da conta deixar a organização, como um "cheque e saldo" extra para "a conta deve ser desabilitada quando o o titular da conta sai ".

Garantir a expiração de senhas leva, na melhor das hipóteses, a senhas de alta qualidade escritas e, no pior dos casos, a senhas incorretas (em um local de trabalho anterior, quando fomos forçados a usar a expiração de senha, acabamos usando (essencialmente) prefixJan2003, prefixFeb2003 e assim por diante, já que meu método preferido de gerar senhas (48 bits aleatórios, codificados em Base64) não é escalável para "novas senhas a cada mês".

    

Answer 6

Acho que se você perguntar a 10 profissionais de segurança diferentes essa pergunta, você receberá 10 respostas diferentes.

Isso depende muito de quão crítico é o ativo que a senha protege.

Se você tiver um ativo altamente seguro, precisará definir sua política de expiração de senha com a brevidade suficiente para que qualquer intruso externo não tenha tempo de usar uma senha brutalmente obrigatória. Outra variável nessa situação é o nível de complexidade exigido nas senhas.

Para sistemas de segurança baixos a médios, acho que uma política de expiração de 6 meses é muito justa.

Para segurança de alto nível, acho que um mês seria melhor - e para instalações 'ultra' seguras, seriam esperados períodos de tempo ainda menores.

    

Answer 7

Impingimos uma expiração de senha de 90 dias para todos aqui (incluindo nós mesmos).

Principalmente porque é simplesmente uma prática recomendada. As chances de alguém usar uma senha "fraca" versus uma mais strong são maiores e quanto mais você a deixar, isso possivelmente resultaria em uma violação de segurança não detectada a longo prazo.

    

Answer 8

Nós expiramos as senhas anualmente e exigimos senhas strongs (de preferência aleatórias) com mais de 10 caracteres. Nós executamos ataques de dicionário nas senhas das pessoas quando elas são alteradas. Mantemos os hashes de senha passados para que as senhas não possam ser reutilizadas. Também verificamos possíveis datas na senha, como disse vatine. ;) A última foi minha adição ...

Em um trabalho anterior, tentamos expirar com mais frequência a pedido de um novo administrador de segurança de rede - a cada dois meses. Duas semanas depois da primeira mudança forçada, levei-o para os escritórios administrativos e examinamos os teclados e os mousepads das pessoas. Mais de 50% deles tinham uma senha escrita em um post-it embaixo. Ele ficou feliz em afrouxar a política depois que nos sentamos e conversamos com a equipe administrativa - a opinião deles era que eles não tinham tempo suficiente para memorizar.

Hoje em dia, a maioria das nossas coisas é de login único em alguns silos. Os recursos do campus (raramente usados pela maioria das pessoas) estão em um silo e essa senha é gerenciada pelo nosso grupo central de TI. Recursos departamentais (usados diariamente - login de máquina, email, edição de site, fotocopiadora) é uma senha gerenciada por nosso grupo, também expirada anualmente. Se as pessoas se queixam de estarem frustradas, salientamos que elas realmente só têm uma senha para lembrar.

Hoje em dia, eu gero um md5sum em um arquivo aleatório em / var / log e uso um subconjunto delas para minhas senhas.

    

Answer 9

Tivemos muitas discussões sobre isso alguns anos atrás, quando começamos uma política de expiração de senha. Nós tínhamos acabado de terminar uma corrida de 10 graus com tabelas de arco-íris contra a árvore AD para ver o quão ruim era, e foi bem horrível. Um grande número de usuários ainda usava a senha do "helpdesk temp" depois de ligar / desligar para uma redefinição de senha, algo horrível como 30% usavam "senha" ou alguma variante como senha (p @ $$ w0rd, etc) . Isso convenceu a gerência de que isso precisava acontecer.

Sendo mais experiente, tivemos de enfrentar o verão ao selecionar um intervalo. Muitos dos nossos professores não ensinam durante o verão, então nosso helpdesk teve que se preparar para as chamadas "Esqueci minha senha", já que todas elas voltam em setembro. Eu acho, e posso estar errado, que nosso intervalo é de 6 meses com uma exceção de trimestre de verão. Portanto, se sua expiração da senha de 6 meses expirar em meados de agosto, ela será reprogramada aleatoriamente para ser redefinida no final de setembro até o início de outubro.

Uma pergunta melhor é com que frequência sua conta de utilitário e senhas de administrador são rotacionadas. Com demasiada frequência, esses parecem ficar isentos de políticas de alteração de senha. Quem quer passar por todos esses scripts para uma alteração de senha da conta do utilitário? E alguns sistemas de backup dificultam a troca de senhas usadas, o que desestimula a troca de senhas de administrador.

    

Answer 10

Um grande problema com a expiração de senha frequentemente é que as pessoas terão dificuldades para se lembrar delas, assim você terá pessoas usando senhas fracas ou semelhantes, ou se sua política não permitir isso, elas começarão a escrever as senhas para ajude a lembrá-los. Você também terá mais solicitações de alteração de senha, quando as pessoas as esquecerem.

Pessoalmente, isso depende do uso da senha, mas não guardo uma senha por mais de três meses, a menos que seja uma conta descartável completa. Para coisas de maior risco, todo mês é bom, e desafiadoramente, mude-o se alguém mais o conhece. Como trabalho em uma pequena empresa de suporte a computadores, temos várias senhas compartilhadas entre muitas pessoas, por isso não queremos alterá-las com muita frequência, devido à interrupção que isso pode causar.

    

Answer 11

Comentários interessantes até agora. É claro, por que é sempre debatido que lembrar senhas é uma questão de pessoal técnico versus pessoal não técnico em uma empresa? O que a habilidade de alguém com hardware / software de computador tem a ver com sua capacidade de levar a segurança a sério? Será que uma pessoa não técnica dará seu cartão de crédito ou de débito? Além disso, as pessoas que colocam senhas em notas post-it em sua mesa devem ser motivo para demissão. É incrível como a memória das pessoas vai melhorar quando eles realmente percebem a segurança é importante e deve ser levada a sério. Não vejo nada diferente que o papel dos códigos de vestimenta e das políticas de conduta no trabalho. Siga as regras ou adeus!

    

Answer 12

Acho que ter uma senha mais segura é muito mais importante do que alterá-la com frequência, mas ambas são definitivamente necessárias para um sistema seguro.

O argumento é que senhas complexas são difíceis de lembrar e levam os funcionários a escrevê-las. Minha opinião sobre isso é que a grande maioria dos ataques vem de fora , e até mesmo escrever uma senha complexa e gravá-la no monitor é mais seguro do que ter uma senha simples memorizada.

    

Answer 13

Estou implementando um protocolo único e autenticação baseada em token de tempo, portanto, em teoria, toda vez que o usuário efetua login.

Embora isso seja indiscutivelmente fora de tópico, um bloco único parece ser uma solução superior.

Da mesma forma, e basicamente, garantindo que o usuário crie uma senha strong e entenda a ética por trás de sua política de segurança (não anote, não faça aniversário, não ofereça a ninguém) vai muito mais longe do que simplesmente forçá-los a mudá-lo a cada enésimo intervalo baseado em tempo.