Vamos fazer o usuário usar uma senha segura

Era



uma vez , bastava ter uma avó malvada na entrada da sala de máquinas para proteger a senha.Há muito tempo, nos tempos dos primeiros mainframes, havia uma excelente autenticação de dois fatores. Antes de inserir sua senha pessoal no terminal, era necessário passar pelo estande com um guarda. Tudo isso reduziu automaticamente a superfície de ataque a algumas pessoas que tinham acesso físico ao terminal. Foi então que surgiram modems, hashing e outras alegrias do mundo moderno, quando as senhas vazavam regularmente aos milhões.



Se você tiver usuários e eles fizerem login com uma senha, sugiro que dê uma outra olhada nas recomendações mais recentes de organizações como o Instituto Nacional de Padrões e Tecnologias e o Centro Nacional de Segurança Cibernética .



Em particular, não está mais na moda exigir a rotação da senha. E para exigir certos símbolos nas melhores tradições da piada sobre "ROSA DE FUCKING" também. Vamos revisar os pontos principais e tentar tornar os usuários mais convenientes e seguros.

A autenticação não é binária

Não, eu entendo que os adeptos de formulações estritas agora começarão a se ressentir. Em teoria, o usuário está logado ou não. Você não conseguirá entrar um pouco. No entanto, os guias de segurança da informação modernos implicam em uma abordagem não binária para a confiança do usuário.



Um usuário perfeitamente confiável conseguiu inserir a senha corretamente e se conectar a partir de um dispositivo autorizado. Um pouco menos confia em um usuário que se conectou a partir de um dispositivo confiável, mas cometeu um erro ao digitar a senha. E é muito ruim se o usuário inseriu a senha corretamente, mas o dispositivo não é confiável, o segundo fator não é confirmado e o IP pertence ao nó de saída de Thor. No terceiro caso, é hora de puxar o interruptor com a inscrição “Alarme! O lobo roubou os coelhos! "



Nossa tarefa, como pessoas que prestam o serviço, é deixar as pessoas confortáveis, seguras e não muito dolorosas se cometerem erros. Portanto, vale a pena colocar certos sinais de atividade anormal, a fim de incluir certas medidas adicionais para proteger a conta. Por exemplo, depois de 3-5 entradas de senha incorretas, solicite ao usuário que passe pelo CAPTCHA. Sim, todo mundo odeia, mas a maioria dos usuários não o encontrará. E aqueles que reduziram sua classificação de confiança simplesmente diminuirão um pouco a velocidade antes de inserir a senha novamente. Mas vamos interromper os ataques automáticos de força bruta.

Não há necessidade de limitar o comprimento máximo da senha

Senhas longas são mais seguras. Permita que os usuários os usem.



Bem, não que não seja necessário. Senhas em negrito com vários megabytes de comprimento podem causar transbordamentos em lugares inesperados ou outros efeitos estranhos. Mas o comprimento máximo condicional de 300 caracteres é garantido para atender a qualquer usuário típico. Além disso, o NIST segue as mesmas recomendações:

O autenticador deve permitir que o usuário use senhas memorizáveis ​​de pelo menos 64 caracteres.

E para serviços especialmente talentosos, o NIST também fornece outra recomendação importante:

Truncar a senha do usuário não é permitido.

Sim, existem serviços extremamente estranhos que acreditam que 12 caracteres serão suficientes, o que significa que os 28 restantes podem ser cortados com segurança e verificar o hash apenas do primeiro fragmento. Não sei o que a mente afetada pensou sobre isso, mas as mesmas organizações bancárias costumam sofrer com isso. Não faça isso. Se o usuário quiser usar uma peça da Ilíada pela metade com fragmentos de textos do grupo Bloodstock, deixe-o usar.

Certifique-se de que todos os caracteres ASCII são válidos

Existem alguns problemas com caracteres especiais. Por exemplo, o uso de "{} / \" ou outros caracteres semelhantes pode ser potencialmente inválido em algumas situações. Digamos que as chaves podem quebrar um JSON válido e fazer com que o processamento de senha travar. Ou o caractere apóstrofo, que pode ser usado na injeção de SQL. Sim, o formulário de entrada de senha também pode ser uma porta de entrada para um ataque.



Em teoria, você poderia simplesmente proibir o uso de tais símbolos para torná-lo mais fácil para você. Mas, ao fazer isso, você reduzirá a entropia da senha do usuário e tornará inconveniente para ele se a senha for gerada automaticamente. Você terá que selecionar certos padrões para exceções. Novamente, referindo-se ao Marx NIST:

Todos os caracteres ASCII [RFC 20] para impressão, incluindo espaço, devem ser senhas válidas. Os caracteres Unicode [ISO / ISC 10646] também devem ser válidos.

Sim. Está tudo correto. Esta é sua dor de cabeça e testes adicionais. Mas se o usuário quiser usar ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ ou මෙයද ඉතා දුෂ්කර මුරපදයකි, deixe-o fazê-lo. Ou adicione um caractere burrito à sua senha para força criptográfica. Tem o direito de.



Além disso, fique para trás em relação ao usuário com a necessidade de usar caracteres especiais. Sim, apenas não toque nele. Deixe-o usar o que quiser. Estudos de vazamentos em massa sugerem que as pessoas ainda usam substituições estúpidas com caracteres especiais, o que não melhora a situação em nada. Especificamente, a Microsoft escreve:

A maioria das pessoas usa padrões semelhantes, como uma letra maiúscula como primeiro caractere, caracteres especiais e números nas duas últimas posições. Os cibercriminosos estão cientes disso e personalizam seus ataques de dicionário com substituições típicas, como "s" para "$", "a" para "@" e "i" para "l".

Sim, a mesma Microsoft, por isso milhões de pessoas todos os meses inventam uma nova senha diferente das anteriores, contendo caracteres especiais e letras em maiúsculas e minúsculas. Eles são os que agora escrevem "Elimine os requisitos de composição de caracteres" em suas diretrizes.



Afinal, no final, utilitários típicos como cain e abel, hashcat, john the ripper podem descobrir uma senha por várias horas ou até minutos em uma placa de vídeo típica, se uma palavra de vocabulário padrão e um padrão de substituição típico forem usados.

Não use dicas de senha

É muito mais seguro enterrar uma senha esquecida para sempre do que armazenar uma dica para o usuário em texto não criptografado no banco de dados.



Em 2013, a Adobe vazou seu banco de dados de senhas. Estava criptografado torto, mas o mais desagradável era que continha dicas para recuperação, que Randal Monroe não deixou de zombar no xkcd.

A mesma opinião é compartilhada pelo NIST, que não recomenda o armazenamento de dicas de nenhuma forma. Esqueceu - restaura por e-mail com todas as verificações adicionais.

Reduza a carga no cérebro do usuário

O National Cyber ​​Security Center lançou um infográfico interessante . Deixe-me citar uma pequena passagem:



Observe que o principal problema com as senhas é que uma boa senha é aleatória e quase impossível de lembrar. Se houver muitos serviços, o usuário usará quase inevitavelmente a mesma senha sempre que possível. O mais avançado fará algo como "myp@ssword_habr.com". Naturalmente, comprometer uma senha em um local compromete automaticamente as contas em todos os outros serviços.

Portanto, deixe o usuário usar gerenciadores de senha. Sim, é como uma carteira especial para cartões bancários que permite perdê-los ao mesmo tempo. Mas aqui você precisa entender que o comprometimento de um armazenamento de senha offline é uma situação bastante rara, em contraste com o comprometimento de senhas idênticas em recursos diferentes. Um gerenciador de senhas não precisa ser perfeito. Precisa ser melhor do que o mesmo tipo de senha em todos os lugares. Não seja como um serviço desagradável que bloqueia a capacidade de colar uma senha em um campo da área de transferência. Isso claramente força o usuário a abandonar o gerenciador de senhas e usar a opção fraca.



O segundo ponto diz que não é necessário forçar o usuário a alterar sua senha se não houver sinais óbvios de seu comprometimento. Isso apenas o motiva a usar o padrão com a mesma senha. É muito melhor dar o alarme se a senha aparecer em um dos muitos dicionários que vazaram. Naturalmente, você não pode permitir que o usuário crie uma senha que já tenha sido incluída nos dicionários.

conclusões

1. Seja gentil com o usuário. Não o force a criar padrões típicos e fazer coisas estúpidas. Requisitos habituais padrão o empurram diretamente para isso. Basta seguir alguns pontos:
2. Use autenticação de chave em vez de senhas, quando aplicável.
3. Não deixe o usuário usar uma senha se ela estiver nos bancos de dados do dicionário. Não importa se ele vazou para lá ou para outra pessoa.
4. , . . .
5. , .
6. , .