Entre para a LISTA VIP da Black Friday

00

DIAS

00

HORAS

00

MIN

00

SEG

Clique para saber mais

Como criar uma boa senha

Como criar uma boa senha
Yan Orestes
Yan Orestes

Compartilhe

Como usuário das múltiplas aplicações web, com certeza você já enfrentou algum problema com uma senha. Talvez a tenha esquecido, ou talvez tenha tido uma conta invadida.

Esses dias, decidi criar uma conta em uma rede social que meus amigos gostam. Entretanto,logo quando digitei a senha que eu queria, uma mensagem de erro apareceu na tela falando que minha senha era muito fraca. Pelo visto senha não ia funcionar, mesmo.

Lembrei daquelas regrinhas que todos já ouvimos em algum momento, sobre uma boa senha ter caracteres minúsculos, maiúsculos, números e símbolos, e remodelei ela; dessa vez, deu certo!

Tudo parecia bem, não é? Duas semanas depois, porém, recebo uma notificação - alguém havia invadido minha conta. Obviamente, fiquei indignado! Minha senha seguia aquelas regrinhas que eu aprendi! A senha era Senh@123...

Depois de pesquisar, descobri que minha conta pode ter sido invadida através de um ataque de dicionário, ou _dictionary attack_. Com essa técnica, o atacante, através de um processo automático, tenta ganhar acesso com múltiplas senhas diferentes. Essas senhas geralmente estão em um arquivo chamado de dicionário de senhas - existem vários desses disponíveis na Internet.

Mas qual o problema dessa senha? Como, então, podemos criar uma boa senha? Quais são os aspectos importantes que devemos levar em conta?

Maiúscula, minúscula, número, pontuação - é isso?

Minha senha Senh@123 contém três letras minúsculas, uma maiúscula, um símbolo e três dígitos numéricos. Lembrando do que aprendemos em nossas aulas de matemática, podemos até calcular quantas possibilidades de senha existem.

Temos 26 possibilidades de letras minúscula, mais 26 de maiúsculas, mais 10 caracteres numéricos, mais por volta de 28 caracteres de pontuação, totalizando 90 caracteres possíveis.

Como nossa senha tem 8 caracteres de comprimentos, a conta fica 90⁸, que é igual a 4.304.672.100.000.000 possibilidades!

Digamos que o atacante consegue testar 1000 senhas por segundo. Para testar todas essas possibilidades, ele precisaria de mais de 136 mil anos.

"Uau! Que número gigante! Mas se é assim, como conseguiram descobrir a senha? Foi sorte do atacante?"

Na verdade, o que acontece é que essa conta toda não se aplica à nossa senha, porque ela não é aleatória! Temos mais de 4 quatrilhões de possibilidades no total, mas a nossa não é apenas mais uma nesse monte. Essa senha é deduzível, e é assim que o ataque de dicionário trabalha.

Banner da promoção da black friday, com os dizeres: A Black Friday Alura está chegando. Faça parte da Lista VIP, receba o maior desconto do ano em primeira mão e garanta bônus exclusivos. Quero ser VIP

Seguindo as regras de uma maneira efetiva

O ataque de dicionário, diferente de outros tipos de ataque, como o ataque de força bruta (brute force), não tem o objetivo de tentar todas as possibilidades que existem dentro de um contexto. O que ele faz é, dadas algumas palavras ou grupos de palavras comuns em senhas, tentar o acesso com várias possibilidades para cada palavra, considerando substituições e modificações comuns.

Ou seja, o ataque não vai só verificar se senha funciona, mas também senha123, Senha, senh@123 e, eventualmente, Senh@123. Isso não significa que caracteres especiais e de grupos diversos não fazem diferença, mas que é ilusório entendê-los como garantia de segurança.

Assim, se nossa senha tiver uma base tão simples e usual como senha, substituições comuns como de a para @ e mudanças do gênero de fato não aumentarão muito o nível de segurança desse nosso segredo. Mas e aí, o que devemos mudar?

Se juntarmos um pouquinho de tudo, podemos selecionar uma palavra aleatória, como cordeiro, e tentar fazer algumas modificações não tão usuais. Com algumas alterações, cheguei em C0rd3iro%6 - uma senha já bem mais segura comparada à anterior.

Deixei um tempo parado e fui, finalmente, logar na minha conta. Coloquei meu email e… qual era a senha, mesmo? Cordeiro alguma coisa, um dos o virava 0 e também havia algum símbolo no final, eu acho… Que complicado!

E agora? Será que a complexidade dessa senha é compensada pela segurança que ela traz? Não haveria um método melhor para nós, usuários?

Senhas complexas X senhas longas

Toda esse problema de memorização e usabilidade que esse tipo de senha mais complexa traz é base das principais críticas contra ele. Randall Munroe, cartunista do webcomics xkcd, criou uma tirinha em 2011 brincando um pouco com o tema, que continua sendo muito relevante.

xkcd - senha

Com um ar cômico, a tirinha nos mostra, com cálculos de entropia, que senhas como C0rd3iro%6 não são tão efetivas no quesito de segurança, apesar de serem difíceis de memorizar. Em contrapartida, senhas mais longas, com várias palavras aleatórias, tendem a uma maior facilidade de memorização, ao mesmo tempo que um nível maior de segurança.

Frases-senha com palavras retiradas aleatoriamente de um dicionário podem ser criadas com auxílio de ferramentas como geradores de palavras aleatórias e memorizadas através de diferentes técnicas (que não devem ser muito difíceis), nos garantindo uma senha pouco convencional e, ainda assim, bastante efetiva!

Mas e aí? Criamos nossa frase-senha comprida, com diversas palavras aleatórias, memorizamos e é isso? Podemos usá-la para todas as nossas contas, então?

Senhas únicas para cada conta

Infelizmente, os ataques de dicionário não são o único perigo que nossas senhas enfrentam, hoje em dia. Há casos em que a segurança nem depende de nós, usuários, como quando alguma plataforma armazena as senhas em texto plano, em vez de armazenar uma hash gerada a partir dessa senha.

Há ainda casos que, apesar de dependerem de nós, não dependem exatamente da complexidade de nossa senha, como com malwares que capturam as teclas digitadas, ou até mesmo um caso bobo de alguém observando o teclado enquanto digitamos.

Por conta disso, não podemos confiar em uma única senha para tudo. O ideal é termos senhas completamente diferentes (isto é, que não sigam um mesmo padrão) para cada serviço em que criarmos uma conta. Assim, caso uma de nossas senhas fosse descoberta, por qualquer motivo que seja, nossas outras contas não estariam comprometidas!

Considerando tudo o que já aprendemos, podemos decidir por criar frases-senha diferentes, com palavras diferentes, para cada conta que criarmos. Entretanto, isso geralmente não é viável, afinal quem vai querer ficar memorizando dezenas de frases aleatórias?

Por conta disso, muitos usuários acabam optando pela simplicidade de uma única senha fraca para todos os serviços, em vez do método mais seguro. Mas será que não temos como encaixar usabilidade e segurança, nesse caso?

Usando gerenciadores de senha para evitar a memorização

Depois de tanto procurarmos pela melhor opção de senha, novamente caímos no problema da memorização… Para gente, o melhor seria se realmente não precisássemos memorizar nada, ou pelo menos não muita coisa, mas que ainda assim tivéssemos senhas seguras.

Poderíamos guardar todas as nossas senhas em um único arquivo, para apenas copiarmos e colarmos elas quando fôssemos usar. Mas deixar em um simples arquivo solto seria um grande risco. E se houver um método melhor, que garante a segurança dessas senhas armazenadas?

Para isso, existem os gerenciadores de senha, como o KeePass e o LastPass, que nos ajudam, de forma segura e organizada, a armazenar todas as nossas senhas.

Podemos configurar o acesso a eles com senhas (que podem seguir as recomendações que trabalhamos ao longo do post!) e até com arquivos-chave, no caso do KeePass, necessários para a visualização do banco de dados. Mas se agora vamos guardar nossas senhas em um gerenciador, como devemos criá-las, enfim?

Usando senhas aleatórias como garantia

Agora que não precisamos mais memorizar senhas à toa, podemos abusar ainda mais do aspecto de segurança, gerando nossa senha através de algoritmos de aleatoriedade, o que, como calculamos mais acima, aumenta intensamente o nível de segurança de nossas senhas.

Com um bom comprimento e uma boa variedade de caracteres (que não precisam se restringir aos ASCII, se a plataforma faz um bom trabalho de hashing de senhas), podemos criar senhas (quase) impossíveis de quebrar com métodos de dicionário/força bruta.

Uma senha gerada por esse gerador aleatórios de senhas em emoji, por exemplo, poderia demorar mais de 1,49 X 10⁵² vezes a idade da Terra para ser quebrada, se todas as pessoas do planeta tentassem simultaneamente quebrá-la com um computador diferente a 1 milhão de tentativas por segundo. Basicamente, é improvável que uma senha dessas seja quebrada.

<iframe src="https://yanorestes.github.io/emoji-pwd/" name="myiFrame" scrolling="no" frameborder="0" marginheight="0px" marginwidth="0px" height="80px" width="550px" allowfullscreen=""></iframe>

Para os casos em que precisamos de um acesso mais dinâmico a alguma conta, que não se restrinja a um computador, podemos usar das outras dicas que aprendemos no post.

Além disso, é importante, sempre que possível, utilizar a ferramenta de autenticação de múltiplos fatores, ou _multi-factor authentication_. Com essa configuração, o acesso a uma conta não depende apenas da senha, mas também de fatores externos diversos.

Uma possibilidade é, por exemplo, exigir um código de login por SMS. Assim, estaremos ainda mais seguros, mesmo que nossa senha seja comprometida.

Maior segurança de dados para maior segurança nossa

Apesar de muitas vezes pensarmos não fazer diferença utilizar uma senha (que sabemos que é) fraquíssima, isso não é verdade. Não tomarmos atitudes em prol da segurança de nossos dados pode acabar em grandes prejuízos na nossa vida.

Tratando-se das senhas, entendemos o que torna uma senha segura (e o que pode torná-la insegura). Também aprendemos técnicas efetivas de criação de senhas que podem nos auxiliar bastante como usuários de múltiplos serviços e plataformas.

Gostou do conteúdo? Se quiser se adentrar mais nas tecnicidades da área de segurança da informação, que tal dar uma olhada em nossa Formação Segurança de Aplicações, lá na Alura?

Veja outros artigos sobre DevOps