Eu sou um um pouco cansado de escrever sobre senhas. Mas, assim como os impostos, o e-mail e a conjuntivite, elas não vão desaparecer tão cedo. Aqui está o que eu sei que é verdade e que tem o respaldo de muitos dados empíricos:
-
Não importa o que o senhor diga a eles, os usuários sempre escolherão senhas simples.
-
Não importa o que o senhor diga a eles, os usuários reutilizarão a mesma senha repetidamente em vários dispositivos, aplicativos e sites. Se o senhor tiver sorte, eles poderão usar algumas senhas em vez da mesma.
O que podemos fazer sobre isso como desenvolvedores?
-
Parar de exigir senhase permitir que as pessoas façam login com Google, Facebook, Twitter, Yahoo ou qualquer outra forma válida de Carteira de motorista da Internet que o senhor se sinta confortável em utilizar. A melhor senha é uma que o senhor não precisa armazenar.
-
Incentivar os navegadores a oferecer suporte geração e gerenciamento automáticos e integrados de senhas. O ideal é que o sistema operacional também ofereça suporte, mas isso requer armazenamento em nuvem e todos na mesma página, e isso me parece mais provável por navegador. O Chrome, pelo menos, é caminhando nessa direção.
-
Nag usuários no momento da inscrição quando eles inserem senhas que são …
Isso é comumente feito com um medidor de força da senha no ambienteque fornece feedback em tempo real à medida que o usuário digita.
Se não for possível evitar o armazenamento da senha, os dois primeiros itens que listei acima são sobre evitar a necessidade de o usuário selecionar uma “nova” senha – então, mostrar uma estimativa da força da senha à medida que o usuário digita é o melhor que se pode fazer.
A maneira mais fácil de criar uma senha segura é torná-la longa. Se todas as outras coisas forem iguais, a lei do crescimento exponencial significa que uma senha mais longa é uma senha melhor. É por isso que eu estava sempre fui fã de frases-senhaembora seja excepcionalmente difícil digitá-las por meio da tela sensível ao toque em nosso admirável mundo novo dos dispositivos móveis – e essa é uma falha cada vez mais crítica. Mas quão curto é curto demais?
Quando construímos o Discurso, tive que selecionar um tamanho mínimo absoluto de senha que aceitaríamos. Escolhi um padrão de 8, com base no que eu sabia de minha pesquisa sobre speed hashing. Uma senha de oito caracteres não é ótimomas, desde que o senhor use uma variedade razoável de caracteres, ele deve ser suficientemente resistente a ataques.
Por ataque, não me refiro a um invasor que automatiza uma página da Web ou um aplicativo para inserir senhas repetidamente. Há um pouco disso, por exemplo senhas extremamente comunsmas é improvável que isso seja um ataque prático a muitos sites ou aplicativos, pois eles tendem a ter limites de taxa sobre a frequência e a rapidez com que o usuário pode tentar senhas diferentes.
O que quero dizer com ataque é um ataque off-line de alta velocidade ao hash de sua senhaem que um invasor obtém acesso a um banco de dados de dados de usuários que vazaram. Esse tipo de vazamento acontece o tempo todo. E continuará acontecendo para sempre.
Se o senhor for realmente azarado, os desenvolvedores por trás desse aplicativo, serviço ou site armazenaram a senha em texto simples. Felizmente, isso não acontece mais com muita frequência, graças aos esforços de educação. Progresso! Mas mesmo que os desenvolvedores tenham armazenado corretamente um hash da sua senha em vez da senha real, é melhor o senhor rezar para que eles tenham usado um algoritmo de hash muito lento, complexo e que consome muita memória, como o bcrypt. E que eles selecionaram um número elevado de iterações. Ops, desculpe, isso foi escrito na idade das trevas de 2010 e agora está desatualizado. I queria dizer scrypt. Sim, scrypt, essa é a solução.
Então estamos seguros? Certo? Vejamos.
O senhor pode ler isso e pensar que uma matriz de craqueamento maciço é algo difícil de conseguir. Lamento informar ao senhor que construir uma matriz de, digamos, 24 GPUs de nível de consumidor otimizadas para hashing de velocidade, é bem ao alcance de uma agência de aplicação da lei comum e de praticamente qualquer pequena empresa que possa arcar com um custo de equipamento de US$ 40 mil. Não há necessidade de comprar quando o senhor pode alugar – há muitos servidores em nuvem equipados com GPU atualmente. Além disso, imagine o que um estado-nação motivado poderia fazer. A mente fica confusa.
Mesmo que o senhor não acredite em mim, mas o senhor deveriao cenário de ataque rápido off-line, muito mais fácil de realizar, quase não foi melhor em 37 minutos.
Talvez o senhor seja um cético. Isso é ótimo, eu também. O que acontece quando tentamos uma senha mais longa do random.org na enorme matriz de cracking?
9 caracteres | 2 minutos |
10 caracteres | 2 horas |
11 caracteres | 6 dias |
12 caracteres | 1 ano |
13 caracteres | 64 anos |
O gerador do random.org tem “apenas” letras maiúsculas, minúsculas e números. E se adicionarmos caracteres especiais, a manter o Q*Bert feliz?
8 caracteres | 1 minuto |
9 caracteres | 2 horas |
10 caracteres | 1 semana |
11 caracteres | 2 anos |
12 caracteres | 2 séculos |
Isso é um pouco melhor, mas o senhor não pode realmente se sentir seguro até a marca de 12 caracteres, mesmo com um complemento completo de letras maiúsculas, minúsculas e números, e caracteres especiais.
É improvável que os cenários de cracking em massa fiquem mais lentos. Embora haja definitivamente um comprimento de senha em que todas as tentativas de cracking caem em um precipício exponencial que é efetivamente intransponível, esses números só aumentarão piores com o tempo, e não melhor.
Então, depois de tudo isso, eis o que eu vim dizer ao senhor, pobre usuário lesado:
A menos que sua senha esteja em menos 12 caracteres, o senhor está vulnerável.
Esse deve ser o tamanho mínimo de senha que o senhor deve usar em qualquer serviço. Gere sua senha com algum tipo de gerador off-line, com o dicewareou seu próprio método caseiro de somar palavras, números e caracteres – o que for preciso, mas certifique-se de que todas as suas senhas tenham pelo menos 12 caracteres.
Agora, para ser justo, como aludi anteriormente, tudo isso faz depende muito do algoritmo de hashing que foi selecionado. Mas o senhor deve presumir que todas as senhas que usar terão o hash mais fraco e mais rápido que existe. Um que seja fácil para as GPUs calcularem. Há um lote de software e sistemas antigos, e assim será por muito, muito tempo.
E para os desenvolvedores:
-
Escolha cuidadosamente seus novos algoritmos de hash de senha e mude todos os seus sistemas de hash de senha antigos para hashes muito mais difíceis de calcular. O senhor precisa de hashes que sejam projetados especificamente para serem difíceis de calcular em GPUs, como o scrypt.
-
Mesmo que o senhor escolha o hash “certo”, poderá ficar vulnerável se o fator de trabalho não for alto o suficiente. Matsano recomenda o seguinte:
Mas essas são apenas diretrizes; o senhor precisa dimensionar o trabalho de hashing de acordo com o que está disponível e é razoável no o senhor servidores ou dispositivos. Por exemplo, tivemos um pequeno bug de negação de serviço no Discourse em que permitimos que as pessoas digitassem senhas de até 20.000 caracteres no formulário de login, e o cálculo do hash levou vários segundos.
Agora, se o senhor me der licença, preciso mudar minha senha do PayPal.
[advertisement] Qual é o seu próximo passo na carreira? Carreiras no Stack Overflow tem as melhores listas de empregos de grandes empresas, quer o senhor esteja procurando oportunidades em uma startup ou na Fortune 500. O senhor pode pesquisar em nosso anúncios de emprego ou criar um perfil e deixe que os empregadores encontrem o senhor. |