Novas regras de senhas do NIST
O United States National Institute for Standards and Technology (NIST) está formulando novas diretrizes para políticas de senha a serem usadas em todo o governo dos EUA.
Essa nova política, desenvolvida pelo NIST, é de grande importância e traz mudanças significativas no gerenciamento de senhas tradicional, adotado nos dias de hoje, além disso são um grande modelo para utilizarmos dentro de nossas próprias empresas e podem servir como base para programas de desenvolvimento de software e aplicações.
Qualquer pessoa interessada no projeto pode revisa-lo, o nome atribuído é Special Publication 800-63-3: Digital Authentication Guidelines e pode ser acompanhado no Github (https://github.com/usnistgov/800-63-3) ou de uma forma mais acessível no site do NIST (https://pages.nist.gov/800-63-3/).
No início de novembro o pesquisador de segurança Jim Fenton fez uma apresentação no evento PasswordsCon em Las Vegas e resumiu as principais mudanças, confira abaixo.
- Favorecer o usuário: uma das sugestões é tornar a política de senhas mais simples e que favoreçam os usuários. Em outras palavras, precisamos parar de pedir aos usuários para fazer coisas que não estão realmente melhorando a segurança.
- Tamanho da senha: as novas diretrizes do NIST dizem que as senhas precisam ter no mínimo 8 caracteres, mas pode-se aumentar o mínimo da senha caso seja utilizada em contas mais sensíveis.
Segundo o NIST, você deve permitir um comprimento máximo de pelo menos 64 caracteres e as aplicações devem permitir todos os caracteres ASCII imprimíveis, incluindo espaços - também devem aceitar todos os caracteres UNICODE, incluindo emoji!
Este é, sem dúvida, um grande passo e ainda devemos considerar que as senhas devem ser Hashed e Salted quando armazenadas, e por este motivo não deve haver restrições desnecessárias de comprimento de caracteres.
- Verifique se as novas senhas são fracas e/ou uma escolha ruim: o conceito aqui é sua aplicação não deixar que as pessoas usem senhas conhecidas como 123456, senha , mudar123 e assim por diante.
Segundo Jim Fenton, uma lista de 100.000 senhas conhecidas é um bom ponto de partida.
O que não deve ser feito
Agora entra a parte interessante da norma, e que quebra diversos mitos sobre a geração de senha.
Sem regras de composição: o que isto significa é que, não existem mais regras que forçam você a usar caracteres específicos ou combinações, como as condições assustadoras em algumas páginas de redefinição de senha que dizem: "Sua senha deve conter uma letra minúscula, uma letra maiúscula, dois números e caracteres especiais como &”%#@_".
Permita que as pessoas escolham livremente sua senha e incentive composições mais longas usando frases em vez de complexidades ou substituições como S3nh4 ou P4ssw+rd.
Não use lembre de senha: os lembretes de senha permitem que ela seja descoberta de forma muito fácil, por exemplo um usuário pode colocar o lembrete de senha como “nome do gato” e o nome do gato ser “floki” e que com certeza poderá ser facilmente identificar em alguma rede social.
Não use Knowledge-based authentication (KBA): para quem não sabe, o KBA é muito utilizado quando precisamos recuperar uma senha e normalmente o site pede para você definir uma lista de perguntas como: "Qual o nome do seu animal de estimação?” ou “Qual é a sua equipe de futebol favorita?”, através dessas perguntas você colocar a resposta e ele te identifica.
Nem preciso mencionar, mas este tipo de pergunta, como na opção anterior, pode ser facilmente descoberta com mapeamento em redes sociais.
Não use a expiração de senhas sem necessidade: este também é um dos grandes pontos da norma, pois como sabemos é muito comum configurar a expiração de senhas, mas se deseja que os usuários cumpram a exigência de criar senhas difíceis de adivinhar, nós não devemos fazê-los mudar as senhas de forma desnecessária ou constantemente.
A única vez que as senhas devem ser redefinidas é quando elas são esquecidas, se forem alvo de ataques ou se você acha (ou sabe) que seu banco de dados de senha foi roubado e, portanto, poderia ser submetido a um ataque de força bruta offline.
SMS como Two-Factor Authentication: o SMS não deve mais ser usado na autenticação de dois fatores (2FA).
Há muitos problemas com a segurança da entrega de SMS, incluindo malware que pode redirecionar mensagens de texto; ataques contra a rede de telefonia móvel, interceptação de mensagens, entre outros.
Para finalizar o NIST também fornece outros conselhos de como a senha deve ser armazenada em base de dados e a sua sugestão é que todas as senhas devem ser hashed, salted e stretched. Você precisa de um salt de 32 bits ou mais, uma chave hash HMAC usando SHA-1, SHA-2 ou SHA-3, e o algoritmo de "stretching" usando PBKDF2 com pelo menos 10.000 iterações.
Com essa nova norma o objetivo do NIST é conseguir que a segurança seja mais efetiva e confiável, sem as complexidades desnecessárias que existem hoje em dia, e sabemos que a complexidade funciona contra a segurança.
0 comentários: