Gerenciamento de Segurança - Outubro de 2005

As Perguntas Mais Freqüentes a Respeito das Senhas

Publicado em 12 de Outubro de 2005

Por Jesper M. Johansson
Senior Security Strategist
Security Technology Unit
Confira outras Colunas sobre o Gerenciamento de Segurança (em inglês).

Nesses últimos dias, parece que me tornei alguém para quem as pessoas vêm tirar dúvidas a respeito de senhas. Bem, na verdade, não vejo problema nisso, pois sou muito interessado no assunto. É uma boa área para se ter interesse, pois nós não iremos nos livrar tão facilmente das senhas, pelo menos por enquanto, e elas são usadas para proteger informações sensitivas. Hoje, os sistemas operacionais e aplicações são projetados em torno das senhas e, mesmo se você usar os smart cards ou sistemas biométricos, todas as contas ainda têm senhas que podem ser usadas em algumas circunstâncias. Algumas contas, mais notavelmente as usadas para executar serviços, não podem usar smart cards e toques biométricos e, portanto, devem ter uma senha para autenticação.

As pessoas geralmente têm as mesmas dúvidas quanto às senhas. Para tentar sanar algumas delas, achei que seria razoável escrever um FAQ. As perguntas que eu não responder aqui podem ser respondidas no meu blog (em inglês), e, se o tempo permitir, irei atualizar este artigo para refletir sobre quaisquer idéias que surgirem.

Perguntas Mais Freqüentes Sobre Senhas e Ataques a Senhas Como as senhas são armazenadas no Windows?

O sistema operacional do Microsoft Windows armazena senhas de diferentes maneiras por diferentes motivos. Para utilização em redes do Windows, incluindo domínios do Active Directory, a senha é armazenada de duas formas diferentes, por padrão: como LM OWF e NT OWF. OWF significa One-Way Function e é um termo que denota uma transformação matemática única de alguns dados. Os dados que estão sendo transformados podem ser convertidos somente de uma maneira, de forma ofuscada. Essa forma não pode ser revertida para a forma original, por isso o uso do termo one-way function. O tipo mais comum de OWF, em uso, é hash criptográfico. Um hash é um pequeno conjunto de dados, ligados matematicamente a um grande conjunto de dados, dos quais o hash é calculado. Se o maior conjunto de dados é alterado, o menor, ou seja, o hash, também é. Os hashes são úteis, por exemplo, como uma soma, para verificar se os dados não foram modificados na transmissão. Um hash criptográfico é aquele que preenche certas propriedades. Ele deve, por exemplo, ser criado de tal forma que seja matematicamente improvável em uma quantidade razoável de tempo para inferir o maior conjunto de dados de apenas um hash. Da mesma forma, é matematicamente improvável encontrar dois conjuntos de dados que gerem o mesmo hash.

Embora o LM OWF não seja exatamente um hash, sua saída é geralmente chamada de "Hash LM", uma vez que o NT OWF gera o "NT hash." Para simplificar, usarei o termo "hash" para denotar cada um deles, mesmo que ele nem sempre esteja correto. O termo OWF refere-se à função usada para calcular um hash.

Há diversos tipos de funções de direção única. Todas as funções do hash são, por definição, de uma só direção. No entanto, as funções criptográficas comuns, que são geralmente reversíveis, também podem ser usadas para criar uma função de direção única. Isso pode ser feito trocando-se os dados e a chave em uma função criptográfica e criptografando-se o valor fixo, a chave, usando-se os dados como chave. É assim que o Hash LM é computado. Ele é computado como segue:

O processo inteiro é apresentado na figura 1.

Figura 1

O algoritmo LM OWF tem mais de 20 anos. Ele foi originalmente criado para uso na família LAN Manager de sistemas operacionais e é incluído nas versões recentes do Windows para compatibilidade inversa com software e hardware que não utilizam novos algoritmos.

O NT hash é simplesmente um hash. A senha é mesclada usando o algoritmo MD4 e então armazenada. O NT OWF é usado para autenticação por membros do domínio tanto no Windows NT 4.0 e domínios mais recentes quanto no Windows 2000 e maiores domínios do Active Directory.

O processo do NT OWF é apresentado na figura 2.

Figura 2

Nem o NT hash e nem o Hash LM é incrementado "salted". Salting é um processo que, originalmente, foi usado em computadores baseados no UNIX, 20 anos atrás. Nesses computadores, as mesclas de senhas eram armazenadas em um arquivo legível mundialmente. Um usuário podia simplesmente pesquisar o arquivo para usuários que tinham o mesmo hash armazenado. Se fosse encontrado algum, significava que eles possuíam a mesma senha. Para resolver este problema, os designers do UNIX decidiram incrementar as senhas antes de armazená-las. O processo de salting combina a senha com um pequeno número de salt - antes de computar o OWF. O salt poderia ser armazenado em texto plano, no arquivo de senha. Isso garantia que dois usuários, com a mesma senha, tinham duas representações diferentes de senha armazenadas. O Windows nunca armazenou hashes no formato legível mundial, portanto, nunca houve necessidade de incrementá-las.

O Windows também armazena um verificador de senha nos membros do domínio quando um usuário efetua logon naquele membro de domínio. Este verificador pode ser usado para autenticar um usuário do domínio se o computador não puder acessar o controlador de domínio. No Windows XP, o verificador de senha também é usado para acelerar o logon do domínio quando o computador é reiniciado sem necessidade. O verificador também é comumente chamado de credencial armazenada. Ela é computada obtendo o NT hash, concatenando o usuário a ele, e mesclando o resultado usando a função MD4.

Internamente, o Windows representa senhas em strings UNICODE de 256 caracteres. O diálogo do logon é limitado a 127 caracteres, no entanto. Portanto, a senha mais extensa que pode ser usada para, interativamente, efetuar logon em um computador que executa o Windows é de 127 caracteres. Teoricamente, os programas, como os serviços, podem usar senhas mais extensas, mas elas devem ser definidas de forma programática, pois a caixa de diálogo de alteração da senha não permite mais do que 127 caracteres.

Início da página

De que forma as senhas são utilizadas no Windows?

Quando um usuário efetua logon, a senha que ele digita é convertida nos dois tipos de OWF e mantidas na memória pelo processo LSASS. Se o usuário estiver autenticando uma conta local, o NT OWF será comparado com o NT hash localmente armazenado, e, se ambos se associarem, o usuário efetua o logon. Caso o usuário esteja autenticando com um domínio do Active Directory que acessa um recurso usando um nome de host name, o NT hash é usado no logon de Kerberos com o Key Distribution Center (KDC, geralmente o controlador de domínio). O verificador de senha é computado pelo WINLOGON, não pelo LSASS.

Em certas situações, o Kerberos não pode ser usado. A lista que segue mostra situações em que alguns outros protocolos devem ser usados.

Nessas situações, o processo de autenticação utiliza dois protocolos diferentes, chamados de LanMan e NTLM. O processo começa com o cliente solicitando uma requisição do servidor de autenticação. Uma vez que a requisição é recebida, o cliente computa a resposta para esta requisição. Isso é feito primeiro preenchendo-se os dois hashes de senha com NULLs a 168 bits. Os 168 bits de cada hash são então divididos em três blocos de 56 bits cada, com cada bloco utilizável como uma chave DES. As seis chaves DES são então usadas para criptografar a requisição. Os três textos em cifras produzidos usando o Hash LM são concatenados e se tornam a resposta do LanMan. Os três textos em cifras produzidos usando o NT hash são concatenados e se tornam uma resposta NTLM.

As funções usadas para computar a resposta podem ser modificadas pelo Nível de Compatibilidade do LM, abordado na Base de Conhecimento da Microsoft, artigo 147706. (O LMCompatibilityLevel é apresentado na Diretiva de Grupo como segurança da Rede: nível de autenticação do LAN Manager). Se este valor está definido como 1 ou menor, o cliente envia as respostas originais do LanMan e NTLM. Se estiver definido como 2, somente a resposta NTLM é enviada. Se estiver definido como 3 ou maior, uma nova versão de ambos os protocolos é usada. A versão NTLM é chamada de NTLMv2. A versão LanManager é geralmente referida como LMv2. Ambos os protocolos usam o NT hash para computar a resposta, e ambos utilizam uma requisição do lado cliente, tanto no lugar de, ou além da requisição do servidor. Além disso, se a definição do Nível de Compatibilidade do LM está definida como 1 ou maior, a resposta do NTLM é fixada para prevenir ataques repetidos. Isso é mostrado na tabela 1.

Tabela 1 - Impacto do Nível de Compatibilidade LM do Lado Cliente

O servidor avalia as respostas em ordem particular, também gerenciada pela definição do Nível de Compatibilidade LM. Todos os servidores, desde o Windows NT 4.0 Service Pack 4 iniciam avaliando a resposta do NTLM como se ela fosse computada usando o NTLMv2. Se isso falhar e o Nível de Compatibilidade LM estiver definido como 4 ou menos, geralmente o servidor irá então avaliar a resposta do NTLM como se fosse uma resposta NTLM original. Se falhar e o servidor estiver definido como 3 ou menos no Nível de Compatibilidade LM, ele avalia a resposta do LanMan. Se nada disso bater ou se a definição do Nível de Compatibilidade LM estiver definido para prevenir o servidor de avaliar a resposta da LanMan e/ou NTLM, a autenticação falha com uma mensagem de erro de nome de usuário ou senha inválida. Isso é mostrado na tabela 2.

Tabela 2 - Impacto do Nível de Compatibilidade LM do Lado Cliente

Lembre-se de que, quando falamos sobre impacto do lado cliente ou servidor da definição do Nível de Compatibilidade LM, estamos nos referindo a qualquer computador do Windows (ou compatível) que opere como cliente ou servidor. Uma das coisas mais confusas sobre esta definição é que ela é geralmente descrita em termos de "definições do controlador de domínio". O fato é que o lado servidor aplica-se a qualquer servidor que suporta um banco de dados de autenticação. Por exemplo, se você se conecta a um computador que executa o Windows XP Professional usando uma credencial definida no SAM, naquele computador, ele está agindo como um servidor e as definições do lado servidor conduzem seu comportamento.

O Windows NT 4.0, Service Pack 4 ou superior, Windows 2000, e edições de 32 bits do Windows XP têm Nível de Compatibilidade LM definido para 0, como padrão. O Windows Server 2003 e o Windows XP 64 bits têm o nível definido para 2, como padrão.

Início da página

O que pode falhar se eu alterar o Nível de Compatibilidade LM?

Inúmeras coisas poderão falhar se você alterar o Nível de Compatibilidade LM de um computador. Se você solicitar a chegada do NTLMv2 (ou seja, nível 5), as falhas serão as seguintes:

Se você configura o Nível de Compatibilidade LM para 3 ou maior, pode ter problemas com dispositivos de hardware de terceiros que possuem um servidor SMB integrado. Muitos deles não podem autenticar tráfego de chegada usando o NTLMv2 e, portanto, irão falhar se você definir o Nível de Compatibilidade LM para 3 ou mais.

Início da página

De que forma as senhas podem ser atacadas?

Há inúmeras maneiras prováveis de ataque a senhas. A mais simples é, provavelmente, a mais efetiva. Se você deseja saber a senha de outra pessoa, pergunte a ela! Aproximadamente 70% dos entrevistados em uma pesquisa feita em 2004 (em inglês) revelariam a senha se alguém negociasse com eles algo que valha mais que seus segredos organizacionais, informações de cartão de crédito, conta do banco ou qualquer assunto que seja protegido por uma senha. O estudo utilizou o chocolate como a questão valiosa a ser negociada: http://news.bbc.co.uk/1/hi/technology/3639679.stm (em inglês).

Esta pesquisa destaca um ponto realmente importante. Os links mais fracos em um sistema de segurança baseado em senha são as pessoas. Na verdade, só para brincar, uma vez eu disse "não há nada errado com as senhas que, removendo as pessoas que as usam, não poderia resolver". As senhas falham na segurança, pois as pessoas geralmente criam senhas fracas ou as passam adiante, inadvertidamente ou não. Para ser justo, no entanto, grande parte do problema está na sobrecarga absoluta dos sistemas baseados em senhas e no fato de a maioria das pessoas nunca ter aprendido a lidar com senhas. Mas este tópico é para um artigo diferente, que provavelmente seria mais bem escrito por alguém com mais conhecimento em pessoas.

Se olharmos para métodos puramente técnicos de ataque a senhas, o primeiro deles envolve a adivinhação a partir de um prompt de logon, tanto local quanto remotamente. Essa abordagem será bem sucedida apenas com senhas muito fracas e levará um tempo considerável. Se as senhas forem continuamente randômicas para o atacante, então qualquer ataque a elas seguirá uma distribuição randômica em que cada senha possível é igualmente passível de se associar à senha de destino. Portanto, estatisticamente falando, um atacante teria de testar metade de todas as senhas possíveis para se associar a certa senha. É claro, é possível que a primeira tentativa encontre o alvo, mas a probabilidade disso é uma dividida pelo número de senhas possíveis extremamente diferentes, a menos que a definição do caractere e o tamanho usado seja extremamente pequenos. Portanto, se as senhas são randomicamente compostas de oito caracteres escolhidos randomicamente, de, ao menos três dos quatro tipos de caracteres (maiúsculas, minúsculas, números e símbolos), um ataque de adivinhação levará entre 1500 e 1,4 milhões de anos, dependendo da rapidez da ferramenta usada. O número baixo é baseado na ferramenta mais rápida sobre a qual já ouvi falar, que consegue fazer 1700 adivinhações por segundo.

Uma segunda maneira de ataque a senhas é capturar os pares de resposta de solicitação e depois tentar corrompê-los. A corrupção é um termo genérico que diz respeito basicamente a diferentes métodos de tentativa de adivinhar uma senha. Todos esses métodos contam com a produção de uma senha teste, executando-a através dos mesmos algoritmos pelos quais a senha real seria executada, e depois comparando o resultado com o valor capturado. Por exemplo, se um atacante captura pares de resposta da solicitação LanMan, ele deve começar adivinhando que a senha é a senha1. Neste caso, ele primeiro computa o Hash LM da senha1. Depois computa a resposta usando o Hash LM e a solicitação enviada ao servidor. Se essa resposta bater com a que o cliente enviou, a senha foi encontrada. Se não, o processo é iniciado com uma nova senha teste. Este tipo de corrupção é consideravelmente mais rápido do que um ataque por adivinhação, mas, mesmo assim, consome muito tempo. Para os Hash LM, ele envolve a computação de cinco funções DES diferentes, com cada uma muito lenta. Um computador rápido pode computar basicamente quase 3.000.000 de pares de resposta da solicitação LanMan por segundo através de um algoritmo otimizado. Se fosse usada uma computação de resposta da solicitação da LanMan, a senha de oito caracteres, abordadas anteriormente, levariam quase 3 anos para ser descoberta usando um ataque de força bruta, em que o atacante tenta simplesmente todas as senhas possíveis. O mesmo computador pode computar em torno de 1.500.000 pares de resposta de solicitação NTLMv2 ou LanManv2 por segundo. Uma vez que essas respostas utilizam um hash que diferencia caracteres, o tempo para uma corrupção aumenta para 70 anos usando esses protocolos.

Corromper a resposta da solicitação do NTLM pode ser até mais rápido, dependendo do conjunto de caracteres usado e do tamanho da senha. A resposta da solicitação do NTLM tem somente três computações DES e um MD4 hash. Computar um MD4 hash é muito mais rápido que computar uma encriptação DES. No entanto, a resposta da solicitação do NTLM é computada usando um hash sensível a caracteres, significando que há várias outras opções a serem consideradas. Uma estimativa bruta é que o mesmo computador poderia testar 4.500.000 pares de resposta de solicitação do NTLM por segundo, resultando em um tempo de corrupção de 23 anos para uma senha de oito caracteres.

Uma terceira forma de ataque é entrar no computador que armazena os hashes. Esses hashes poderiam então ser corrompidos usando essencialmente a mesma técnica para os pares capturados de resposta da solicitação, mas usando muito menos computações. Usar um exemplo de senha de oito caracteres levaria somente 6 dias para forçar brutalmente o espaço todo dos Hash LM. Isso acontece parcialmente, pois agora há somente duas computações DES para realizar, mas muito da velocidade vem do fato de os LM armazenarem a senha de oito caracteres como uma senha de 7 caracteres e uma de 1 caractere, sendo que as duas partes podem ser corrompidas separadamente. Se a senha foi armazenada como um bloco único de 8 bytes, seria levado um ano para corrompê-la.

Início da página

O que são as tabelas Arco-íris?

Uma nova criação de um antigo ataque surgiu em 2004. Por muitos anos, os analistas de segurança sabiam que o tempo de corrupção poderia ser aumentado se o invasor pudesse simplesmente comparar os hashes capturados com os que já haviam sido nas senhas conhecidas. Este ataque, conhecido como um ataque a hash pré-computado, funciona somente se as senhas não são incrementadas; ao contrário, a mesma senha teria diversos hashes possíveis diferentes. O método promete grandes melhorias na velocidade se for funcionar. Possivelmente, a primeira implementação deste tipo de ataque foi em um produto chamado Quakenbush Password Appraiser, que surgiu em 1998. O problema com esse tipo de abordagem é que ele requer grande espaço de armazenamento para manter as funções OWF computadas, e leva muito tempo para computar tudo. Em 2004, Philippe Oechslin descobriu uma solução para o primeiro problema. Em vez de armazenar o hash inteiro, uma tabela Arco-íris armazena somente uma parte dele, juntamente com as senhas que são conhecidas para gerar o hash. O invasor agora pode simplesmente olhar as partes do hash que estão armazenadas e computar o hash apenas para senhas que podem produzir o hash. Essa abordagem acelera a corrupção por inúmeras ordens de magnitude. Mesmo uma antiga implementação pobre otimizada deste ataque resultava em corrupções que levavam menos de uma hora, em vez de 57 dias. Essa teoria foi implementada na ferramenta RainbowCrack.

As tabelas Arco-íris funcionam do mesmo modo para o Hash LM e o NT hash, com a advertência que o espaço de armazenamento requerido para o NT hash é inúmeras vezes maior do que para o Hash LM caso sejam desejados hashes para senhas maiores que oito caracteres. O armazenamento para o Hash LM está dentro de alcance para a maioria dos usuários, no entanto. Um conjunto de tabelas Arco-íris para o Hash LM computava a partir de espaços alfanuméricos e os 14 símbolos na parte superior de um teclado americano têm aproximadamente 17 GB de armazenamento. Um conjunto de tabelas Arco-íris para os Hash LM computados a partir de um espaço completo de caracteres, em um teclado americano, tem aproximadamente 47 GB de armazenamento.

As tabelas Arco-íris ainda levam muito tempo para computar, devido ao grande número de computações requeridas e às ferramentas pouco otimizadas atualmente disponíveis. Deveríamos aguardar por mais melhorias no desempenho à medida que as ferramentas forem se tornando melhores. Além disso, as tabelas Arco-íris ficaram disponíveis para compra online por mais de um ano e os usuários de diversos serviços de compartilhamento de arquivos agora podem fazer o download delas junto com música, fiLM e software tipicamente disponíveis nestes serviços. Na verdade, vários pesquisadores de segurança desenvolveram técnicas aprimoradas de geração para acelerar a produção das tabelas.

Início da página

Eu devo me preocupar com a corrupção de senhas?

A resposta é um item não qualificado. A corrupção com hashes capturados não é um ataque interessante. O hash é o único segredo usado em protocolos de resposta de solicitações, hoje em dia, tanto no Windows como em outros sistemas operacionais. Um atacante com o hash tem tudo o que é necessário para autenticar, enquanto o usuário e a corrupção são simplesmente uma perda de tempo. As ferramentas que implementam este tipo de ataque, conhecidas como ataque que passa o hash, ainda estão disponíveis na Internet. Embora as ferramentas sejam ainda relativamente instáveis e não confiáveis, devemos esperar que sua qualidade melhore à medida que as senhas também o façam. Além disso, para capturar os hashes, o atacante deve entrar no servidor de autenticação, que é basicamente o controlador de domínio de uma rede baseada no Windows. Se isso ocorreu, a rede foi totalmente comprometida e as senhas corrompidas são somente úteis para atacar outras redes em que os mesmo usuários usaram a mesma senha (uma prática que deveria ser totalmente desestimulada). O Windows nunca irá passar os hashes através da rede em um canal descriptografado. Assim, capturar os hashes em uma transferência de rede é muito simples.

Desde Janeiro de 2005, a corrupção com o verificador armazenado de senha (a credencial armazenada) teve interesse renovado devido à publicação da primeira ferramenta comumente disponível para extrair os verificadores de um computador comprometido. Corromper o verificador de senha é razoavelmente eficiente, levando um tempo três vezes maior do que a corrupção com NT hashes. Isso, no entanto, não é um ataque interessante. Primeiro, o verificador é um hash do hash, tornando, pelo menos, duas vezes mais resiliente do que o hash original. Segundo por que, uma vez que o verificador de senha é incrementado com nome de usuário, ele é unicamente possível para dois usuários que usam a mesma senha. Enquanto um ataque pré-computado do hash ainda pode ser usado para acelerar a primeira computação, ele é inútil com o segundo hash. Finalmente, o verificador supre uma importante finalidade. Sem ele, os usuários precisariam usar credenciais locais ao efetuar logon no computador, enquanto se desconectam de um domínio, mas usam credenciais quando conectados. Este processo criaria claramente um aborrecimento aos usuários. Mais importante, no entanto, é o efeito que ele teria nos hashes capturados. A maior parte dos pesquisadores sobre segurança concorda com que a vasta maioria de usuários usaria a mesma senha para duas contas. Se um atacante comprometer um computador que possua credenciais locais e essas credenciais se associarem às do domínio, ele terá todas as informações necessárias para se autenticar como usuário no domínio e não terá de corromper uma única senha. A representação do OWF armazenada localmente para a conta local é idêntica àquela armazenada para a conta de domínio dos usuários, se as duas tiverem a mesma senha. Nitidamente, a dinâmica da interação homem-computador significa que o verificador de senha provavelmente aumenta a segurança, em vez de diminuí-la. Por isso os ataques contra os verificadores de senha talvez não sejam tão interessantes.

Corromper pares capturados de respostas de solicitações é, no entanto, um ataque interessante ainda. No entanto, usar o Nível de Compatibilidade LM pode ser efetivamente inválido por não transmitir os pares de resposta de solicitação LanMan. Essa é uma abordagem válida em quase todos os ambientes. Alguns (possivelmente nem todos) problemas com o Nível de Compatibilidade LM foram listados acima. Caso você não esteja sujeito a essas questões, recomendamos que configure seu Nível de Compatibilidade LM para 5.

Início da página

Por que o Hash LM é armazenado se ele é tão vulnerável?

O Hash LM é armazenado por razões inversas de compatibilidade. Muitos ambientes não precisam mais dele e podem desabilitar o armazenamento daquele valor. O artigo da Base de Conhecimento, 299656, informa sobre o valor do registro que pode ser usado para configurar este comportamento. Isso irá prevenir ataques contra Hashes LM capturados de um servidor de autenticação comprometido. No entanto, ele não irá prevenir nenhum computador de enviar uma resposta LanMan durante uma seqüência de autenticação. Além de configurar o valor do registry, falado no artigo 299656 da KB, o armazenamento do hash LM pode ser prevenido usando uma senha maior que 14 caracteres ou certos caracteres Unicode na senha. A discussão sobre quais caracteres Unicode resulta em não armazenar o hash LM está além do escopo deste artigo, mas é argumentado no Manual de Intensificação na Segurança do Windows 2000 e no Proteja a sua Rede do Windows, por Johansson e Riley (em inglês).

Observe que o valor real de segurança do não armazenamento do Hash LM é insignificante diante de um atacante conhecedor do assunto. Os únicos ataques que ele previne são aqueles que contam com Hashes LM capturados de um servidor de autenticação comprometido. Conforme mencionado anteriormente, a corrupção de tais hashes deveria ser considerada uma perda de tempo para os atacantes mais sofisticados. Primeiro, o NT hash é perfeitamente adequado para autenticar como usuário, sem corrupção nenhuma. Na verdade, não há diferença no valor da segurança entre uma senha de 1 caractere armazenada usando um Hash LM e uma senha complexa de 127 caracteres armazenada usando o NT hash. Ambas geram um hash que pode ser usado para autenticar como usuário, e, se o valor do Nível de Compatibilidade LM foi definido para 4 ou maior, no servidor de destino, o LM OWF é inútil.

Início da página

O que devo fazer para proteger minhas senhas?

O mais importante a fazer é usar senhas boas. As senhas boas derrotam qualquer ataque acima, exceto os que usam hashes capturados, que só são derrotados protegendo adequadamente seus servidores de autenticação. Algumas características de senhas boas são:

Tendo em vista todos esses requisitos, e mais o fato de que todos nós temos diferentes senhas, como irmos nos lembrar de tudo se eles são tão complexos, extensos, usados apenas uma vez? Infelizmente, a indústria de segurança, durante anos, persistiu na teoria de que escrever senhas é uma brecha na segurança. Nada pode ir além da verdade. Escrever sua senha é uma excelente idéia, contanto que você proteja adequadamente o meio em que você escreveu! Fazer isso permite que você crie senhas melhores, aumentando assim a segurança, em vez de reduzi-la. É claro que escrever sua senha em um papel e pendurá-lo no monitor torna vulnerável a um ataque binocular, mas se você escrever em um papel e colocar na sua carteira, a senha estará mais bem protegida. Os produtos de software para gerenciar senhas são diversos. O mais simples permite que você armazene a senha que criar; muitos também irão digitá-la automaticamente para você em um site. Alguns dos melhores irão, de verdade, gerar senhas para você, criando algumas muito mais complexas do que a média humana poderia criar. Alguns ainda criam as senhas a partir de entradas conhecidas e não precisam armazenar nada. A idéia básica por trás dessas ferramentas é que, enquanto você retém a habilidade de ter um segredo único que proteja todos os computadores, este segredo não é exposto em nenhum desses computadores. Uma das ferramentas vem com o Proteja a sua Rede do Windows (em inglês).

Uma idéia ainda melhor do que usar senhas complexas é usar smart cards. As versões do Windows, desde o Windows 2000, são capazes de usar smart cards para logon aos domínios do Active Directory. Uma abordagem completa sobre os smart cards está além do escopo deste artigo. No entanto, há um fator importante a ser lembrado: mesmo quando você requer smart cards para logon interativo, cada usuário ainda tem sua senha, que ainda pode ser usada para fins de logon na rede. É altamente improvável que veremos um sistema útil, completamente sem a necessidade de senhas, nos próximos 10 anos, e ainda assim há inúmeros serviços, tais como e-mail e sites da Web, que irão continuar a usar senhas. De fato, aprender sobre os riscos inerentes em senhas e saber qual o melhor uso delas é algo que vale muito a pena.

Início da página

O que dizer sobre as frases de acesso?

Há quase um ano, escrevi um artigo sobre se as frases de acesso são melhores que as senhas. O artigo essencialmente estabeleceu que nós pensássemos que as frases são melhores que as senhas, mas não temos provas científicas disso.

O que nós sabemos é que as pessoas tendem a usar substituição de letras em suas senhas. É aí que você substitui uma letra por outra. Por exemplo, substitua s por $. Eu me lembro de como pensei que fosse inteligente quando tive essa idéia. Bem, os caras maldosos também acabaram pensando nisso. Se a sua senha é Seattle1 (que, a propósito, é complexa, de acordo com as regras de complexidade integradas), há somente uma substituição do $ por s e o cara maldoso tem que checar somente duas senhas para encontrar a correta.

Mas e se a sua senha for "Eu só uso uma frase se a senha for forte para a maioria das minhas senhas"? Essa é bem complexa, pois tem letra maiúscula, outras minúsculas e um símbolo. E também nove caracteres s. Um atacante que suspeitar que você substituiu um ou mais deles por $ terá que tentar 512 combinações para encontrar a correta. As frases de acesso têm uma vantagem importante sobre outras senhas: elas aumentam o valor da substituição da letra em diversos aspectos.

As frases também permitem que você se lembre de quanto maior as senhas, melhor. Estender uma senha é o principal fator para torná-las fortes. Na série de artigos anteriores pedi exemplos de frases. Enquanto várias delas eram apenas palavras colocadas juntas, sem espaços, elas eram muito extensas! A média de tamanho foi de quase 31 caracteres. Compre isso com a média de nove caracteres, de acordo com o estudo anterior documentado na série de artigos supramencionados. E 75% das frases pareceram ser de origem natural. Isso significa que eu fui incapaz de discernir qualquer fonte para estebelecer. A grande categoria seguinte foi a literatura, que teve aumento de, no mínimo, 6% de frases de acesso.

Outro fator interessante sobre essas frases é que elas são fáceis de serem lembradas e podem ser usadas por qualquer pessoa virtualmente. Peguei meu filho mais velho para usar uma frase de acesso quando ele tinha 6 anos. Tente com uma senha como K%Dsi&7e, que não é tão forte quanto a frase que ele está usando.

Início da página

O que devo fazer com as senhas em contas de serviços?

As contas de serviços apresentam uma situação interessante. Na maior parte dos casos, as senhas necessárias para eles serão usadas somente de forma programática, não interativamente. Isso quer dizer que elas podem ser consideravelmente mais fortes do que senhas usadas de forma interativa. Por exemplo, a caixa de diálogo gráfica da interface de logon suporta senhas de até 127 caracteres. No entanto, internamente, o Windows 2000 ou superior permitem que as senhas sejam de até 256 caracteres. Para contas que só precisam ser programaticamente usadas, como a maioria dos serviços de conta, nós podemos tirar vantagem disso para definir uma senha que não seja interativamente usada. Se a senha nunca precisar ser digitada por uma pessoa, não há motivo para defini-la o mais extensa possível. Note que você não pode configurar uma senha maior que 127 caracteres na Interface Gráfica de Usuário. Para isso, você precisa de uma ferramenta chamada NetUserChangePassword ou NetUserSetInfo APIs, diretamente. O limite de tamanho está somente na Interface Gráfica e não nos APIs.

A Segunda questão especial sobre contas de serviço é que, de forma geral, não esperamos que as senhas expirem ou que sejam bloqueadas. Se a senha expirar ou a conta for bloqueada, o serviço que usa a conta não será iniciado. Portanto, devemos ter certeza de que desabilitamos a expiração da senha e as contas de serviço. Em vez disso, devemos ter um processo para alterar as senhas em intervalos regulares. As considerações sobre bloqueio de conta são mencionadas abaixo.

O último fator a ser lembrado sobre os serviços de contas tem menos a ver com senhas do que com as contas em si. Se um atacante compromete um computador que utiliza uma conta de serviço, ele tem acesso à senha para aquela conta. Isso quer dizer que o atacante agora comprometeu outro computador que confia naquela conta. Isso é chamado de dependência de conta de serviço. No entanto, uma vez que ela não é especificamente relacionada à senha na conta, o leitor deve recorrer ao artigo Proteja a sua Rede do Windows, capítulo 8, que aborda detalhadamente este assunto.

Início da página

De que forma devo gerenciar senhas na conta integrada do administrador?

Todos sabem que você deve definir uma senha forte para a conta integrada do Administrador. No entanto, você pode se questionar se deve permitir o uso desta conta. Basicamente, ela não é necessária após a configuração do computador (nota: o Windows Small Business Server é uma exceção notável. Você precisa da conta do Administrador nesta plataforma). A menos que você precise da conta, pode desabilitá-la após finalizar a configuração do computador. Toda pessoa que administra um computador deve ter sua própria conta administrativa. Se todos usarem essa conta, você não terá como fazer uma auditoria de nada do que eles fizerem. (Lembre-se de que você só pode fazer auditoria dos usuários que sejam administradores se eles consentirem. Se eles quiserem, podem desabilitar ou modificar as entradas da auditoria. Afinal, eles são administradores). Sem o uso de contas únicas administrativas, você perde toda a responsabilidade de seus administradores.

Também é importante que você defina senhas na conta integrada do Administrador. A maioria das organizações não faz isso. Nós temos scripts padrões que projetam clientes e servidores e todos eles contêm uma senha altamente codificada. O resultado líquido é que todos os computadores no ambiente têm a mesma senha na conta local do Administrador. Se algum dos computadores se tornar comprometido, o atacante irá obter o hash daquela senha. Esse hash agora pode ser usado para efetuar logon em qualquer um dos outros computadores que usam a mesma senha na conta. Este é, de fato, o princípio do maior privilégio em ação. A rede toda não está mais segura do que o computador menos seguro da rede. O que temos de fazer é definir uma senha única para a conta integrada do Administrador em cada computador. Isso é algo complicado, mas vale a pena. Fui informado de que o User Manager Pro (em inglês) pode ajudá-lo a gerenciar isso, embora eu não tenha uma experiência em primeira mão com isso.

Você também pode usar uma ferramenta de linha de comando que defina a senha. Caso deseje usar a conta, deve ser capaz de recuperar a senha. Isso significa tanto escrevê-la quanto usar uma ferramenta que a recupere para você. Uma das ferramentas é a passgen, que vem com o Proteja a sua Rede do Windows (em inglês). A Passgen é designada para definir uma senha pseudo-randômica em contas regulares e de serviço pela rede. A senha pode tanto ser totalmente randômica quanto baseada em duas partes de entrada: com identificador único do computador ou conta, e com uma frase de acesso comum. A frase de acesso comum é o segredo global, mas não é armazenado em nenhum dos computadores protegido pelo segredo. Por isso, é muito mais fácil proteger do que a senha dos administradores em milhares de computadores.

Você deve levar em conta uma senha em branco na conta local do Administrador. Particularmente em servidores, que são fisicamente seguros em seus suportes, essa é uma opção razoável. Por padrão, o Windows XP e o Server 2003 não permitem o logon na rede para uma conta com senha em branco. Contanto que o servidor esteja fisicamente seguro, e que este recurso não tenha sido desabilitado, você terá uma conta local de Administrador que não pode ser usada pela rede, mas sim localmente.

Início da página

O que devo definir para bloquear uma conta?

Você deve desabilitá-la. O bloqueio de conta é um recurso que bloqueia uma conta após certo número de tentativas de logon com uma senha incorreta. É designado para proteger o computador contra senhas fracas. O problema é que senhas fracas irão, eventualmente, sofrer um ataque, de todo modo, independente do bloqueio. O atacante esperto irá simplesmente modificar o ataque de forma que não atinja o bloqueio de conta. Uma senha fraca irá resistir mais a um ataque quando o bloqueio for usado, mas ainda assim pode ser corrompida.

Além disso, um bloqueio torna trivial para um atacante menos astuto desabilitar completamente o sistema. Um simples arquivo pode ser usado para bloquear cada conta no computador, enfraquecendo-o. O bloqueio de conta, enquanto foi feito para proteger senhas fracas, cria uma condição em que uma recusa de ataque ao serviço seja possível.

Pelo menos no Windows, o bloqueio também é uma definição tudo-ou-nada. Você não pode selecioná-lo apenas para submeter certas contas ao bloqueio. Assim, se você está interessado em proteger apenas certas contas, deve habilitar o recurso para todas elas. Isso expõe todas as contas à recusa de vulnerabilidade de serviço, descrita anteriormente. Se um computador tem o bloqueio habilitado e um atacante bloqueia uma conta usada para aquele serviço, por exemplo, o serviço não será iniciado. Isso pode causar sérias conseqüências, não só no tempo de funcionamento, mas também nos objetivos corporativos e receita da organização, caso a conta seja usada para essas finalidades.

A melhor solução para o problema de senhas fracas é usar outras melhores. Conforme já mencionamos, levará anos para adivinhar uma boa senha, tornando o bloqueio de conta totalmente desnecessário em ambientes que as reforçam. Além disso, o bloqueio geralmente requer uma chamada ao suporte técnico. As estimativas de custo em torno dessas chamadas variam de $30 a $70 por ocorrência.

Alguns pensam que precisamos do bloqueio de contas para nos protegermos das pessoas, pois elas sempre escolhem senhas fracas, não importa o que façamos. Em partes, elas realmente fazem isso, mas nós podemos impor restrições para prevenir isso. Uma política de senha deve reforçar as senhas fortes. Se desejar, pode utilizar um filtro de senha para reforçar até as mais fortes restrições e evitar as pessoas de usar palavras do dicionário, ou até trocas de palavras do dicionário. Se você não confia nos seus funcionários para escolher boas senhas, então você deve preveni-los usando os smart cards ou alguma outra forma de autenticação, como o RSA SecurID. Pense cuidadosamente no problema antes de gastar muito do seu orçamento com redefinições de contas, simplesmente por ter medo de que as pessoas não escolham uma boa senha. No final, as senhas fracas irão falhar. A solução correta é treinar as pessoas a não usá-las.

As Pessoas são o Link mais Fraco; e a Defesa mais Forte

Eu tenho de ser otimista com o fato de pensar que as pessoas podem realmente ser treinadas para ser, no mínimo, conscientes sobre a segurança. Existem diversas soluções técnicas, como os smart cards, que tentam remover a pessoas da equação. Essas soluções também removem a necessidade de medidas, como um bloqueio de conta sem comprometer a estabilidade da rede. O problema é que os smart cards não são uma solução completa, já que muitas aplicações não os suportam. Como foi anteriormente mencionado, as contas sempre terão senhas e algumas contas não podem usar smart cards. Contudo, usar os smart cards reduz um pouco do problema, ou seja, ainda irá permanecer, principalmente com o bloqueio de contas. No entanto, nenhuma dessas medidas técnicas será efetiva contar um atacante que explora pessoas para um ataque de engenharia social. Uma pessoa que negocia sua senha por chocolates provavelmente fará o mesmo com os smart cards, embora o custo será maior para o atacante. No final das contas, as pessoas acabam sendo o link mais fraco no sistema homem-computador, e os atacantes são altamente treinados para atacar pessoas.

Muito da sabedoria mais aceita sobre as senhas, incluindo todos os argumentos sobre o bloqueio de contas, é baseado na hipótese de que as pessoas não podem ser treinadas para usar senhas boas. No entanto, se a pessoa não pode ser treinada para usar uma senha resiliente a um ataque por adivinhação, então devemos presumir que também não podemos treiná-las para negociá-la por chocolate com a primeira pessoa que lhe pergunta. Se perdermos toda a esperança no treinamento de nossas pessoas, então a segurança será uma batalha perdida para sempre. Os atacantes sempre encontrarão um jeito em torno disso tudo, explorando as pessoas, e essas sempre serão o lado mais fraco. Os atacantes que têm as nossas pessoas como foco terão muito mais sucesso do que aqueles que só se concentram em ataques técnicos, e isso nós nunca poderemos prevenir. O pensamento de que as pessoas podem ser treinadas para realizar ações rudimentares referentes à segurança é o que me leva a continuar trabalhando. Por favor, não me tire essa ilusão.

Caso você tenha sucesso ao treinar suas pessoas, elas serão sua linha de defesa mais forte. Elas entenderão a necessidade da proteção a informações, tomando passos sensatos para implementar isso. Elas irão reconhecer as tentativas a ataques contra pessoas e computadores, tornando-se um sistema muito efetivo de detecção (e prevenção). Além disso, elas irão prevenir a necessidade de algumas das medidas mais onerosas de segurança técnica que nó localizamos para consertar os erros humanos deliberados ou acidentais. O investimento na segurança humana pode ser o mais importante que você irá fazer, mas vale muito a pena!

Para Saber Mais

Caso você tenha grande interesse no assunto de senhas, leia o Capítulo 11 de Proteja a Sua Rede do Windows (em inglês). Ele contém abordagens detalhadas que incluem tipos de senhas que as pessoas geralmente usam na vida rela e os motivos pelos quais as frases devem ou não ser melhores que as senhas.

Como sempre, esta coluna é para você. Se existe algo que você deseje ver, por favor, envie-me uma mensagem, clicando em Contact Us, na parte inferior da página. Você também pode entrar em contato comigo através do meu blog (em inglês). Lá você encontrará um lugar onde fazemos discussões sobre este artigo.

Início da página