Broken Authentication

O que é?

• Formas de se obter as credenciais de usuários e se passar por eles;
• Segunda posição no rank de riscos de 2017 da OWASP (most critical security risks to web applications)

Exemplos

Ameaça 1 - Credential stuffing

Atacantes utilizam combinações de usuários e senhas vazadas de sites para fazer ataques automatizados em diversos sites. Embasamento: pesquisas indicam que 81% dos usuários utilizam a mesma senha em vários sites.

Prevenção

• Utilizar MFA (multi-factor authentication);
• Secondary Passwords, PINs and Security Questions;
• CAPTCHA;
• CSRF token no form de login;
• Aconselhe usuários a não reutilizar senhas e a ficarem atentos à vazamentos de senha (https://haveibeenpwned.com/);

Ameaça 2 - Brute force guessing

Ataques de força bruta automatizados com combinações de username e senha.

Prevenção

• Limitar o número de tentativa consecutivas de autenticação;
• Evitar expor detalhes da falha na autenticação. Ex: email inexistente, usuário não cadastrado, senha incorreta.
• Utilizar rotação de senhas;
• Utilizar MFA (multi-factor authentication);
• Secondary Passwords, PINs and Security Questions;
• CAPTCHA;
• CSRF token no form de login;

Ameaça 3 - Weak passwords

Permitir utilização de senhas fracas ou default (admin/admin, por exemplo);

Prevenção

• MFA;
• Secondary Passwords, PINs and Security Questions;
• Validar a força da senha do usuário;
• Validar contra uma lista de senhas frequentes: https://github.com/danielmiessler/SecLists/tree/master/Passwords

Ameaça 4 - Weak password recovery process

Uso de processos de recuperação de credenciais fracos. Exemplo: perguntas e respostas;

Prevenção

• Antes de iniciar o processo de recuperação, faça perguntas de segurança sobre dados coletados do usuário: ano de nascimento, nome da mãe, jogo favorito, etc.
• Envie o link/token de recuperação por um canal secundário seguro (usualmente, email).
• O link/token deve ter um período curto de validade (sugerido 20 minutos);
• Nunca envie uma nova senha diretamente. Permita que o usuário redefina sua senha (armzenamento inseguro de senha);
• Ao finalizar o processo de recuperação, finalize qualquer sessão aberta do usuário;
• Gere log de todo o procedimento: processo iniciado, perguntas respondidas incorretamente, quando a mensagem foi enviada, quando a senha foi alterada, IPs de origem, etc.

Ameaça 5 - Weak password storage and transport

Uso de senhas em plain text, criptografadas ou com algoritmos fracos de hashing que podem ser quebrados com uma rainbow table.

Prevenção

• Usar algoritmos recentes de hashing e com salting para salvar credenciais. Não utilize criptografia a menos que exista algum requisito muito forte. O fato da senha poder ser recuperada é um risco de segurança. Algoritmos recomendados que já incluem o salt por default: Argon2 (vencedor da competição de algoritmos de hashing de 2015) or Bcrypt.
• O salt deve ser único para cada usuário (salts protegem de ataques de rainbow tables);
• Usar transporte de dados criptografado (ex.: HTTPS, SSL)
• Usar uma pepper. A pepper é um pedaço único adicionado a todas as senhas e que não é salvo no storage. Isso adicionar uma dificuldade aos atacantes que conseguem acesso direto aos dados do storage, como SQL Injection ou backups.

The pepper should be at least 32 characters long and should be randomly generated. It should be stored in an application configuration file (protected with appropriate permissions) using the secure storage APIs provided by the operating system, or in a Hardware Security Module (HSM). The pepper is traditionally used in a similar way to a salt by concatenating it with the password prior to hashing, using a construct such as hash($pepper . $password).

• Algoritmos legados: SHA-512 > SHA-256 > SHA-1 > MD5

Ameaça 6 - Session hijacking

• Sequestro de sessão (session hijacking). O atacante consegue acesso à uma sessão iniciada pelo usuário e altera seus dados. Exemplo: um usuário inicia uma sessão e simplesmente fecha o browser. Outra pessoa assume o computador e a sessão ainda está aberta.

  • Exposição de session id na URL: isso pode vazar o session id em logs, links compartilhados, etc.
  • Reuso de session ids entre logins;
  • Timeout muito longo para invalidação de sessão;

Prevenção

• O session id deve ser longo o suficiente para evitar ataques de força bruta (no mínimo 128 bits/ 16 bytes)
• Prefira utilizadar cookies para armazenar o session id pois eles possuem mecanismos de transporte seguro (HTTPS) e expiração.
• Sempre use secure, http only, domain restricted e non-persistent cookies;
• Sempre gere um session id novo a cada login;
• Sempre invalide cookies e tokens de sessão no logout ou após um período de inatividade;

Histórias de Terror

Credential stuffing

In October–November 2016, attackers gained access to a private GitHub repository used by Uber (Uber BV and Uber UK) developers, using employees' usernames and passwords that had been compromised in previous breaches. The hackers claimed to have hijacked 12 employees' user accounts using the credential stuffing method, as email addresses and passwords had been re-used on other platforms. Multi-/two-factor authentication, though available, was not activated for the affected accounts. The hackers subsequently located credentials for the company's AWS datastore in the repository files, and were therefore able to obtain access to the records of 32 million non-US users and 3.7 million non-US drivers, as well as other data contained in over 100 S3 buckets. The attackers alerted Uber, demanding payment of $100,000 to agree to delete the data. The company paid through a 'bug bounty program', but did not disclose the incident to affected parties for over a year. After the breach came to light, the company was fined £385,000 (downsizeable to £308,000) by the UK Information Commissioner's Office.[9]

Referências

Site da OWASP 2017 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication