Por que você deve se preocupar sempre que o banco de dados de senhas de um serviço é vazado

“Nosso banco de dados de senhas foi roubado ontem. Mas não se preocupe: suas senhas foram criptografadas. ” Vemos regularmente declarações como esta online, inclusive ontem, do Yahoo . Mas devemos realmente aceitar essas garantias pelo valor de face?

A realidade é que o comprometimento do banco de dados de senha é uma preocupação, não importa o quanto uma empresa tente manipulá-lo. Mas existem algumas coisas que você pode fazer para se isolar, não importa o quão ruins sejam as práticas de segurança da empresa.

Como as senhas devem ser armazenadas

Veja como as empresas devem armazenar senhas em um mundo ideal: você cria uma conta e fornece uma senha. Em vez de armazenar a própria senha, o serviço gera um “hash” a partir da senha. Esta é uma impressão digital única que não pode ser revertida. Por exemplo, a senha “senha” pode se transformar em algo que se parece mais com “4jfh75to4sud7gh93247g…”. Quando você insere sua senha para efetuar login, o serviço gera um hash a partir dela e verifica se o valor do hash corresponde ao valor armazenado no banco de dados. Em nenhum momento o serviço salva sua própria senha no disco.

Para determinar sua senha real, um invasor com acesso ao banco de dados teria que pré-computar os hashes para senhas comuns e, em seguida, verificar se eles existem no banco de dados. Os invasores fazem isso com tabelas de pesquisa – listas enormes de hashes que correspondem às senhas. Os hashes podem então ser comparados ao banco de dados. Por exemplo, um invasor saberia o hash para “senha1” e veria se alguma conta no banco de dados está usando esse hash. Se estiverem, o invasor sabe que sua senha é “senha1”.

Para evitar isso, os serviços devem “salgar” seus hashes. Em vez de criar um hash da própria senha, eles adicionam uma string aleatória à frente ou ao final da senha antes de fazer o hash. Em outras palavras, um usuário digitaria a senha “senha” e o serviço adicionaria o salt e o hash de uma senha que se parece mais com “senha35s2dg”. Cada conta de usuário deve ter seu próprio salt exclusivo, e isso garantiria que cada conta de usuário teria um valor hash diferente para sua senha no banco de dados. Mesmo se várias contas usassem a senha “password1”, elas teriam hashes diferentes devido aos diferentes valores de sal. Isso derrotaria um invasor que tentasse pré-computar hashes para senhas. Em vez de ser capaz de gerar hashes que se aplicam a todas as contas de usuário em todo o banco de dados de uma vez, eles teriam que gerar hashes exclusivos para cada conta de usuário e seu sal exclusivo. Isso levaria muito mais tempo de computação e memória.

É por isso que os serviços costumam dizer para não se preocupar. Um serviço que usa procedimentos de segurança adequados deve informar que está usando hashes de senha com sal. Se eles simplesmente estiverem dizendo que as senhas estão “hash”, isso é mais preocupante. O LinkedIn fez hash em suas senhas, por exemplo, mas não as salgou – então foi um grande negócio quando o LinkedIn perdeu 6,5 milhões de senhas com hash em 2012 .

Práticas de senha inadequadas

Isso não é a coisa mais difícil de implementar, mas muitos sites ainda conseguem bagunçar de várias maneiras:

• Armazenando senhas em texto simples : em vez de se preocupar com hash, alguns dos piores criminosos podem simplesmente despejar as senhas em texto simples em um banco de dados. Se esse banco de dados for comprometido, suas senhas estarão obviamente comprometidas. Não importaria o quão fortes eles eram.
• Hashing as senhas sem salgá-las : Alguns serviços podem fazer o hash das senhas e desistir, optando por não usar sais. Esses bancos de dados de senha seriam muito vulneráveis ​​a tabelas de pesquisa. Um invasor pode gerar os hashes para muitas senhas e, em seguida, verificar se eles existem no banco de dados – eles podem fazer isso para todas as contas de uma vez, se nenhum sal for usado.
• Reutilização de sais : alguns serviços podem usar um sal, mas podem reutilizar o mesmo sal para cada senha de conta de usuário. Isso é inútil – se o mesmo salt fosse usado para todos os usuários, dois usuários com a mesma senha teriam o mesmo hash.
• Usando sais curtos : Se sais de apenas alguns dígitos forem usados, seria possível gerar tabelas de pesquisa que incorporam todos os sal possíveis. Por exemplo, se um único dígito fosse usado como sal, o invasor poderia facilmente gerar listas de hashes que incorporavam todos os sal possíveis.

As empresas nem sempre lhe contarão toda a história, portanto, mesmo que digam que uma senha foi hash (ou hash e salgada), podem não estar usando as melhores práticas. Sempre erre pelo lado da cautela.

Outras Preocupações

É provável que o valor salt também esteja presente no banco de dados de senhas. Isso não é tão ruim – se um valor de sal exclusivo fosse usado para cada usuário, os invasores teriam que gastar grandes quantidades de energia da CPU quebrando todas essas senhas.

Na prática, tantas pessoas usam senhas óbvias que provavelmente seria fácil determinar as senhas de muitas contas de usuário. Por exemplo, se um invasor conhece o seu hash e conhece o seu salt, ele pode verificar facilmente se você está usando algumas das senhas mais comuns.

Se um invasor descobrir por você e quiser quebrar sua senha, ele pode fazer isso com força bruta, desde que conheça o valor do sal – o que provavelmente é verdade. Com acesso local offline a bancos de dados de senha, os invasores podem empregar todos os ataques de força bruta que desejarem.

Outros dados pessoais provavelmente vazam quando um banco de dados de senha é roubado: nomes de usuário, endereços de e-mail e muito mais. No caso do vazamento do Yahoo, perguntas e respostas de segurança também vazaram – o que, como todos sabemos, torna mais fácil roubar o acesso à conta de alguém.

Ajuda, o que devo fazer?

O que quer que um serviço diga quando seu banco de dados de senhas é roubado, é melhor presumir que todo serviço é completamente incompetente e agir de acordo.

Primeiro, não reutilize senhas em vários sites. Use um gerenciador de senhas que gera senhas exclusivas para cada site . Se um invasor conseguir descobrir que sua senha para um serviço é “43 ^ tSd% 7uho2 # 3” e você só usar essa senha naquele site específico, ele não aprenderá nada de útil. Se você usar a mesma senha em todos os lugares, eles podem acessar suas outras contas. É assim que as contas de muitas pessoas são “hackeadas”.

Se um serviço for comprometido, certifique-se de alterar a senha que você usa lá. Você também deve alterar a senha em outros sites se reutilizá-la neles – mas não deveria fazer isso em primeiro lugar.

Você também deve considerar o uso de autenticação de dois fatores , que o protegerá mesmo se um invasor descobrir sua senha.

O mais importante é não reutilizar senhas. Bancos de dados de senha comprometidos não podem prejudicá-lo se você usar uma senha exclusiva em todos os lugares – a menos que eles armazenem algo importante no banco de dados, como o número do seu cartão de crédito.

Crédito da imagem: Marc Falardeau no Flickr , Wikimedia Commons