Savannah.gnu.org comprometido e fora do ar
Savannah é o repositório central de desenvolvimento do projeto GNU e de outros softwares livres hospedados pela FSF, funcionando nos moldes do Sourceforge.
No momento em que escrevo a sua página inicial informa que o serviço está fora do ar devido a um comprometimento de segurança que levou à obtenção de senhas, após quebrar os hashes das mesmas que foram vazados por um SQL Injection.
O serviço vai retornar ao ar via backup do dia 23/11 (mudanças em projetos enviadas a partir do dia 24 terão que ser reenviadas), após ser consertada a falha que permitiu o ataque e serem implementadas medidas adicionais, como a adoção de hashes mais robustos (crypt-md5) e obrigatoriedade de senhas fortes.
A disponibilidade de backup do dia 23 (semana passada) é um grande avanço em relação à indisponibilidade anterior do Savannah, em que foi divulgado que o backup completo mais recente era de 2 meses antes. (via lwn.net).
@brlinuxblog
Feed RSS
Eu não sou expert em criptografia e nem segurança é minha área, mas vi recentemente um post onde se recomenda a utilização de chaves SHA256 no mínimo e recomenda-se não usar SHA1 e abandoná-lo o quanto antes. Daí as dúvidas: MD5 não é inferior ao SHA1? Não era melhor ter partido logo para sha512 ou algo assim?
Vamos ver se assim aprende a usar ZFS…
tenho usado nos servidores, snapshot diario, send semanal.. um compromentimento de alguma coisa, pode ser recuperado em segundos do dia anterior, de 1 a 5 dias anteriores, e depois de semana em semana (até 4 semanas)..
@sergio
Herege, como ousa oferecer solução proprietária?
Para o GNU usar algo, este deve ser totalmente livre e não feito por empresas.
Estou sendo irônico.
Para chaves o MD5 não presta, é muito fácil criar duas strings com o mesmo hash MD5 (ataque de colisão). Para senhas ele é suficiente, pois senhas não são vulneráveis a ataques de colisão. O SHA-1 também é vulnerável (mas muito menos do que o MD5) a ataques de colisão e portanto não deveria ser usado para assinaturas digitais (mas continua sendo usado…). Para estes casos só deveriam ser usados algoritmos mais robustos como o SHA-2, o Whirlpool ou o Tiger.
Senhas são mais vulneráveis a ataques de contra-imagem (também conhecido como pré-imagem, ou imagem inversa), e não é conhecido nenhum ataque de contra-imagem viável (isto é, que seja possível calcular antes de você virar bisavô) para o qual o MD5 seja vulnerável.
Mesmo assim eu não usaria MD5 a não ser que eu fosse obrigado por limites de processamento ou memória.
Senha : 1234
Loucura mesmo usar software proprietário quando há soluções que são Software Livre e atendem muito bem:
-LVM2 ou BTRFS ou combinação de ambos
-Backup mais freqüente com Bacula também.
Mas tudo depende de organização e recursos. Software é detalhe, mas um detalhe que só deve ser proprietário em último caso.
@Jack Ripoff
O MD5 foi comprometido por esgotamento. Existem bases de dados mapeando quase todos os hashs possíveis com suas respectivas senhas geradoras.
Ele é fraco para hashs de senhas hoje.
O SHA1 está fraco para isso também.
Basicamente, o MD5 não deveria nunca mais ser usado para hashs.
BTRFS? Só um louco para usar um código experimental num servidor…
Enquanto o BTRFS não fica pronto, snapshots acho que só com o Solaris/FreeBSD com ZFS, não?
Qual é a minha senha?
MD5 (“xxxxxxxxxxxxxxxxxxxxx”) = d0eb57b67f447976bed72ec9c77e4ccc
Existem bancos mapeando quase todos os 340282366920938463463374607431768211456 hashes possíveis? Impressionante a determinação e a paciência dessa gente…
Alguém sabe se eles estavam usando um salt pelo menos?
Exemplo de um banco de dados com busca para uma lista de hashs MD5 e SHA1 mapeados:
http://md5.rednoize.com/
eu ja usei o http://md5.rednoize.com/ uma vez, mas vale lembrar que ele nem de longe tem uma base significativa, ele somente possui o de “falavras comuns”, ele não possui hash de palavras com números e letras aleatórios (eu testei com 9, 8, 7, 6, 5, 4, 3 e 2 dígitos, somente foram encontradas as palavras com 2 digitos)
BACULA rules!!!!
@Marcelo Atie
Esse search foi um exemplo aberto.
Mas para quebrar um MD5 com 6 caracteres entre números e letras (sem acentos, pontuações etc), um Parallel Python rodando um quebrador paralelo de MD5 em um cluster nosso aqui com só 100 núcleos demorou 4 minutos.
Muito fácil, ou seja.
Para 8 caracteres demorou 3 horas.
Muito fácil para uma senha com 8 caracteres e com um universo de escolha de mais de 35 caracteres para cada posição.
O MD5 está morto, completamente.
“Para senhas ele é suficiente, pois senhas não são vulneráveis a ataques de colisão.”
Me tirem uma dúvida. O fato do MD5 ter colisão não seria justamente o contrário? Senhas são dados pequenos, mais fácil enontrar enquanto assinatura de arquivos e imagens são arquivos maiores, a chave fica maior e mais difícil fazer colisão?
@marcosalex
O MD5 possui dois grandes problemas:
- Colisões fáceis
- Esgotamento
Isso o torna inseguro tanto para hashs de arquivos quanto para hashs de senhas.
Os hashs do MD5 possuem o mesmo tamanho em bits independentemente do tamanho do arquivo ou string que o gerou.
O fato desse tamanho em bits ser pequeno no MD5 é que possibilitou que as colisões e esgotamento ocorressem.
E hashs de senha podem apresentar colisões sim. Ás vezes senhas de 4 dígitos geram hashs MD5 que colidem com hashs de senhas de 8 dígitos. É perfeitamente possível.
Tenho projeto hospedado lá mais vou dizer uma coisa.
Pense numa política de backup……
Ter colisões qualquer função de hash tem. Isso é devido ao princípio da casa do pombo. Um ataque de colisão é outra coisa. A ideia é achar duas entradas que geram o mesmo hash, e para isso eu preciso ter controle sobre ambas as entradas – coisa que não acontece com uma senha.
Com uma senha, o que eu tenho é o hash dela e quero descobrir uma entrada que seja transformada pela função de hash nesse mesmo hash particular. Em outras palavras, eu quero achar a contra-imagem (mais preciso seria dizer “um elemento do conjunto contra-imagem”) desse hash. Isso é um ataque de contra-imagem. Uma forma “esperta” de descobrir a contra-imagem de um hash é buscar numa tabela. Para se proteger disto, basta usar um salt suficientemente grande na sua função (de 128-bits pra cima).
O fato de o MD5 ser vulnerável a ataques de colisão não tem tanto a ver com ele ser um hash só de 128-bits (isto tem mais a ver com ataques que tiram proveito do paradoxo do aniversário), mas com a função de compactação dele. O princípio da função de hash MD5 (e de muitas outras) é iterar uma função de compactação ao longo da sua entrada. A função de compactação do MD5 em particular é especialmente vulnerável a colisões.