Visão geral técnica das senhas

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows 7, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Vista

Este tópico para o profissional de TI explica como o Windows implementa senhas em versões do Windows começando com Windows Server 2012 e Windows 8.1. Ele também discute senhas fortes, frases secretas e políticas de senha.

Como as senhas são armazenadas no Windows

Este artigo fornece informações sobre o armazenamento de senhas "inativas".

O Windows representa senhas em cadeias de caracteres UNICODE de 256 caracteres, mas a caixa de diálogo de logon é limitada a 127 caracteres. Portanto, a senha mais longa possível tem 127 caracteres. Programas como serviços podem usar senhas mais longas, mas devem ser definidos programaticamente.

O sistema operacional Windows armazena senhas de várias maneiras diferentes para fins diferentes.

Senhas armazenadas como OWF

Para uso na rede do Windows, incluindo domínios do Active Directory, a senha é armazenada de duas maneiras diferentes por padrão: como OWF do LM (função unidirecional do LAN Manager) e como OWF do NT. "Função unidirecional" é um termo que indica uma transformação matemática unidirecional de dados. Os dados que estão sendo transformados só podem ser convertidos por meio da criptografia de uma maneira e não podem ser revertidos. O tipo mais comum de função unidirecional em uso é um hash criptográfico. Um hash é um pequeno conjunto de dados que está matematicamente vinculado a algum conjunto maior de dados do qual o hash é calculado. Se o conjunto maior de dados for alterado, o hash também será alterado. Hashes são úteis, por exemplo, como uma soma de verificação para verificar se os dados não foram modificados na transmissão. Um hash criptográfico é um hash que atende a determinadas propriedades. Um hash criptográfico deve, por exemplo, ser criado de forma que seja matematicamente inviável em um período de tempo razoável inferir o conjunto maior de dados apenas a partir do hash. Da mesma forma, é matematicamente inviável encontrar dois conjuntos de dados grandes que geram o mesmo hash.

Há muitos tipos diferentes de funções unidirecionais. Todas as funções de hash são, por definição, funções unidirecionais. No entanto, funções criptográficas comuns que normalmente são reversíveis também podem ser usadas para criar uma função unidirecional. Isso pode ser feito trocando os dados e a chave em uma função criptográfica e criptografando o valor fixo (a chave) usando os dados como a chave. É assim que o hash do LM é calculado. O hash do LM é calculado da seguinte maneira:

1. A senha é preenchida com bytes NULL para exatamente 14 caracteres. Se a senha tiver mais de 14 caracteres, ela será substituída por 14 bytes NULL para as operações restantes.
2. A senha é convertida em maiúsculas.
3. A senha é dividida em duas chaves de 7 bytes (56 bits).
4. Cada chave é usada para criptografar uma cadeia de caracteres fixa.
5. Os dois resultados da etapa 4 são concatenados e armazenados como o hash do LM.

O algoritmo OWF do LM está incluído no Windows para compatibilidade com versões anteriores com software e hardware que não podem usar algoritmos mais recentes.

O hash do NT é simplesmente um hash. A senha é "hasheada" usando o algoritmo MD4 e armazenada. A OWF do NT é usada para autenticação por membros do domínio em domínios Windows NT 4.0 e anteriores e em domínios do Active Directory.

Nem o hash do NT nem o hash do LM possuem salt. Salting é um processo que combina a senha com um valor numérico aleatório (o salt) antes de calcular a função unidirecional.

Senhas armazenadas no Active Directory

As senhas inativas são armazenadas em vários atributos do banco de dados do Active Directory (arquivo NTDS.DIT). Esses atributos são listados na tabela a seguir:

Atributo do Active Directory	Conteúdo
unicodePwd	Hash do NT criptografado
dbcsPwd	Hash do LM criptografado
ntPwdHistory	Hashes do NT criptografados – Histórico de Senhas
lmPwdHistory	Hashes do LM criptografados – Histórico de Senhas
supplementalCredentials	Chaves Kerberos, WDigest etc.

Observação

O armazenamento de hashes de LM está desabilitado por padrão desde o Windows Vista e o Windows Server 2008.

Quando armazenado no arquivo DIT, o hash do NT é protegido por duas camadas de criptografia. No Windows Server 2016/Windows 10 e versões posteriores, ele é primeiro criptografado com DES para compatibilidade com versões anteriores e, em seguida, com CNG BCrypt AES-256 (consulte CNG BCRYPT_AES_ALGORITHM). As versões anteriores do Windows criptografam hashes do NT usando duas camadas de criptografia DES + RC4.

Para obter mais informações sobre credenciais complementares, consulte MS-SAMR: supplementalCredentials e Estruturas de credenciais suplementares.

Senhas armazenadas no SAM local

Em membros do domínio e estações de trabalho, os hashes de senha da conta de usuário local são armazenados em um banco de dados local do SAM (Gerenciador de Contas de Segurança) localizado no registro. Eles são criptografados usando os mesmos algoritmos de criptografia e hash que o Active Directory. As senhas no atributo supplementalCredentials para contas de usuário local também são armazenadas no Banco de Dados do SAM local desde Windows Server 2016.

Credenciais armazenadas em cache

O Windows também armazena um verificador de senha em membros do domínio quando um usuário de domínio faz logon nesse membro de domínio. Esse verificador poderá ser usado para autenticar um usuário de domínio se o computador não puder acessar o controlador de domínio. O verificador de senha também é comumente chamado de credencial armazenada em cache. Ele é calculado usando o hash do NT, concatenando o nome de usuário a ele e, em seguida, fazendo hash do resultado usando a função de hash MD4.

Como as senhas funcionam no Windows

No Windows e em muitos outros sistemas operacionais, um método para autenticar a identidade de um usuário é usar uma senha ou senha secreta.

É recomendável usar a autenticação multifator segura, como Cartão Inteligente, FIDO e Windows Hello para Empresas. No entanto, a autenticação de senha ainda é necessária em alguns cenários.

Proteger seu ambiente de rede requer que senhas fortes sejam usadas por todos os usuários. Isso ajuda a evitar a ameaça de um usuário mal-intencionado adivinhar uma senha fraca, seja por meio de métodos manuais ou usando ferramentas, para adquirir as credenciais de uma conta de usuário comprometida. Isso é especialmente verdadeiro para contas administrativas. Ao alterar uma senha complexa regularmente, ela reduz a probabilidade de um ataque de senha bem-sucedido.

As configurações de política de senha controlam a complexidade e o tempo de vida das senhas. As políticas de senha afetam as senhas do Windows, não necessariamente as senhas de recursos.

A capacidade dos usuários de modificar suas senhas é regida pelas políticas de senha e pelas interfaces disponíveis. Por exemplo, por meio da Área de Trabalho Segura, os usuários podem alterar sua senha a qualquer momento com base nas políticas de senha administradas pelo administrador do sistema ou pelo administrador de domínio. Recursos como Windows Vault, BitLocker e Encrypting File System permitem que os usuários modifiquem senhas específicas para esse recurso.

Como as senhas são usadas no Windows

Quando um usuário faz logon, a senha que o usuário digita é convertida em ambos os tipos de funções unidirecionais e mantida na memória pelo processo LSASS (Serviço de Subsistema da Autoridade de Segurança Local). Se o usuário estiver usando uma conta local para autenticação, a OWF do NT será comparada com o hash do NT armazenado localmente e, se os dois corresponderem, o usuário será conectado. Se o usuário estiver se autenticando em um domínio do Active Directory usando um nome de host para acessar um recurso, o hash do NT será usado em um logon Kerberos no KDC (Centro de Distribuição de Chaves), que normalmente é o controlador de domínio.

O Kerberos não pode ser usado nas seguintes situações:

• Autenticação em um domínio que executa apenas Windows NT 4.0 ou anterior
• Acessar um recurso em um membro de domínio do Active Directory usando um endereço IP em vez de um nome de host
• Acessar um recurso em um computador que não é membro de um domínio do Active Directory
• Acessar um recurso em um computador que seja membro de um domínio do Active Directory, mas não seja confiável para seu domínio
• Acessar qualquer recurso em um computador em execução que não dá suporte ao Kerberos

Nessas situações, o processo de autenticação usa dois protocolos diferentes, denominados LAN Manager e NTLM. O processo começa com o cliente solicitando um desafio do servidor de autenticação. Depois que o desafio é recebido, o cliente calcula uma resposta a esse desafio. Isso é feito primeiro preenchendo os dois hashes da senha com valores nulos para 168 bits. Os 168 bits de cada hash são divididos em três chaves DES de 56 bits. As seis chaves DES são usadas para criptografar o desafio. Os três textos codificados produzidos usando o hash do LM são concatenados e se tornam a resposta do LAN Manager. Os três textos codificados produzidos usando o hash do NT são concatenados e se tornam a resposta do NTLM.

As funções usadas para calcular a resposta podem ser modificadas pela configuração Nível de Compatibilidade do LM na Segurança de rede: configuração de Política de Grupo de nível de autenticação do LAN Manager. Se esse valor for definido como 1 ou inferior, o cliente enviará as respostas originais do LAN Manager e do NTLM. Se for definido como 2, somente a resposta NTLM será enviada. Se for definido como 3 ou superior, uma nova versão de ambos os protocolos será usada. A versão do NTLM é chamada de NTLMv2. A versão do LAN Manager geralmente é conhecida como LMv2. Ambos os protocolos usam o hash do NT para calcular a resposta e ambos usam um desafio do lado do cliente, em vez de ou além do desafio do servidor. Além disso, se a configuração Nível de Compatibilidade do LM estiver definida como 1 ou superior, a resposta do NTLM receberá um carimbo de data e hora para ajudar a evitar ataques de reprodução. Para obter informações sobre a configuração Nível de Compatibilidade do LM, consulte Segurança de rede: nível de autenticação do LAN Manager.

Senhas fortes

As senhas fornecem a primeira linha de defesa contra o acesso não autorizado à sua organização. A partir do Windows Server 2003, o Windows verifica a complexidade da senha da conta de Administrador durante a instalação do sistema operacional. Se a senha estiver em branco ou não atender aos requisitos de complexidade, a caixa de diálogo Configuração do Windows solicitará que você crie uma senha forte para a conta administrador. Se deixar essa senha em branco, não poderá acessar essa conta pela rede.

Senhas fracas fornecem aos invasores acesso fácil aos computadores e à rede, enquanto senhas fortes são consideravelmente mais difíceis de quebrar. A tabela a seguir compara senhas fracas e fortes.

Senha fraca	Senha forte
Em branco	Tem pelo menos sete caracteres
Contém informações facilmente detectáveis ou conhecidas, como nome de usuário ou nome de domínio	Contém informações "secretas" ou aleatórias
É semelhante às senhas anteriores	É significativamente diferente das senhas anteriores
Contém uma palavra de dicionário completa	Contém uma combinação dos seguintes caracteres: – Letras maiúsculas – Letras minúsculas – Numerais – Símbolos incluindo espaços

Um exemplo de uma senha forte é J*p2leO4>F.

Uma senha pode atender à maioria dos critérios de uma senha forte, mas ainda assim ser bastante fraca. Por exemplo, Hello2U! é uma senha relativamente fraca, embora atenda à maioria dos critérios para uma senha forte e também atenda aos requisitos de complexidade da política de senha. H!elZl2o é uma senha forte porque a palavra do dicionário é intercalada com símbolos, números e outras letras. É importante instruir os usuários sobre os benefícios de usar senhas fortes e ensiná-los a criar senhas realmente fortes.

Crie senhas que contêm caracteres do conjunto de caracteres ANSI estendido. O uso de caracteres ANSI estendidos aumenta o número de caracteres que você pode escolher ao criar uma senha. Como resultado, pode levar mais tempo para o software de quebra de senha quebrar senhas que contêm esses caracteres ANSI estendidos do que para quebrar outras senhas. Antes de usar caracteres ANSI estendidos em sua senha, teste-os minuciosamente para garantir que as senhas que contêm caracteres ANSI estendidos sejam compatíveis com os aplicativos que sua organização usa. Tenha cuidado especialmente com o uso de caracteres ANSI estendidos em senhas se sua organização usar vários sistemas operacionais diferentes. Por exemplo, esses sistemas podem padronizar no ISO-8859-15. A implementação real do protocolo no Windows geralmente usa UNICODE ou UTF8 em vez da codificação ANSI real.

Exemplos de senhas que contêm caracteres do conjunto de caracteres ANSI estendido são kUµ!¶0o and Wf©$0k#»g¤5ªrd.

Frases secretas no Windows

Uma frase secreta é uma forma diferente de senha baseada em token na qual os tokens são palavras em vez de símbolos de um conjunto de caracteres. Um exemplo de frase secreta é uma frase que contém caracteres especiais, numerais, letras maiúsculas e letras minúsculas. As principais diferenças entre frases secretas e senhas são:

• Uma frase secreta geralmente tem espaços, as senhas não.
• Uma frase secreta é muito mais longa do que a grande maioria das palavras, e, mais importante, mais longa do que qualquer cadeia aleatória de letras que uma pessoa comum poderia lembrar.

Frases secretas que estão em conformidade com o limite de caracteres definido na política geralmente são mais difíceis de quebrar do que senhas porque contêm mais caracteres. É o hash do LM e do NT que armazena a senha ou a frase secreta, e o hash do LM é o mais fraco dos dois.

Há várias maneiras de garantir que o hash do LM não esteja armazenado, uma delas é usar senhas ou frases secretas com mais de 14 caracteres. Você também pode usar a Segurança de rede: não armazene o valor de hash do LAN Manager na próxima configuração de Política de Grupo de alteração de senha. O uso dessa configuração de política desativa globalmente os hashes de LM de armazenamento para todas as contas. A alteração entrará em vigor na próxima vez que a senha for alterada. Como o efeito da política não é imediato, você não observará imediatamente os possíveis problemas de interoperabilidade causados por não armazenar hashes de LM.

Políticas de senha local disponíveis no Windows

É possível implementar uma configuração de política de senha que impõe requisitos de complexidade de senha. Para obter mais informações sobre essa configuração de política, confira A senha deve atender aos requisitos de complexidade. Para obter informações sobre como aplicar uma política de senha, consulte Aplicar ou modificar uma Política de Senha. Para obter informações sobre todas as configurações de política de senha disponíveis, consulte Política de Senha.

Política de senha refinada disponível por meio do AD DS (Active Directory Domain Services)

A partir do Windows Server 2008, é possível usar políticas de senha refinada para especificar várias políticas de senha e aplicar diferentes restrições de senha e políticas de bloqueio de conta a diferentes conjuntos de usuários em um único domínio. Por exemplo, para aumentar a segurança de contas privilegiadas, aplique configurações mais rigorosas às contas privilegiadas e aplique configurações menos rigorosas às contas de outros usuários. Ou, em alguns casos, talvez deseje aplicar uma política especial de senha a contas cujas senhas sejam sincronizadas com outras fontes de dados.

Para armazenar políticas de senha refinadas, existem duas novas classes de objeto no esquema do AD DS:

• Contêiner de Configurações de Senha
• Configurações de Senha

Para obter mais informações sobre essas políticas, consulte AD DS: políticas de senha refinadas.