Devo forçar meus usuários a alterar as senhas a cada n dias / semanas / mês?

Question

A questão diz tudo. Estamos projetando um sistema em que a segurança é muito importante. Uma das ideias que alguém teve foi forçar os usuários a mudarem as senhas a cada 3 meses. Minha opinião sobre isso é que, embora seja mais seguro porque a senha muda com frequência, isso também força nossos usuários a lembrar de alterações de senhas e torna mais fácil que eles simplesmente a escrevam em algum lugar para ajudar a lembrar.

Na mesma ideia, é realmente bom forçar os usuários a usar uma senha super difícil de adivinhar. Obrigue-os a usar% &% e letras minúsculas em maiúsculas. Eu sei que é bastante complicado inventar uma senha e depois lembrar dela.

Então, novamente, não queremos ninguém usando 12345.

Existe algum whitepaper sobre este assunto? Boa prática?

Estou falando de um site criado com PHP. MySQL em um ambiente de lâmpada, se isso mudar alguma coisa.

    

Answer 1

Acho que posso estar em minoria nisso (com base em minha experiência limitada em lidar com departamentos de TI na escola e no trabalho), mas acho que políticas obrigatórias de mudança de senha baseadas em tempo são inúteis e prejudiciais na pior das hipóteses. As pessoas tendem a ser muito ruins em escolher boas senhas e mantê-las em segredo. As políticas de expiração de senha são projetadas para mitigar isso limitando a quantidade de tempo que qualquer senha pode ser violada / engenharia social / roubo; no entanto, eles não conseguem isso na prática, principalmente porque forçam os usuários a reaprender sua senha continuamente. Ao dificultar que o usuário consolide suas senhas na memória, você acaba fazendo com que muitas delas escolham senhas mais fracas e / ou escrevam suas senhas em algum lugar onde olhos curiosos possam encontrá-las.

Além disso, quando for forçado a alterar sua senha regularmente, muitos usuários escolherão senhas que seguem um padrão muito reconhecível, como [base string][digit] . Digamos que um usuário queira usar o nome de seu gato, Fluffy, como senha. Eles podem começar com uma senha de fluffy e, em seguida, alterá-la para fluffy1 , fluffy2 , fluffy3 e assim por diante. Nesse caso, a política não ajuda realmente a segurança; mesmo que o usuário escolha uma string base mais segura do que fluffy , e mesmo se mantiver sua senha memorizada com segurança, o único caractere de sufixo que muda a cada poucos meses faz muito pouco para mitigar ataques de crack ou engenharia social.

Veja também: Expiração da senha considerada prejudicial , um pequeno artigo (não escrito por mim) que, na minha opinião, uma boa introdução para esses problemas.

    

Answer 2

Minha grande organização (mais de 15.000 usuários) implementou "alterações de senha" a cada 120 dias no outono de 2009. É uma grande dor de cabeça de TI e desperdício de recursos de suporte. Toda vez que a janela de 120 dias se aproxima, temos milhares de usuários forçados a mudar sua senha ... o que muitos deles fazem incorretamente e bloqueiam sua conta ... ou esquecem o dia seguinte. Nosso helpdesk fica sobrecarregado com chamadas de senha, embora tenhamos tentado fazer o máximo possível de autoatendimento.

Se você quiser que seus usuários / clientes odeiem você ... e sua equipe de TI da linha de frente para queimá-lo na efígie, sempre que possível ... implemente alterações de senha.

Políticas de mudança de senha são uma caixa de seleção em algum gerente de TI, como reservar em algum lugar ... e foi escrita há 15 anos. Ninguém nas trincheiras que realmente implementa ou apóia a política dirá a você que é uma boa idéia.

Eu argumentei aqui por "frases secretas" em vez de senhas ... muito boas que fizeram ... aquela luz no fim do túnel era um trem que se aproximava. :)

Uma passphrase é uma string longa e quase irreversível, muito fácil de lembrar, como "MyCatIsFromSpainAndICallHimElGato". Ou talvez uma frase de um poema ou música.

Se você quiser fazer com que seja realmente difícil de decifrar ... mexer com o caso, adicionar alguma pontuação, mudar alguns para ells, ohs para zeros, a para @, etc ... Mas mantenha-se lembrar-capaz .... essa é a chave. Há até mesmo maneiras de pegá-los para que eles fluam facilmente de seus dedos para o teclado ... para que você não esteja pulando entre as mãos ou com SHIFTs e pontuações estranhas.

Então ...

• Use longas "frases secretas".
• Teste-os internamente quanto à força.
• Implemente o "logon único" em toda a sua infraestrutura para que os clientes só precisem usá-lo uma ou duas vezes por dia.
• Nunca force-os a mudá-lo.
• E educar, educar, educar em seu uso adequado.

Matt

EDIT: 8/24/2011 XKCD concorda e disse que melhor do que Eu fiz.

    

Answer 3

Não. Minha opinião pessoal é que é desnecessário e até mesmo contraproducente . Eu briguei com o meu blog, mas você pode caçar se estiver interessado.

Em resumo, isso se resume a dois motivos:

1. Forçar um usuário a alterar constantemente sua senha leva a senhas incorretas.

Não haverá escassez de evidência anedótica sobre isso, mas faz sentido que, se sou forçado a lembrar de uma coisa nova a cada x dias, tornarei essas coisas fáceis de lembrar e, provavelmente, relacionadas umas às outras.

É muito mais provável que os usuários escolham senhas "previsíveis", como "Jan2010" ou "Password05", se souberem que precisará mudar em breve. É muito provável que impor uma política rígida aos caracteres apenas resulte em um ponto de exclamação ou em um nome totalmente escrito em vez de uma abreviação. Há uma grande diferença entre uma senha tecnicamente complexa e uma que não seja adivinhada.

2. Forçar mudanças de senha regulares não impede ataques, apenas reduz o risco (e não muito)

Pense nisso - se sua senha for adivinhada ou descoberta de alguma forma, quanto tempo levaria um invasor para usar essa informação? Coloque-se no lugar do atacante. Você acabou de descobrir uma senha. Você não entraria e extrairia toda informação que pudesse imediatamente para o caso de alguém descobrir? Em 30 dias, você já tem tudo o que deseja.

Minha recomendação:

• Forçar uma política de senha extremamente rígida (como 15 caracteres com letras maiúsculas e minúsculas, números e caracteres especiais, sem palavras em inglês > 3 caracteres)
• Nunca faça o usuário alterar sua senha. Se eles tiverem que escrever a senha em um pedaço de papel e guardá-la na carteira, está tudo bem. As pessoas são boas em conseguir pedaços de papel, mas não tão boas em lembrar de seqüências aleatórias de caracteres.

Answer 4

Do ponto de vista do usuário, ter que alterar minha senha é incrivelmente inconveniente. Eu absolutamente odeio ter que fazê-lo, e vou apenas relutantemente usar sites que eu absolutamente preciso se eles precisarem que eu mude minha senha.

Também tem havido alguma discussão sobre se isso é realmente uma boa prática, já que algumas pessoas acabam tendo que anotar suas senhas para se lembrar delas.

Você poderia implementar um desses widgets que mostre às pessoas quão strong (ou fraca) é sua senha enquanto a preenchem - eu acho que essas são (sorta) úteis, embora eu não saiba se elas realmente resultar em senhas mais strongs.

    

Answer 5

Como usuário de um ambiente de política de senha bastante estrito ("super difícil de adivinhar senhas" e alteração de senhas), minha opinião é que apenas a senha de hardware é necessária. Apesar de demorar um pouco para os usuários se acostumarem com ele (especialmente se eles são do tipo 12345), eles devem ser capazes de recuperá-lo e digitá-lo facilmente dentro de uma semana.

No entanto, posso prever usuários finais desconfortáveis se você tiver senhas strongs e forçá-las a mudar.

    

Answer 6

Do ponto de vista de administração de TI, sua melhor opção é investigar a possibilidade de permitir que seu aplicativo use os recursos de logon único do esquema de autenticação existente que seus clientes estão usando. Obviamente, o Active Directory é um grande player, mas se o seu aplicativo funciona com a política que a TI local já configurou, você não precisa se preocupar em reinventar a roda.

Desde que surgiu muito debate sobre se as alterações na senha impostas são ou não uma boa ideia (embora eu ache que isso é secundário em relação à sua pergunta principal), achei que você poderia gostar de algumas das ideias & links aqui . Para a maioria das situações, se você não for impor uma complexidade de senha & Mudança de horário, você pode não ter senhas - mas o modo implementado (treinamento, suporte de gerenciamento, etc) é mais importante do que eu posso enfatizar.

    

Answer 7

A alteração de senhas geralmente pode levar o usuário a anotá-las. O que não é uma idéia tão ruim de acordo com Bruce Schneier ( link ).

Eu diria que ter a segurança atrapalhando a usabilidade pode ser uma coisa boa, só porque lembra o usuário de agir com segurança. Por exemplo, no banco onde eu trabalho, muitas das medidas de segurança em vigor são teatro de segurança (por exemplo, reconhecimento facial na porta, mas o cara da segurança abrirá a porta para você se o reconhecimento falhar). Embora essas medidas não melhorem a segurança por si mesmas, elas estão sempre lá para nos lembrar que a segurança é uma preocupação importante no trabalho, que há uma certa quantidade de registro e verificação em andamento e que, se você for pego fazendo algo "inseguro" estará em apuros.

É claro que isso se aplica à segurança dos funcionários de um banco, pode não se aplicar aos usuários do seu site ...

    

Answer 8

Você deve forçar seus usuários a mudar a cada n dias se sua política de segurança exigir isso. Eu trabalho para uma agência do Estado, e esta é uma exigência imposta pelo escritório do Auditor do Estado. Eu não posso fazer nada sobre isso, então eu tenho que forçar mudanças.

Se você não estiver limitado por regulamentações para forçar alterações de senha, não as force. Certifique-se de que as senhas configuradas atendem a determinados requisitos mínimos de complexidade. O tamanho supera a complexidade para a maioria dos sistemas de senha, portanto, um padrão de variável é o melhor caso, na minha opinião. Tais como:

• Nenhuma senha deve ter menos de 10 caracteres.
• As senhas entre 10 a 25 caracteres exigem pelo menos três conjuntos de caracteres.
• As senhas entre 25 e 40 caracteres exigirão pelo menos dois conjuntos de caracteres.
• Senhas com mais de 40 caracteres podem usar um único conjunto de caracteres.

Os esquemas de complexidade incorporados para coisas como o Active Directory não suportam esse tipo de sistema em camadas. Se você criar seu próprio ambiente de alteração de senha, poderá fazer coisas como essa. Como cada uso da tecla Shift aumenta a probabilidade de um evento finger-finger, senhas longas com vários conjuntos de caracteres são MUITO mais prováveis de incorrer em eventos de login com falha, especialmente durante os estágios de aprendizado. Se você tiver um sistema de bloqueio de conta, isso pode ser um grande problema. Para a pessoa que usa a terceira linha do seu poema favorito (63 caracteres!) Como frase-senha, não ter que fazer h @ x0r, torna a entrada rápida e eficiente.

Caso a tecnologia ou o ambiente de risco mude significativamente e suas senhas não sejam tão complexas quanto deveriam ser, coloque uma maneira de expirar as senhas ao longo de um período de tempo. As pessoas vão reclamar da necessidade, especialmente se você nunca forçou uma mudança antes, mas isso ajudará você a manter sua postura de segurança.

    

Answer 9

Difícil adivinhar senhas é uma coisa boa. Impor níveis de complexidade que resultam em usuários esquecendo suas senhas ou tendo que escrevê-los é uma coisa ruim, porque qualquer segurança obtida pela complexidade é completamente perdida no processo. Em um mundo ideal (que infelizmente não é onde moramos), deve haver um equilíbrio entre complexidade e usabilidade. É claro que pessoas diferentes verão esse ponto de equilíbrio em lugares diferentes.

A lógica por trás da alteração regular de senhas em X dias é um pouco perdida para mim. A razão pela qual eu geralmente ouço isso é para limitar a utilidade de uma senha roubada, à qual eu respondo que qualquer dano real quase certamente será feito dentro das primeiras horas de qualquer maneira. por exemplo. Fred "se familiariza com a senha de Mary". A menos que isso aconteça quase ao mesmo tempo em que Mary está mudando a senha, que diferença faz se for alterada amanhã ou no próximo mês? É realmente provável que Fred espere mais uma semana ou duas antes de usar a senha (supondo que essa foi a intenção o tempo todo)?

Obviamente, trocar as senhas se houver qualquer razão ou suspeita de que isso possa ser necessário é um assunto totalmente diferente.

    

Answer 10

Se o aplicativo precisar de um nível tão alto de segurança, você considerou usar algo como tokens SecurID? Isso significa que o usuário recebe uma nova senha a cada 60 segundos; você não precisa se preocupar com eles usando senhas de escrita. No entanto, estes custam dinheiro. Quão segura é a solução?

    

Answer 11

Acho que a informação para os usuários é importante. Explique a eles como criar uma senha e como é importante não usar a mesma senha duas vezes. Uma maneira fácil de criar uma senha é pegar uma frase e pegar a primeira letra de cada palavra e adicionar alguns números.

Eu gosto de governar o mundo = Iltrw99

Não os obrigue a alterar a senha, isso apenas os confundirá.

    

Answer 12

Embora eu não concorde com a alteração de senhas a cada três meses, isso é um requisito se sua empresa for negociada publicamente e fizer parte de ser compatível com SOX. Nota lateral: Sarbanes-Oxley é uma merda.

    

Answer 13

Algo que eu não vi mencionado é o acesso externo a recursos.

Eu tenho a tendência de concordar que, se você escolher uma política sensata de senha, a menos que alguém a anote, é provável que ninguém adivinhe essa senha.

No entanto, digamos que você tenha um webmail acessível externamente, agora é possível que os usuários digitem suas credenciais em "qualquer PC antigo" e IMO que aumente o risco dos dados corporativos colocados por spyware / malware / trojans e outros que possam cheirar / roubar essas senhas.

    

Answer 14

Se as pessoas escrevem senhas simples, o que faz você pensar que não vai escrever uma frase-senha enorme ou uma senha super complicada. O que as alterações de senha incrementais realizam é uma eliminação de ID do usuário que não está mais em uso automaticamente e permite que o usuário individual tenha alguma responsabilidade em tudo isso. As pessoas vão ser pessoas, procurando o caminho fácil para realizar alguma coisa; senhas repetidas e senhas incrementalmente alteradas podem ser detectadas e negadas. Os requisitos de complexidade podem ser reforçados, alterações forçadas de senha também podem abrir os olhos de usuários que não são de TI para sua responsabilidade em tudo isso. A maioria dos usuários que se queixam da mudança de senha é a pessoa preguiçosa que finge mudar sua senha é como uma cirurgia de coração aberto. Pare de reclamar, seja responsável e pare de tentar encontrar uma rua fácil ou procure um novo emprego com os requisitos "relaxantes" ...