Armazenamento de senhas: um dos pilares de segurança

Neste momento, à medida que se aproxima o final do primeiro quarto do século XXI, a maioria das pessoas certamente conscientes de que as senhas de usuários valem como ouro digital e que protegê-las é um aspecto fundamental para garantir a segurança e a privacidade dos dados. Apesar disso, nem todas as empresas gerenciam o armazenamento de senhas de maneira adequada.

Neste post, destacamos como NÃO armazenar as senhas de usuários e quais métodos são usados ​​por serviços que levam a segurança a sério.

O jeito errado: armazenar senhas em texto simples

O método mais simples é armazenar senhas em um banco de dados não criptografado. Quando um usuário tenta fazer login, a autenticação é apenas uma questão de comparar o que ele insere com o que está no banco de dados.

Mas sempre existe o risco de invasores roubarem esse banco de dados de uma forma ou de outra — por exemplo, explorando vulnerabilidades no software da base de dados. Ou uma tabela de senhas pode ser roubada por um funcionário mal-intencionado com altos privilégios de acesso. Credenciais de colaboradores vazadas ou interceptadas também podem ser usadas para roubar senhas. Simplificando, existem muitos cenários em que as coisas podem dar errado. Lembre-se: os dados armazenados em formato aberto são exatamente isso – abertos.

Um jeito “um pouquinho” melhor: senhas criptografadas

E se você armazenar senhas de forma criptografada? Não é uma má ideia à primeira vista, mas não funciona tão bem na prática. Afinal, se você armazenar senhas criptografadas no banco de dados, elas deverão ser descriptografadas todos os momentos para compará-las com a inserida pelo usuário na tentativa de login.

Isso significa que a chave de criptografia estará em algum lugar por perto. Se for esse o caso, essa chave pode facilmente cair nas mãos dos hackers junto com o banco de dados de senhas. Então, isso vai contra todo o propósito de segurança, já que os cibercriminosos serão capazes de descriptografar rapidamente esse banco de dados e obter credencias de acesso em texto simples. E daí voltamos para a estaca zero.

Se toda brincadeira tem um fundo de verdade, os criptógrafos advertem que a codificação não resolve o problema da privacidade dos dados – apenas a transforma em um desafio de armazenamento seguro de chaves. Você pode criar algum esquema que seja capaz de reduzir os riscos, mas em geral não será possível proteger senhas de um jeito confiável, pelo menos não dessa maneira.

O jeito certo: armazenamento de senhas com hashes

O melhor método, portanto, é não armazenar senha nenhuma. Afinal, se você não tem algo, não pode ser roubado, certo?

Mas como verificar se um usuário conectado digitou a senha correta? É aí que entram em ação as funções hash: algoritmos criptográficos especiais que embaralham quaisquer dados em uma sequência de bits de comprimento fixo de maneira previsível, mas irreversível.

Previsível aqui significa que os mesmos dados são sempre convertidos na mesma hash. E irreversível significa que é completamente impossível recuperar os dados com hash. Isso é o que qualquer serviço online que se preocupa um pouco com os dados do usuário faz e que valoriza sua reputação.

Quando um usuário cria uma senha durante o registro, o que será armazenado no banco de dados junto ao nome de usuário não será a senha em si, mas a hash. Então, durante o processo de login, essa hash é comparada à hash da senha inserida pelo usuário. Se corresponderem, significa que as senhas são iguais.

Em caso de vazamento de banco de dados, não são as senhas que os invasores conseguem, mas as hashes, em que os dados originais não podem ser recuperados (irreversibilidade, lembra?). É claro que esta é uma grande melhoria em termos de segurança, mas ainda é muito cedo para nos alegrarmos: se os cibercriminosos colocarem as mãos em hashes, poderão tentar um ataque de força bruta.

O jeito ainda melhor: hashes aleatórias

Após obter seu banco de dados, os hackers podem tentar extrair as senhas por meio de força bruta. Isso significa pegar uma combinação de caracteres, calcular hash e procurar correspondências em todas as entradas do banco de dados. Se nenhuma correspondência for encontrada, eles tentarão outra combinação e assim por diante. Se houver uma correspondência, a senha usada para calcular o hash no banco de dados agora será conhecida.

Pior ainda, o processo de quebra de senhas com hash pode ser otimizado por meio das chamadas tabelas arco-íris. Elas são enormes matrizes de dados com funções hash pré-calculadas para as senhas encontradas com maior frequência. Dessa forma, facilitando a busca por correspondências no banco de dados roubado. E tudo é feito automaticamente, é claro, então o processo de quebra da criptografia é acelerado consideravelmente.

No entanto, há boas notícias: é impossível calcular antecipadamente as hashes de todas as combinações de caracteres possíveis – uma tabela arco-íris completa para qualquer algoritmo de hash ocupará mais espaço em disco do que existe no planeta. Mesmo para o algoritmo MD5, que não é muito confiável, tal tabela hipotética conteria (respirando fundo) 340 282 366 920 938 463 463 374 607 431 768 211 456 registros. É por isso que apenas as combinações mais comuns são incluídas nas tabelas arco-íris.

Para combater o uso de tabelas arco-íris, os especialistas em criptografia criaram uma solução que utiliza outra propriedade importante das funções hash: mesmo a menor alteração no texto fonte altera o resultado do hash de forma irreconhecível.

Antes de uma senha com hash ser calculada e gravada no banco de dados, um conjunto aleatório de caracteres (chamado salt ou sal) é adicionado a ele. Dessa forma, hashes do banco de dados são modificados a tal ponto que mesmo as senhas mais básicas, óbvias e usadas com frequência, como “12345678” e “senha”, não podem ser submetidas à força bruta com tabelas arco-íris.

A variante mais simples usa o mesmo salt para todas as senhas. Mas o mais resistente a hackers cria um salt separado para cada registro individual. A beleza desta abordagem é que esses elementos podem ser armazenados no mesmo banco de dados sem nenhum risco adicional: conhecer o salt não torna a tarefa dos invasores muito mais fácil. Para quebrar os hashes, eles ainda terão que aplicar força bruta – ou seja, passar por cada combinação.

Quanto mais os serviços on-line adotarem esse método de não armazenamento de senhas, menor será a probabilidade de ocorrer um roubo em massa de credenciais de usuários (e os problemas subsequentes associados à invasão de contas).