Nostr Web Client

Estranho esse negócio de vazar usuário e senha.

Hoje as senhas não são salvas em formato de hash SHA 256 nos servidores para evitar que sejam expostas e nem a própria empresa sabe a senha porque o que o sistema faz é só comparar se hash obtido da senha fornecida está de acordo com o hash armazenado para conceder ou negar acesso?

Isso quer dizer que muitas empresas ainda armazenam as senhas em texto aberto ou criptografada e tem a chave roubada?

Existem empresas que, se você disse que esqueceu a senha, eles enviam a senha por email.

Jeferson Quadros 6mo ago

Olá, nostr:nprofile1qqsyewdfv34gkvrdmef7kv3pnh2an8d3uvqjx63ld9dr4qu9md8a97spzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7aua4m7;

* Senhas não são e nem devem ser armazenadas com SHA, pois elas não devem ser criptografadas, mas sim derivadas (o que é bem diferente). Pra isso, usa-se um algoritmo de derivação de senhas. O mais famoso e usado é o bcrypt. Ótimo, por sinal. Se algum sistema que tu usas, corra.

* Além da própria senha, a string de derivação contém o usuário, e também um termo chamado de salt.

* Bancos vazados são vazados em hashes e, sim, nesse momento, nem a empresa do sistema e nem os hackers sabem da sua senha.

* Ocorre é que há um esforço computacional assíncrono na comunidade cracker para criar o que chamam de rainbow tables. Esse esforço é bastante grande e consiste em derivar combinações de senhas com logins e salts sobre todo o banco vazado a fim de identificar conformidades.

* Eventualmente, após bastante GPU usada, são criadas essas rainbow tables e vendidas da deepweb.

* É bastante raro uma big tech ter seus bancos vazados e os hackers raramente tentam isso. A estratégia principal é atacar serviços menores e, eventualmente descoberta a senha, tentar o uso desse par de login e senha nos serviços grandes. Daí o mantra de nunca repetir senha e bom seria não repetir login também. Além disso, 2FA costuma ajudar horrores.

* Sou economista. Essa é minha formação acadêmica. Além disso, tenho décadas de experiência profissional com programação. Muito sistema de login já implementei e já ensinei tranquilamente bem mais de mil alunos a fazerem isso. Contudo, NÃO SOU UM PROFISSIONAL DE SEGURANÇA DA INFORMAÇÃO, então, abuse do seu direito de checar o que eu disse sobre o processo de hackeamento. Posso estar falando alguma bobagem ou estar desatualizado, mas é algo bem parecido com isso que fazem.

Reply to this note

Please Login to reply.

Discussion

ENSA obsoleta 6mo ago

Olá, irmão pianeiro.

Depois vou estudar mais sobre derivação de senha e bcrypt, ficou meio difícil de entender, não quer dizer que você é pouco didático, mas por causa da minha ignorância, você conseguiu despertar o que poucos professores conseguem, a curiosidade e interesse de saber mais e isso é o que importa.

Sobre o SHA 256, todas as instâncias do Cryptpad (suíte de escritório colaborativa online que se vende como super segura) deixam claro que eles usam SHA para não salvar a senha com eles. Num primeiro momento isso parece muito seguro, mas pegando a soma de checagem, eles podem tentar as senhas e gerar essas somas e comparar. Obviamente deve haver aplicativos que fazem isso de forma automatizada e rápida. Aí seria só vender tudo mastigado.

Jeferson Quadros 6mo ago

Que bom que eu despertei interesse. É um assunto bonito. Como falei, meu conhecimento vai até implementar um sistema e até mesmo ensinar alguém a fazer isso, contudo, o que sei sobre como esses mecanismos são contornados pelos criminosos não vai muito além do que é inevitável acabar aprendendo diante da proximidade entre as áreas.

Sobre o SHA, a falha em usá-lo reside principalmente no ponto em que ele é algoritmo focado em performance. Ele ser performático pode até parecer bom -- e é --, mas em se tratando se senhas, não. Isso por que, como havia comentado, existe um esforço coordenado na comunidade de criminosos de pré-computar hashes e simplesmente procurá-los nos bancos vazados, através das rainbow tables e esse esforço, não preciso dizer, será tão difícil quanto é custoso computacionalmente gerar uma hash.

Nesse ponto, gerar uma hash bcrypt é algumas centenas de milhares de vezes mais custoso do que fazer o mesmo com SHA, o que torna a capacidade dos hackers de criar essas tabelas muito menor em termos de velocidade.

Criptografias performáticas como o SHA são recomendadas para contextos onde a velocidade é importante, como em comunicações -- sobretudo instantâneas, -- hashs de integridade de dados, camada de encriptação se arquivos, etc. mas, em senhas, queremos o contario.

É muito estranho que esse sistema que mencionaste use SHA e ainda por cima coloca a bunda pra fora da janela contando isso pra todo mundo. IMHO, contar isso é pior do que fazer, é um problema ainda maior de segurança.

Um abraço.