por Fernando Cima
Existe já uma extensa literatura na Internet orientando os usuários a escolherem suas senhas (conflitantes por sinal - afinal é uma boa coisa o usuário anotar a senha em um papel?) por isso não vamos repisar este tema aqui. Vamos falar aqui do outro lado - como definir a política de senhas apropriada para a sua aplicação ou rede.
Primeiro é bom lembrar que a política de senhas é um controle de segurança, e antes de defini-la você deve entender exatamente quais são os riscos que você quer mitigar com a senha - que dependem diretamente do valor do que está sendo protegido com a senha, e dos demais controles de acesso que existem adicionalmente além da própria senha. Por exemplo, a política de senhas para um sistema restrito a consultas não precisa ser tão rígida quanto a de um sistema que comanda transações, e os meu PIN number usado junto com o smartcard não tem que ser tão rígido quanto a minha senha de logon.
Também é necessário entender contra o quê estamos nos protegendo ao estabelecer uma política de senhas. Ao contrário do que normalmente se pensa, não queremos só evitar ataques por força bruta ou por dicionário. Queremos evitar também que o usuário esqueça a senha e tenha que resetá-la - segundo o Gartner 30% dos chamados de Help Desk são resets de senha, cada um levando em média 20 minutos para resolver. Em resumo, precisamos de senhas que sejam difíceis de adivinhar mas fáceis de lembrar.
Dito isso, vamos ao que eu considero ser as melhores práticas a serem utilizadas na hora de definir sua política:
Tamanho mínimo da senha e Complexidade da senha: A exigência de um tamanho mínimo e a de complexidade (i.e. a presença de letras, números, símbolos e maiúsculas/minúsculas) são a principal defesa contra ataques de força bruta ou dicionário. As duas juntas garantem um nível de variação - ou entropia - mínimo para tornar um ataque de força bruta demasiado caro ou mesmo inviável.
A configuração de complexidade default do Active Directory exige que a senha tenha pelo menos três símbolos de quatro categorias (maiúsculas, minúsculas, algarismos e caracteres não-alfanuméricos) e não contenha nem o primeiro nem o último nome do usuário. Isso deve ser suficiente para a maioria das organizações - pode ser implementado no entanto um critério particular através de passwords filters.
Mas como balancear a complexidade da senha com a necessidade dela ser facilmente lembrada pelos usuários? Orientando o uso de frases secretas ao invés de senhas curtas mais ininteligíveis. Por exemplo, a senha Eu compro pão na 111N tem mais entropia do que dce*(1%& e é muito mais fácil de ser lembrada. Não aceite a velha desculpa de que os usuários não vão conseguir lembrar as senhas e por isso não dá para forçar senhas complexas - a experiência no mundo real prova o contrário.
Troca periódica da senha: Gene Spafford argumenta que forçar a troca da senha periodicamente acrescenta muito pouco em termos de segurança. A origem da troca periódica de senha está no tempo em que o poder computacional para fazer o ataque de força bruta contra uma senha era limitado, e fazia sentido trocar a senha em um prazo menor do que o tempo que em tese seria gasto fazendo o ataque. Nos dias de hoje com o poder computacional existente em um cluster (ou em uma botnet) esse cálculo não faz mais muito sentido, e forçar uma troca periódica muito freqüente cria mais chamadas no Help Desk do que proteção adicional.
Trocas periódicas de senha têm no entanto um outro benefício - elas são ótimas para você encontrar contas de usuário que não são mais utilizadas (stale accounts) e deveria ter sido desabilitadas ou removidas. Eu recomendaria colocar a troca periódica na política de senhas, mas em um prazo maior, talvez a cada três ou quatro meses.
Não repetição das últimas senhas: Usado para impedir que o usuário "troque" a senha e continue com a mesma. Não vejo contra indicações em definir um limite alto para esta - o default no Windows são as últimas 24 e parece adequado.
Prazo mínimo de troca de senhas: Serve em tese para impedir que o usuário troque a senha seguidas vezes, ultrapassando o limite estabelecido para não repetir as últimas senhas, e voltando para a senha anterior. Tem no entanto um efeito colateral: se o usuário trocou a senha e ele não se sentiu confortável (ou mesmo foi vista por uma outra pessoa), ele terá que esperar o prazo mínimo ou chamar o Help Desk para poder fazer uma nova troca. Por mim não vale a pena definir este prazo - se alguém teve a pachorra de trocar a senha 24 vezes seguidas para continuar com a anterior, então merece ficar com ela!
Bloqueio de contas: Bloquear o acesso do usuário após um determinado número de tentativas de autenticação incorretas é uma das melhores formas de se proteger contra ataques de dicionário ou força bruta. No entanto como todo remédio muito potente ele tem efeitos colaterais sérios.
O pior de todos é expor o seu serviço a um ataque de negação de serviço trivial - basta uma pessoa fazer propositalmente algumas tentativas inválidas de logon para bloquear o acesso daquele usuário, e com um pequeno script se bloqueia a organização inteira. Se o serviço estiver disponível pela Internet, então basta uma pessoa qualquer na Internet para cortar o logon de toda a empresa.
Aqui na Microsoft não usamos bloqueio de contas. A análise de risco mostrou que um atacante poderia facilmente de qualquer ponto da Internet usar o o nosso Outlook Web Access para bloquear todas as contas de usuário do Active Directory, um risco inaceitável para a empresa. Se este risco também é inaceitável para a sua organização, não habilite o bloqueio de contas e use o tamanho mínimo e a complexidade como mecanismos de proteção. E é claro monitore qualquer tentativa de repetida de autenticação inválida.
Se no entanto a sua análise de riscos aponta para o uso de bloqueio de contas, existe o problema do bloqueio indesejado - aquele onde o próprio usuário bloqueia a sua conta. Boa parte das vezes isso acontece após a troca, por alguns programas gravarem a senha anterior (o Windows 2003 evita esse problema não contando para fins de bloqueio uma tentativa de logon inválida usando a senha anterior), ou pelo próprio usuário digitar a nova senha incorretamente.
Para minimizar o bloqueio indesejado, que causa perda de produtividade e custo de help desk, defina um limite alto para bloqueio - 10 ou mesmo 50 tentativas como no nosso guia de segurança. Isto continua sendo efetivo como proteção contra ataques de força bruta, e elimina drasticamente o número de bloqueios indesejados.
Para terminar, eu queria somente enfatizar a necessidade de se ter uma política de senhas, qualquer que seja ela. Junto com a aplicação dos patches de segurança, trata-se na minha opinião das duas medidas de segurança mais importantes que uma organização pode tomar. Na minha experiência vendo incidentes de segurança, a enorme maioria deles teria sido evitada se os patches estivessem aplicados e senhas fortes estivessem sendo utilizadas. Se você estiver começando agora a definir a estratégia de segurança da sua organização, comece por estes fundamentos.
fonte: <http://blogs.technet.com/fcima/archive/2006/10/05/Como-Definir-sua-Pol_2600_iacute_3B00_tica-de-Senhas.aspx>
