Por que você deve sempre se preocupar com vazamento de senhas?
"Nosso banco de dados de senhas foi roubado ontem. Mas não se preocupe: as senhas foram criptografadas "Nós vemos regularmente declarações como este em linha,. Incluindo ontem, do Yahoo . Mas devemos realmente levar essas garantias pelo seu valor nominal?
A realidade é que os compromissos do banco de dados de senha são uma preocupação, não importa o quanto uma empresa pode tentar girá-lo. Mas há algumas coisas que você pode fazer para se isolar, não importa quão ruim práticas de segurança de uma empresa são.
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 propriamente dita, 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 efetuar login, o serviço gera um hash a partir dele e verifica se o valor hash corresponde ao valor armazenado no banco de dados. Em nenhum ponto o serviço nunca salvar a sua própria senha para o disco.
Para determinar sua senha real, um atacante 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 atacantes fazem isso com tabelas de pesquisa - listas enormes de hashes que combinam senhas. Os hashes podem então ser comparados ao banco de dados. Por exemplo, um invasor deve saber o hash para "password1" e, em seguida, verifique se alguma conta no banco de dados está usando esse hash. Se eles são, o atacante sabe que sua senha é "password1".
Para evitar isso, os serviços devem "sal" seus hashes. Em vez de criar um hash a partir da senha em si, eles adicionam uma seqüência aleatória para a frente ou fim da senha antes hash it. Em outras palavras, um usuário digeria a senha "senha" eo serviço adicionaria o sal e hash uma senha que se parece mais com "password35s2dg." Cada conta de usuário deve ter seu próprio sal exclusivo, o que garante 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 devido aos diferentes valores de sal. Isso iria derrotar um invasor que tentou pré-computar hashes para senhas. Em vez de ser capaz de gerar hashes que se aplicavam a cada conta de usuário em todo o banco de dados ao mesmo tempo, eles teriam de 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 não se preocupar. Um serviço usando procedimentos de segurança adequados deve dizer que eles estavam usando hashes de senha salgados. Se eles simplesmente dizem que as senhas são "hash", isso é mais preocupante. LinkedIn hash suas senhas, por exemplo, mas não o fizeram sal-los-por isso foi um grande negócio quando 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 confundi-lo em uma variedade de maneiras:
- Armazenar senhas em texto simples: em vez de se preocupar com hashing, alguns dos piores criminosos pode simplesmente despejar as senhas em formato de texto simples em um banco de dados. Se esse banco de dados estiver comprometido, suas senhas serão obviamente comprometidas. Não importava o quanto fossem fortes.
- Hash as senhas Sem Salga Them: Alguns serviços podem botar as senhas e dar-se lá, optando por não usar sais. Esses bancos de dados de senhas seriam muito vulneráveis a tabelas de pesquisa. Um invasor poderia gerar os hashes para muitas senhas e, em seguida, verificar se existiam no banco de dados - eles poderiam fazer isso para cada conta de uma só vez, se nenhum sal foi usado.
- Sais reutilização: Alguns serviços podem usar um sal, mas eles podem reutilizar o mesmo sal para cada conta de usuário senha. 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 curto Sais: Se forem utilizados sais de apenas alguns dígitos, seria possível gerar tabelas de pesquisa que incorporaram cada sal possível. 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.
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 único valor de sal fosse usado para cada usuário, os atacantes teriam que gastar enormes quantidades de poder de CPU quebrando todas essas senhas.Na prática, muitas pessoas usam senhas óbvias que provavelmente seria fácil determinar senhas de muitos usuários de contas. Por exemplo, se um atacante sabe o seu hash e eles sabem o seu sal, eles podem facilmente verificar se você está usando algumas das senhas mais comuns.
Se um atacante tem para fora para você e quer quebrar a sua senha, eles podem fazê-lo com força bruta, desde que eles sabem o valor do sal, o que provavelmente fazem. Com acesso local, off-line para bancos de dados de senha, os atacantes podem empregar todos os bruta ataques de força que eles querem.
Outros dados pessoais também provavelmente vazamentos 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, torna mais fácil roubar o acesso à conta de alguém.
Ajuda, o que devo fazer?
Seja qual for um serviço que diz quando seu banco de dados de senhas é roubado, é melhor assumir que cada serviço é completamente incompetente e agir em conformidade.Primeiro, não reutilize senhas em vários sites. Use um gerenciador de senhas que gera senhas únicas para cada site . Se um invasor 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 poderiam acessar suas outras contas. Isto é como as contas de muitas pessoas tornam-se "hackeado".
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 deve fazer isso em primeiro lugar.
Você também deve considerar o uso da autenticação de dois fatores , que irá protegê-lo mesmo que um invasor descobre sua senha.
