Broken Authentication

Referencia:

https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authenticationhttps://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring.html

Objetivo:

Este procedimento tem como objetivo adequar todos os desenvolvimentos realizados pelo grupo Co.Action no item Broken Authentication estabelecido no documento "OWASP Top 10 vulnerabilities". 
Todos desenvolvimentos futuros dentro do grupo deverão ser revisados de maneira a estar adequados ao padrão aqui estabelecido.

Descrição: Broken Authentication é um termo abrangente para várias vulnerabilidades que os invasores exploram para invadir um sistema. Abaixo são alguns requisitos para prevenir que isto ocorra:

1. Usar senha em texto normal ou com hash fraco.
2. Verificar sistema de recuperação de login/senha.
3. Permitir usuário e senhas comuns (admin pass).
4. Não usar, ou não efetivo, two way factor.
5. Não alterar session IDs após o login ou não invalidar session IDs.
6. Verificar força da senha.
7. Proteção contra login de força bruta.
8. Enumeração de nome de usuário / senha.

Usar senha em texto normal ou com hash fraco:

      As senhas são a principal porta de entrada para ataques, os invasores, procuram por dados de texto não criptografados, para forçar a entrada no sistema.

      As senhas armazenadas no banco de dados devem possuir criptografia do tipo SHA-1 ou superior com algum gerador randômico SALT, a criptografia deve ser de apenas uma via. 

Verificar sistema de recuperação de login/senha

      Não deve ser utilizado para recuperação de credenciais processos fracos ou ineficazes, como, “respostas baseadas em conhecimento”, que não podem ser protegidos.

      A recuperação de senha deve ser enviando uma senha provisória para o e-mail registrado, com uma senha provisória que deve obedecer as regras de senha (Permitir usuário e senhas comuns). Essa senha deve ser invalidada após o seu uso.

Permitir usuário e senhas comuns (admin pass)

    As senhas de todos os sistemas devem seguir as seguintes regras:

• Ter pelo menos 8 dígitos;
• Conter letras maiúsculas;
• Conter letras minúsculas;
• Conter números;
• Conter caracteres especiais (Ex: @ # $ % & * " ' ´ ~ [ ] { } / ? ; .  ,);

Não usar, ou não efetivo, two way factor

     A autenticação de dois fatores é uma forma de aumentar a segurança dos produtos, adicionando uma camada extra de segurança, pedindo ao usuário para fornecer uma segunda forma de identificação junto como o e-mail e a senha.

     Todos os sistemas devem oferecer a opção de autenticação TOTP (Time-based One Time Password) como a segunda forma de identificação. Este TOTP é gerado por um aplicativo no dispositivo móvel do usuário, como autenticador Google ou autenticador Microsoft.

Não alterar session IDs após o login ou não invalidar session IDs

    As sessions devem possuir as seguintes regras:

• As credenciais devem ser protegidas: as credenciais de autenticação do usuário devem ser protegidas quando armazenadas usando hashing ou criptografia.
• Não exponha o ID da sessão no URL: os IDs da sessão não devem ser expostos no URL (por exemplo, regravação do URL).
• Os IDs de sessão devem atingir o tempo limite: as sessões de usuário ou tokens de autenticação devem ser devidamente invalidados durante o logoff.
• Recriar IDs de sessão: IDs de sessão devem ser recriados após o login bem-sucedido.
• Não envie credenciais por conexões não criptografadas: senhas, IDs de sessão e outras credenciais não devem ser enviadas por conexões não criptografadas.

Verificar força da senha

     Todas as telas que solicitem o cadastro de senha, como (cadastro/atualização) devem possuir um indicador para mostrar a força da senha, seguindo os passos para validar a senha.

Proteção contra login de força bruta

    Força a desativação da conta após um número estabelecido de tentativas de login inválidas (por exemplo, cinco tentativas é comum). A conta deve ser desativada por um período de tempo suficiente para desencorajar a adivinhação de força bruta de credenciais, mas não tanto para permitir que um ataque de negação de serviço seja executado.

Enumeração de nome de usuário / senha:

      As respostas de falha de autenticação não devem indicar qual parte dos dados de autenticação estava incorreta. Por exemplo, em vez de "Nome de usuário inválido" ou "Senha inválida", apenas use "Nome de usuário e / ou senha inválidos" para ambos. As respostas de erro devem ser verdadeiramente idênticas na exibição e no código-fonte.