Eliminar senhas incorretas usando a proteção de senha do Azure Active Directory

Muitas diretrizes de segurança recomendam não usar a mesma senha em vários locais, torná-la complexa e evitar senhas simples, como Password123. Você pode fornecer aos seus usuários orientações sobre como escolher senhas, mas senhas fracas ou inseguras geralmente são usadas. A proteção de senha do Azure AD detecta e bloqueia senhas fracas conhecidas e suas variantes e também pode bloquear outros termos fracos que são específicos para sua organização.

Com a proteção de senha do Azure AD, as listas globais padrão de senhas banidas são automaticamente aplicadas a todos os usuários em um locatário do Azure AD. Para dar suporte a suas necessidades de negócios e de segurança, você pode definir entradas em uma lista personalizada de senhas banidas. Quando os usuários alteram ou redefinem suas senhas, essas listas de senhas banidas são verificadas para impor o uso de senhas fortes.

Você deve usar recursos adicionais como a autenticação multifator do Azure AD, não apenas confiar em senhas fortes impostas pela proteção de senha do Azure AD. Para obter mais informações sobre como usar várias camadas de segurança para seus eventos de entrada, consulte Sua Se$$nha não importa.

Importante

Este artigo conceitual explica a um administrador como funciona a proteção de senha do Azure AD. Se você for um usuário final já registrado para redefinição de senha por autoatendimento e precisar voltar à sua conta, vá para https://aka.ms/sspr.

Se sua equipe de TI não tiver habilitado a capacidade de redefinir sua própria senha, entre em contato com sua assistência técnica para obter mais assistência.

Lista de senhas proibidas globalmente

A equipe do Azure AD Identity Protection analisa constantemente os dados de telemetria de segurança do Azure AD procurando senhas mais fracas ou comprometidas usadas com frequência. Especificamente, a análise procura termos base que geralmente são usados como base para senhas fracas. Quando são encontrados termos fracos, eles são adicionados à lista de senhas proibidas globalmente. O conteúdo da lista de senhas proibidas globalmente não se baseia em nenhuma fonte de dados externa, mas nos resultados da análise e telemetria de segurança do Azure AD.

Quando uma senha é alterada ou redefinida para qualquer usuário em um locatário do Azure AD, a versão atual da lista de senhas proibidas globalmente é usada para validar a força da senha. Essa verificação de validação resulta em senhas mais fortes para todos os clientes do Azure AD.

A lista de senhas proibidas globalmente é aplicada automaticamente a todos os usuários em um locatário do Azure AD. Não há nada para habilitar ou configurar e não pode ser desabilitado. Essa lista de senhas proibidas globalmente é aplicada aos usuários quando eles alteram ou redefinem sua própria senha por meio do Azure AD.

Observação

Os criminosos virtuais também usam estratégias semelhantes em seus ataques para identificar senhas e variações de baixa segurança comuns. Para melhorar a segurança, a Microsoft não publica o conteúdo da lista de senhas proibidas globalmente.

Lista personalizada de senhas banidas

Algumas organizações desejam melhorar a segurança e adicionar suas próprias personalizações ao topo da lista de senhas proibidas globalmente. Para adicionar suas próprias entradas, você pode usar a lista personalizada de senhas banidas. Os termos adicionados à lista personalizada de senhas banidas devem ser focados em termos específicos da organização, como:

  • Nomes de marcas
  • Nomes de produtos
  • Localizações, como a sede da empresa
  • Termos internos específicos da empresa
  • Abreviações que tenham um significado específico para a empresa

Quando os termos são adicionados à lista personalizada de senhas banidas, eles são combinados com os termos na lista de senhas proibidas globalmente. Os eventos de alteração ou redefinição de senha são validados em relação ao conjunto combinado dessas listas de senhas banidas.

Observação

A lista personalizada de senhas proibidas é limitada a um máximo de 1.000 termos. Ela não foi projetada para bloquear listas muito grandes de senhas.

Para aproveitar ao máximo os benefícios da lista personalizada de senhas banidas, entenda primeiro como as senhas são avaliadas antes de adicionar termos à lista personalizada de senhas banidas. Essa abordagem permite detectar e bloquear com eficiência grandes números de senhas fracas e suas variantes.

Modifique a lista personalizada de senhas banidas em Métodos de Autenticação

Vamos considerar um cliente chamado Contoso. A empresa tem sede em Londres e faz com que um produto seja denominado Widget. Para este cliente de exemplo, seria um desperdício e menos seguro tentar bloquear variações específicas desses termos da seguinte forma:

  • "Contoso!1"
  • "Contoso@London"
  • "ContosoWidget"
  • "!Contoso"
  • "LondonHQ"

Em vez disso, é muito mais eficiente e seguro bloquear apenas os termos básicos da chave, como os exemplos a seguir:

  • "Contoso"
  • "London"
  • "Widget"

O algoritmo de validação de senha bloqueia automaticamente variantes e combinações fracas.

Para começar a usar uma lista personalizada de senhas banidas, conclua o seguinte tutorial:

Ataques de pulverização de senha e listas de senhas comprometidas de terceiros

A proteção de senha do Azure AD ajuda você a se defender contra ataques de pulverização de senha. A maioria dos ataques de pulverização de senha não tenta atacar uma determinada conta individual mais do que algumas vezes. Esse comportamento aumentaria a probabilidade de detecção, seja por meio de bloqueio de conta ou outros meios.

Em vez disso, a maioria dos ataques de pulverização de senha envia apenas um pequeno número de senhas mais fracas conhecidas em relação a cada uma das contas de uma empresa. Essa técnica permite que o invasor pesquise com rapidez uma conta facilmente comprometida e evite possíveis limites de detecção.

A proteção de senha do Azure AD bloqueia com eficiência todas as senhas fracas conhecidas com probabilidade de uso em ataques de pulverização de senha. Essa proteção se baseia em dados reais de telemetria de segurança do Azure AD para criar a lista de senhas proibidas globalmente.

Há alguns sites de terceiros que enumeram milhões de senhas que foram comprometidas em violações anteriores de segurança publicamente conhecidas. É comum que produtos de validação de senha de terceiros sejam baseados em comparação de força bruta contra essas milhões de senhas. No entanto, essas técnicas não são a melhor maneira de melhorar a força geral da senha, considerando as estratégias típicas usadas pelos invasores de pulverização de senha.

Observação

A lista de senhas proibidas globalmente não se baseia em nenhuma fonte de dados de terceiros, incluindo listas de senhas comprometidas.

Embora a lista de proibidos globalmente seja pequena em comparação a algumas listas em massa de terceiros, ela é originada da telemetria de segurança do mundo real em ataques de pulverização de senha reais. Essa abordagem melhora a segurança e a eficácia geral, e o algoritmo de validação de senha também usa técnicas inteligentes de correspondência difusa. A proteção de senha do Azure AD detecta e bloqueia com eficiência milhões de senhas fracas mais comuns de serem usadas em sua empresa.

Cenários híbridos locais

Muitas organizações têm um modelo de identidade híbrida que inclui ambientes de Active Directory Domain Services (AD DS) locais. Para estender os benefícios de segurança da proteção de senha do Azure AD para seu ambiente de AD DS, você pode instalar componentes em seus servidores locais. Esses agentes exigem eventos de alteração de senha no ambiente de AD DS local para obedecer à mesma política de senha do Azure AD.

Para obter mais informações, consulte Impor a proteção de senha do Azure AD para AD DS.

Como as senhas são avaliadas

Sempre que um usuário altera ou redefine a senha, a nova senha é verificada quanto à força e à complexidade validando-a com relação à lista combinada de termos da lista de senhas banidas globais e personalizadas.

Mesmo que a senha do usuário contenha uma senha proibida, ela ainda poderá ser aceita se a senha geral for forte o suficiente em outros aspectos. Uma senha configurada recentemente passará pelas etapas a seguir para avaliar a força geral e determinar se ela deverá ser aceita ou rejeitada:

Etapa 1: Normalização

Primeiro, uma nova senha passa por um processo de normalização. Isso permite que um pequeno conjunto de senhas banidas seja mapeado para um conjunto muito maior de senhas potencialmente fracas.

A normalização tem as duas partes a seguir:

  • Todas as letras maiúsculas são alteradas para letras minúsculas.

  • Em seguida, as substituições de caracteres comuns são executadas, como no exemplo a seguir:

    Letra original Letra substituída
    0 o
    1 l
    $ s
    @ um

Considere o seguinte exemplo:

  • A senha "blank" é banida.
  • Um usuário tenta alterar sua senha para "Bl@nK".
  • Embora "Bl@nk" não seja banido, o processo de normalização converte essa senha em "blank".
  • Essa senha seria rejeitada.

Etapa 2: Verificar se a senha é considerada proibida

Uma senha é examinada quanto a outro comportamento de correspondência e uma pontuação é gerada. Essa pontuação final determina se a solicitação de alteração de senha é aceita ou rejeitada.

Comportamento da correspondência difusa

Correspondência difusa é usada na senha normalizada para identificar se ela contém uma senha encontrada na lista de senhas banidas global ou personalizada. O processo de correspondência baseia-se em uma distância de edição de comparação de um (1).

Considere o seguinte exemplo:

  • A senha "abcdef" é banida.

  • Um usuário tenta alterar sua senha para uma das seguintes:

    • 'abcdeg' - último caractere alterado de 'f' para 'g'
    • 'abcdefg' - 'g' anexado ao final
    • 'abcde' - 'f' à direita foi excluído do final
  • Cada uma das senhas acima não corresponde especificamente à senha banida "abcdef".

    No entanto, uma vez que cada exemplo está a uma edição de 1 do termo banido ‘abcdef’, eles são considerados uma correspondência de “abcdef”.

  • Essas senhas seriam rejeitadas.

Correspondência de subcadeia de caracteres (em termos específicos)

A correspondência de subcadeia é usada na senha normalizada para verificar o primeiro e o último nome do usuário, assim como o nome de locatário. A correspondência de nome de locatário não é feita ao validar senhas em um controlador de domínio AD DS para cenários híbridos locais.

Importante

A correspondência de subcadeia de caracteres é imposta somente para nomes e outros termos, que têm pelo menos quatro caracteres de comprimento.

Considere o seguinte exemplo:

  • Um usuário chamado Poll que deseja redefinir sua senha para "p0LL23fb".
  • Após a normalização, essa senha seria "poll23fb".
  • A correspondência de subcadeia de caracteres determina que a senha contém o primeiro nome do usuário "Poll".
  • Embora "poll23fb" não esteja especificamente em nenhuma das listas de senhas banidas, foi encontrada uma correspondência de subcadeia de caracteres "Poll" na senha.
  • Essa senha seria rejeitada.

Cálculo de pontuação

A próxima etapa é identificar todas as instâncias de senhas banidas na nova senha normalizada do usuário. Os pontos são atribuídos com base nos seguintes critérios:

  1. Cada senha banida encontrada na senha do usuário recebe um ponto.
  2. Cada caractere restante que não faz parte de uma senha banida recebe um ponto.
  3. Uma senha deve ter pelo menos 5 (cinco) pontos para que seja aceita.

Para os próximos dois exemplos, vamos supor que Contoso esteja usando a proteção de senha do Azure AD e tenha "contoso" em suas listas personalizadas de senhas banidas. Vamos supor também que "blank" está na lista global.

No cenário de exemplo a seguir, um usuário altera sua senha para "C0ntos0Blank12":

  • Após a normalização, essa senha se torna “contosoblank12”.

  • O processo de correspondência considera que essa senha contém duas senhas banidas: “contoso” e “blank”.

  • Essa senha então recebe uma pontuação:

    [contoso] + [blank] + [1] + [2] = 4 pontos

  • Como essa senha está abaixo de 5 (cinco) pontos, ela é rejeitada.

Vejamos um exemplo um pouco diferente para mostrar como a complexidade adicional em uma senha pode criar o número necessário de pontos a serem aceitos. No cenário de exemplo a seguir, um usuário altera sua senha para "ContoS0Bl@nkf9!":

  • Após a normalização, essa senha se torna “contosoblankf9!”.

  • O processo de correspondência considera que essa senha contém duas senhas banidas: “contoso” e “blank”.

  • Essa senha então recebe uma pontuação:

    [contoso] + [blank] + [f] + [9] + [!] = 5 pontos

  • Como essa senha tem pelo menos 5 (cinco) pontos, ela é aceita.

Importante

O algoritmo de senhas banidas, juntamente com a lista de senhas proibidas globalmente, pode mudar e muda a qualquer momento no Azure com base em análise e pesquisa de segurança contínuas.

Para o serviço de agente do controlador de domínio local, os algoritmos atualizados só entrarão em vigor depois que o software do agente de controlador de domínio for atualizado.

O que os usuários veem

Quando um usuário tentar redefinir uma senha para alguma que seria proibida, a seguinte mensagem de erro será exibida:

“Infelizmente, sua senha contém uma palavra, uma frase ou um padrão que pode ser facilmente adivinhado. Tente novamente com outra senha”.

Requisitos de licença

Usuários Proteção de senha do Azure AD com a lista global de senhas proibidas Proteção de senha do Azure AD com a lista personalizada de senhas proibidas
Usuários somente na nuvem AD do Azure Gratuito O Azure AD Premium P1 ou P2
Usuários sincronizados pelo AD DS local O Azure AD Premium P1 ou P2 O Azure AD Premium P1 ou P2

Observação

Os usuários locais AD DS que não estão sincronizados com o Azure AD também se beneficiam da proteção de senha do Azure AD com base no licenciamento existente para usuários sincronizados.

Informações adicionais sobre licenciamento, incluindo custos, podem ser encontradas no site de preços do Azure Active Directory.

Próximas etapas

Para começar a usar uma lista personalizada de senhas banidas, conclua o seguinte tutorial:

Você também pode habilitar a proteção de senha do Azure AD local.