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. ”Nós regularmente vemos declarações como essa on-line, incluindo ontem, do Yahoo. Mas devemos realmente tomar essas garantias pelo valor de face?

A realidade é que o banco de dados de senha compromete está uma preocupação, não importa como uma empresa possa tentar girá-la. Mas há algumas coisas que você pode fazer para se isolar, independentemente de quão ruins sejam as práticas de segurança de uma 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 senha em si, 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 “password” pode se transformar em algo que se parece mais com “4jfh75to4sud7gh93247g…”. Quando você digita sua senha para efetuar login, o serviço gera um hash dele 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 para o 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 ser comparados ao banco de dados. Por exemplo, um invasor saberia o hash da "senha1" e, em seguida, veria se alguma conta do banco de dados está usando esse hash. Se eles forem, o atacante sabe que sua senha é "password1".

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 hashing dela. Em outras palavras, um usuário digitaria a senha “password” e o serviço adicionaria o salt e hash uma senha que se parece mais com “password35s2dg”. Cada conta de usuário deve ter seu próprio sal exclusivo, e isso garantiria que cada conta de usuário teria um valor de hash diferente para sua senha no banco de dados. Mesmo que várias contas usassem a senha “password1”, elas teriam hashes diferentes por causa dos diferentes valores de sal. Isso frustraria um invasor que tentou pré-computar hashes para senhas. Em vez de gerar hashes que se aplicavam a todas as contas de usuário em todo o banco de dados de uma só vez, eles precisavam gerar hashes exclusivos para cada conta de usuário e seu exclusivo sal. Isso levaria muito mais tempo de computação e memória.

É por isso que os serviços costumam dizer não se preocupar. Um serviço usando procedimentos de segurança adequados deve dizer que eles estavam usando hashes de senha salgada. Se eles estão simplesmente dizendo que as senhas são "hash", isso é mais preocupante. O LinkedIn quebrou suas senhas, por exemplo, mas não as descartou - 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 incorreta

Esta 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 o hash, alguns dos piores transgressores podem simplesmente despejar as senhas em formato de texto simples em um banco de dados. Se tal banco de dados estiver comprometido, suas senhas estarão obviamente comprometidas. Não importaria o quão forte eles fossem.
• Hashing as senhas sem salga-los: Alguns serviços podem hash as senhas e desistir de lá, 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 elas existem no banco de dados - elas podem fazer isso para todas as contas de uma só vez, se nenhum sal tiver sido usado.
• Reutilizando saisAlguns serviços podem usar sal, mas podem reutilizar o mesmo sal para cada senha de conta de usuário. Isso é inútil - se o mesmo sal 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 consulta que incorporassem todos os sais possíveis. Por exemplo, se um único dígito fosse usado como um sal, o atacante poderia facilmente gerar listas de hashes que incorporassem todos os sal possíveis..

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

Outras preocupações

É provável que o valor de sal 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 enormes quantidades de energia da CPU quebrando todas essas senhas..

Na prática, muitas pessoas usam senhas óbvias que provavelmente seriam fáceis de determinar as senhas de muitas contas de usuários. Por exemplo, se um invasor souber seu hash e ele souber o seu valor, ele poderá verificar com facilidade se você está usando algumas das senhas mais comuns..

Se um invasor descobrir isso e quiser quebrar sua senha, ele poderá fazê-lo com força bruta, desde que saiba o valor do sal - o que provavelmente faz. Com acesso local e offline a bancos de dados de senhas, os invasores podem empregar todos os ataques de força bruta que quiserem..

Outros dados pessoais também vazam quando um banco de dados de senhas é roubado: nomes de usuário, endereços de e-mail e muito mais. No caso do vazamento do Yahoo, também foram vazadas perguntas e respostas de segurança - que, como todos sabemos, tornam 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 for roubado, é melhor assumir 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 gere senhas exclusivas para cada site. Se um invasor descobrir que sua senha para um serviço é “43 ^ tSd% 7uho2 # 3” e você só usa essa senha nesse site específico, eles não aprenderam nada útil. Se você usar a mesma senha em todos os lugares, eles poderão acessar suas outras contas. É assim que as contas de muitas pessoas são "hackeadas".

Se um serviço ficar comprometido, lembre-se de alterar a senha que você usa lá. Você também deve alterar a senha em outros sites, se você reutilizá-lo lá - mas você não deveria estar fazendo isso em primeiro lugar.

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

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

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