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

"Nossa base de dados de senhas foi roubada ontem. Mas não se preocupe: suas senhas foram criptografadas. "Nós regularmente vemos declarações como esta on-line, inclusive ontem, do Yahoo. Mas devemos realmente levar essas garantias ao valor nominal?

A realidade é que a base de dados de senha compromete o e uma preocupação, não importa como uma empresa possa tentar girá-la. Mas há algumas coisas que você pode fazer para isolar-se, não importa o quão ruim são 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 própria senha, o serviço gera um "hash" 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 fazer login, o serviço gera um hash e verifica se o valor hash corresponde ao valor armazenado no banco de dados. Em nenhum momento o serviço nunca salvou sua senha no disco.

Para determinar sua senha real, um invasor com acesso ao banco de dados teria que pré-calcular os hashes para senhas comuns e verificar se eles existem no banco de dados. Os atacantes fazem isso com tabelas de pesquisa - grandes listas de hashes que combinam senhas. Os hashes podem então ser comparados ao banco de dados. Por exemplo, um invasor saberia o hash para "senha1" e depois verificaria se alguma conta no banco de dados está usando esse hash. Se o forem, o atacante sabe que sua senha é "senha1".

Para evitar isso, os serviços devem "salar" seus hashes. Em vez de criar um hash a partir da senha propriamente dita, eles adicionam uma seqüência de caracteres aleatória para a frente ou o final da senha antes de arrastá-la. Em outras palavras, um usuário entraria a senha "senha" e o serviço adicionaria o sal e o hash uma senha que se parece mais com "password35s2dg". Cada conta de usuário deve ter seu próprio sal exclusivo e isso garantirá que cada conta de usuárioteria um valor de hash diferente para sua senha no banco de dados. Mesmo que várias contas usassem a senha "senha1", elas teriam diferentes hashes devido aos diferentes valores de sal. Isso venceria um atacante que tentasse pré-computar hashes para senhas. Em vez de poder gerar hashes que se aplicam a cada conta de usuário em todo o banco de dados ao mesmo tempo, eles teriam que gerar hashes únicos 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 geralmente dizem não se preocupar. Um serviço que usa procedimentos de segurança adequados deve dizer que eles estavam usando hashes de senha salgados. Se eles simplesmente estão dizendo que as senhas são "hash", isso é mais preocupante. O LinkedIn abotoou suas senhas, por exemplo, mas elas não as saltaram - por isso, foi um grande problema quando o LinkedIn perdeu 6.5 milhões de falhas de falhas em 2012.

Práticas de senha incorretas

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

• Armazenando senhas em texto simples : Em vez de incomodar com hashing, alguns dos piores infratores podem simplesmente despejar as senhas em forma de texto simples em um banco de dados. Se tal banco de dados estiver comprometido, suas senhas são obviamente comprometidas. Não importava o quanto eles eram fortes.
• Hashing as senhas sem salgá-las : alguns serviços podem ter as senhas e desistir, optando por não usar sais. Essas bases de dados de senhas seriam muito vulneráveis ​​a tabelas de pesquisa. Um invasor pode gerar os hashes para muitas senhas e verificar se eles existiram no banco de dados - eles poderiam fazer isso para cada conta de uma só vez, se nenhum sal fosse usado.
• Reusing Salts : Alguns serviços podem usar um sal, mas eles podem reutilizar o mesmo sal para cada senha de conta de usuário. Isso é inútil - se o mesmo sal fosse usado para cada usuário, dois usuários com a mesma senha teriam o mesmo hash.
• Usando Sólidos Curtos : Se forem usados ​​sais de apenas alguns dígitos, seria possível gerar tabelas de pesquisa que incorporassem todos os sais possíveis. Por exemplo, se um único dígito fosse usado como sal, o atacante poderia facilmente gerar listas de hashes que incorporavam todos os sais possíveis.

As empresas nem sempre dirá toda a história, portanto, mesmo que eles digam que uma senha foi esmagada( ou esmagada e salgada), eles podem não estar usando as melhores práticas. Sempre erre no lado de cautela.

Outras preocupações

É provável que o valor do 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 atacantes teriam que gastar enormes quantidades de energia da CPU que quebrassem todas essas senhas.

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

Se um atacante tiver isso para você e quiser quebrar sua senha, eles podem fazê-lo com força bruta, desde que conheçam o valor do sal - o que eles provavelmente fazem. Com acesso local e offline às bases de dados de senhas, os invasores podem empregar todos os ataques de força bruta que eles desejam.

Outros dados pessoais também podem escorrer quando um banco de dados de senha é roubado: nomes de usuários, endereços de e-mail e muito mais. No caso do vazamento do Yahoo, as perguntas e respostas de segurança também foram vazadas - o que, como todos sabemos, facilita o acesso à conta de alguém. Ajuda do

, o que devo fazer?

O que um serviço diz quando o banco de dados de senha é roubado, é melhor assumir que todos os serviços são completamente incompetentes e atuam em conformidade.

Primeiro, não reutilize senhas em vários sites. Use um gerenciador de senhas que gere senhas únicas para cada site. Se um atacante consegue 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 podem acessar suas outras contas.É assim que as contas de muitas pessoas se tornam "pirateadas".

Se um serviço se tornar comprometido, certifique-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 fazer isso em primeiro lugar.

Você também deve considerar a utilização de autenticação de dois fatores, que irá protegê-lo, mesmo que um invasor aprenda sua senha.

O mais importante não é reutilizar senhas. Os 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 seu número de cartão de crédito.

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