Tendo acabado de receber um email de um fornecedor nos informando que eles nos forçariam a alterar nossa senha a cada seis meses, estou curioso para saber quais políticas de expiração de senha as pessoas usam e por que as usam.
Respostas:
Há uma linha tênue aqui entre nunca mudar e mudar 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 alterá-la com muita frequência também tem efeitos colaterais ruins. Um local em que trabalhei, forçou todos os usuários da rede interna a alterar senhas a cada 6 semanas e a senha não poderia ser a mesma das seis senhas anteriores. Três senhas erradas bloquearam a estação de trabalho e a equipe de TI precisou desbloqueá-la. O que resultou em todo mundo escrevendo a senha em post-it pendurado na tela ou colocado na gaveta. Pesadelo.
Eu diria que alterar a senha a cada 6 meses deve ser suficiente. Isso evitará as temidas post-its.
Eu sugeriria que empregasse um pouco de matemática que levasse em conta sua complexidade mínima de senha, a rapidez com que um invasor poderia adivinhar senhas, o número de contas desbloqueadas e algumas informações informadas sobre seus riscos.
Espero que você tenha algum tipo de limitação de taxa para adivinhação de senha. Normalmente, isso seria feito através de algo que bloqueia temporariamente as contas após um certo número de senhas ruins.
E espero 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ê bloqueie uma conta por 20 minutos. Isso limita efetivamente a taxa de tentativa de senha a 174 por hora ou 4176 por dia. Mas vamos assumir que é por usuário.
Vamos supor que você exija senhas com mais de 8 caracteres que contenham maiúsculas, minúsculas e um número e que você faça algumas verificações no 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 lugar e o invasor sabe disso, então você tem 10 * 26 ^ 7 (80G) de senhas possíveis. O melhor caso é 62 ^ 8 (218T).
Portanto, um invasor que tentasse 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 caso. Ou, em outras palavras, dado um ano, eles teriam entre 1 em 50.000 e 1 em 52.000.000.000 de adivinhações. Se você tem uma base de usuários de 50.000, é quase garantido que, na pior das hipóteses, eles entrem em uma conta por ano e tenham aproximadamente 50% de chance de obter 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 obter cerca de 80 dos seus 50.000 usuários por ano.
Trabalhe nessa matemática e descubra onde está o seu nível de risco aceitável. E lembre-se de que quanto mais curto o definir, mais difícil será para os usuários se lembrarem e mais provavelmente eles o escreverão em algum lugar conveniente para um invasor no local.
Como um bônus adicional: se alguém estiver tentando milhares de senhas por usuário por dia nos seus sistemas, eu realmente espero que você tenha algum tipo de monitoramento que identifique isso.
EDIT: Esqueci de mencionar: nossa política atual é de 90 dias, mas isso tem tudo a ver com as descobertas de auditores de segurança equivocados e nada a ver com a realidade.
90 dias parece ser suficiente para a maioria dos cenários. Minha maior preocupação é a complexidade da senha. Mais do que o problema de prazo na geração de post-its é a complexidade forçada. Uma coisa é evitar as palavras do dicionário e outra ter caracteres especiais, mas quando você começa a dizer que nenhum personagem pode se repetir ou estar em ordem crescente / decrescente, você dificulta a vida dos usuários. Adicione isso a uma vida útil curta da senha e você será bem-vindo em mais problemas.
A expiração de senha é irritante e reduz a segurança.
A expiração de senha se defende contra a situação em que um invasor já comprometeu a senha de um usuário já, mas não possui um mecanismo para descobrir o que é continuamente (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 inútil a expiração da senha.
Faça com que os usuários escolham uma senha forte para começar; incentive-os a se lembrarem, e não exija que eles mudem, ou eles acabarão anotando-os em todos os lugares.
Se você possui um dispositivo que precisa de garantias de segurança "alta a ultra alta", é melhor usar um token de hardware que gere senhas únicas em vez de confiar em expirar a senha.
A principal "vitória" para um sistema de expiração de senha é que, eventualmente, você terá uma conta desativada se o titular deixar a organização, como um "cheque e saldo" adicionais para "a conta deve ser desativada quando o titular da conta folhas".
A aplicação da expiração de senha leva, na melhor das hipóteses, a senhas de alta qualidade anotadas e, na pior das hipóteses, a senhas ruins (em um local de trabalho anterior, depois que fomos forçados a usar a expiração de senha, acabei usando (essencialmente) prefixo Jan2003, prefixoFeb2003 e assim por diante como meu método preferido de geração de senhas (48 bits aleatórios, codificado em Base64) não é dimensionado para "novas senhas todos os meses").
Eu acho que se você perguntar a 10 profissionais de segurança diferentes essa pergunta - você obterá 10 respostas diferentes.
Isso depende muito de quão crítico é o ativo que a senha está protegendo.
Se você possui um ativo altamente seguro, precisa definir sua política de expiração de senha suficientemente curta para que qualquer intruso externo não tenha tempo para fazer força bruta em uma senha. Outra variável nessa situação é qual nível de complexidade é necessário nas senhas.
Para sistemas de segurança de baixa a média, 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 mais curtos.
Nós aplicamos uma validade de senha de 90 dias a todos aqui (incluindo a nós mesmos).
Principalmente porque são simplesmente boas práticas. As chances de alguém usar uma senha "fraca" em comparação com uma senha mais forte são maiores e, quanto mais tempo você deixar a mesma, possivelmente resultará em uma violação de segurança não detectada a longo prazo.
Expiramos senhas anualmente e exigimos senhas fortes (de preferência aleatórias) com mais de 10 caracteres. Executamos ataques de dicionário às senhas das pessoas quando elas são alteradas. Mantemos hashes de senhas antigos para que as senhas não possam ser reutilizadas. Também checamos possíveis datas na senha, como disse vatine. ;) A última foi a 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 após a primeira mudança forçada, eu o levei pelos nossos 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 por 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.
Atualmente, a maioria de nossas coisas é de logon único em alguns silos. Os recursos do campus (raramente usados para a maioria das pessoas) estão em um silo e essa senha é gerenciada pelo nosso grupo central de TI. Os recursos departamentais (usados diariamente - login na máquina, email, edição de sites, fotocopiadora) são uma senha gerenciada pelo nosso grupo, que também expira anualmente. Se as pessoas reclamam de estar frustradas, destacamos que elas realmente têm apenas uma senha para lembrar.
Hoje em dia, eu gero um md5sum em um arquivo aleatório em / var / log e uso um subconjunto para minhas senhas.
Tivemos muitas discussões sobre isso alguns anos atrás, quando iniciamos uma política de expiração de senha. Nós tínhamos acabado de terminar uma corrida de lfphcract com tabelas arco-íris contra a árvore do AD para ver o quão ruim era e era horrível. Um número preocupante de usuários ainda usava sua senha "temp do helpdesk" após ligar / soltar para redefinir a senha, algo horrível como 30% usava "password" ou alguma variante como senha (p @ $$ w0rd, etc.) . Isso convenceu a gerência de que isso precisava acontecer.
No ensino superior, tivemos o verão para enfrentar ao selecionar um intervalo. Muitos de nossos professores não ensinam durante o verão, então nosso serviço de assistência teve que se preparar para as chamadas "esqueci minha senha" quando elas voltaram em setembro. Penso e posso estar errado, que o nosso intervalo é de 6 meses, com uma exceção no trimestre de verão. Portanto, se a validade da sua senha de 6 meses expirar em meados de agosto, ela seria reprogramada aleatoriamente para redefinir no final de setembro até o início de outubro
Uma pergunta melhor é com que freqüência sua conta de utilitário e senhas de administrador são giradas. Com muita freqüência, esses parecem ficar isentos das políticas de alteração de senha. Quem quer passar por todos esses scripts para obter uma alteração na senha da conta do utilitário? E alguns sistemas de backup dificultam a alteração de senhas usadas, o que desestimula a alteração de senhas de administrador.
Um grande problema com a expiração de senhas com frequência é que as pessoas se esforçam para lembrá-las; portanto, você terá pessoas que usam senhas fracas ou semelhantes ou, se sua política não permitir isso, elas começarão a escrever as senhas para ajudar a lembrá-las. . Você também terá mais solicitações de alteração de senha, quando as pessoas as esquecerem.
Pessoalmente, depende do uso da senha, mas eu não a mantenho por mais de três meses, a menos que seja uma conta descartável completa. Para coisas de maior risco, todos os meses é bom, e mude-a desafiadoramente se alguém que a conhece sair. 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.
Comentários interessantes até agora. Claro, por que sempre se debate que a lembrança de senhas é um problema técnico versus não técnico em uma empresa? O que a capacidade de alguém com hardware / software de computador tem algo a ver com a capacidade de levar a segurança a sério? Uma pessoa não técnica distribuirá seu cartão de crédito ou pinos de débito #? Além disso, as pessoas que colocam senhas em post-its em suas mesas devem ser motivos de demissão. É incrível como a memória das pessoas melhorará quando elas realmente perceberem que a segurança é importante e deve ser levada a sério. Não vejo diferença quanto ao papel dos códigos de vestuário e da política de conduta no trabalho. Siga as regras ou adeus!
Penso que ter uma senha mais segura é muito mais importante do que alterá-la frequentemente, 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 é que a grande maioria dos ataques vem de fora , e até mesmo escrever uma senha complexa e colá-la no monitor é mais segura do que ter uma senha simples memorizada.
Estou implementando autenticação única com base em token e time-token, portanto, teoricamente, toda vez que o usuário efetua login.
Embora isso seja indiscutivelmente fora de tópico, uma solução única parece ser uma solução superior.
Da mesma forma, e mais basicamente, garantir que o usuário crie uma senha forte e compreenda a ética por trás de sua política de segurança (não anote, não faça aniversário, não dê a ninguém) mais do que simplesmente forçá-los a alterá-lo a cada enésimo intervalo de tempo.