“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 online, incluindo ontem, do Yahoo. Mas devemos realmente assumir essas garantias pelo valor de face?

A realidade é que o banco de dados de senhas compromete são uma preocupação, não importa o quanto uma empresa possa tentar manipulá-la. Mas há algumas coisas que você pode fazer para se isolar, não importa 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 fornecer 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 determinar sua senha real, um invasor com acesso ao banco de dados teria que pré-computar os hashes para senhas comuns e verificar se eles existem no banco de dados. . Os atacantes fazem isso com tabelas de pesquisa - listas enormes de hashes que correspondem a senhas. Os hashes podem ser comparados ao banco de dados. Por exemplo, um invasor saberia o hash de "senha1" e, em seguida, veria se alguma conta no banco de dados está usando esse hash. Se estiverem, o invasor 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, 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 salgada. Se eles estão simplesmente dizendo que as senhas são "hash", isso é mais preocupante. O LinkedIn trilhou 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 incorretas de senha

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 puro : ao invés de se preocupar com hashing, alguns dos piores transgressores podem simplesmente despejar as senhas em forma de texto base 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 hastear 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 hashes para muitas senhas e verificar se elas existem no banco de dados - elas poderiam fazer isso para todas as contas de uma vez, se não houvesse sal.
• Reutilizando sais : Alguns serviços podem usar sal, mas eles podem reutilizar o mesmo sal para cada senha da 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 salt, o invasor poderia facilmente gerar listas de hashes que incorporassem todos os sal possíveis.

As empresas nem sempre contam a história toda, por isso, mesmo que digam que uma senha foi criptografada (ou com hash e salgados), eles podem não estar usando as melhores práticas. Sempre erre do lado da precaução

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 CPU quebrando todas essas senhas.

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

RELACIONADO: Como os invasores realmente “cortam contas” on-line e Como Proteger-se

Se um invasor o disser 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 email 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 cada serviço é completamente incompetente e agir de acordo.

Primeiro, não reutilize as 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á-la lá - mas você não deveria estar fazendo isso em primeiro lugar.

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

O mais importante é não reutilizar senhas. Bancos de dados de senha comprometidos não podem te machucar se você usar uma senha exclusiva em todos os lugares - a menos que eles armazenem algo mais 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

Como monitorar os recursos de sistema do seu Chromebook com o Cog

Embora os Chromebooks sejam geralmente considerados máquinas de "uso casual", eles continuam a ficar mais poderosos e versáteis. E, à medida que continuam a fazer mais, a tensão na máquina torna-se naturalmente maior. Se você está procurando uma maneira excelente de acompanhar de forma rápida e fácil o que seu Chromebook está fazendo, não procure mais.

(how-top)

As chaves de perfil baixo vêm encolhendo seus teclados mecânicos

Os teclados mecânicos são perfeitos! Mas ninguém diria que eles são elegantes ou compactos. Mesmo os menores modelos tradicionais, os “60%”, são do tamanho e peso de um livro de bolso. Mas isso pode estar mudando muito em breve. RELATED: Como Escolher (e Personalizar) o Melhor Teclado Mecânico Para Você Cherry, a empresa alemã famosa por criar o design original do MX Switch que deu início à mecânica moderna revival, revelou um novo switch de baixo perfil na CES 2018.

(how-top)