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 da gravidade das 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 em disco.
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, 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 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 estão simplesmente dizendo que as senhas são "hash", isso é mais preocupante. O LinkedIn hashed suas senhas, por exemplo, mas elas não foram salvas - por isso, foi um grande negócio quando o LinkedIn perdeu 6,5 milhões de senhas com hash em 2012.
Práticas de senha incorreta
- Armazenando senhas em texto simples: Em vez de se preocupar com o hash, alguns dos piores criminosos podem simplesmente despejar as senhas em formato de texto simples em um banco de dados. Se tal banco de dados estiver comprometido, suas senhas estã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 senhas 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 for usado.
- Reutilizando saisAlguns serviços podem usar salt, 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 sais possíveis.
As empresas nem sempre informam toda a história, por isso, mesmo que digam que uma senha foi hash (ou hash e salgada), talvez não estejam usando as práticas recomendadas. 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 do seu status, ele poderá verificar com facilidade se você está usando algumas das senhas mais comuns.
Se um invasor fizer isso por você e quiser decifrar sua senha, ele poderá fazê-lo com força bruta, desde que saiba o valor do sal - o que provavelmente acontece.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 - 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 for roubado, é melhor assumir que cada serviço é completamente incompetente e age 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ê usar essa senha apenas nesse site específico, eles não aprenderam nada de ú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".
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. 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 o número do seu cartão de crédito.
