| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Um artigo interessante. :) Já tinha utilizado uma abordagem parecida para o algoritmo de hashing utilizado por omissão no mysql. O hash calculado era um valor de 64 bits em hexa ou mais exactamente a concatenação de dois valores de 32 bits depois passados para hexa. O algoritmo é bastante simples pelo que é baseado em valores intermediários (para não dizer quase finais o que levava a um maior reaproveitamento) do hashing da string com menos um caracter. Por exemplo, o hash da string "AAA" utiliza os valor intermediários do calculo do hash "AA". Quer dizer que posso utilizar esses mesmos valores para "AAB", "AAB", etc. O núcleo central do algoritmo ficava reduzido a 5 linhas de assembler. Foi nessa altura que me lembrei que talvez fosse viável guardar esses valores para reutilização para os casos mais complicados. Na altura, fiz uns cálculos e cheguei a conclusão que não tinha hardware para a minha empreitada: era preciso muita memória RAM para garantir que o processo fosse rápido. Se máquina começa-se a fazer swap o processo ficaria muitíssimo lento. Acabei por desistir por falta de tempo mas acho giro comprovar que afinal não estava a fazer nada de novo e que a ideia não era tão disparatada como isso. Afinal já outras pessoas tinham utilizado o mesmo estratagema numa outra situação. Fiquem bem! :)
JP
|
| | | | | Na sequência do artigo de ontem em que alguém se queixava que só se dizia mal do windows aqui vai mais uma... Está aqui um artigo que explica porque é que isto acontece. Basicamente o windows guarda as passwords sem adicionar algo de random. No linux, para além da password há 12 bits (algo a que eles chamam de salt) que são random. Isto resulta num tempo maior para descobrir a password. Segundo ele, demora 4096 vezes mais tempo ou requer 4096 vezes mais memória para a mesma performance. Outra vantagem do linux é que como os ditos 12 bits são random, se tiver duas vezes a mesma password em duas contas a pesquisa tem de recomeçar do zero. No Windows, como a password não tem o dito salt, a password é guardada de uma forma sempre igual. Por isso, se tiver a mesma password em duas contas é só comparar a encriptação de uma com outra e vê-se que é a mesma password. O método, no entanto, só é realmente eficiente se a password for alfa-numérica. Se esta tiver outros caracteres, aumenta a complexidade e a necessidade de tempo/memória aumenta também, para descobrir a password. Protejamo-nos...
|
| | | | Esse problema só existe se as senha forem criptografas usando o algorítmo do Lan Manager(quem se lembra!), caso este esteja habilitado. E se o indivíduo obtiver acesso de administrador ao servidor.
Foi intruduzido um novo algorítmo de criptografia de senhas no SP3 do NT4 (faz tempo!), o NTLM2, que acaba com essa brincadeira.
O problema é que a configuração default até o windows 2000 era de utilizar também senhas em LM para compatibilidade com sistemas legados. Mas a Microsoft tem guias e recomendações claríssimas, que dizem para manter habilitado somente em caso de necessidade. Então, é mais um problema de falta de conhecimento e leitura da documentação básica por parte dos administradores do que de implemetação.
|
| | | | | | | Esta "descoberta" é tão actual como vir dizer que no Linux se consegue sacar o crypt das passwords dos users do /etc/passwd... Já agora fica o artigo com informações sobre o store da password em Windows.
|
| | | | | Boas. Esse problema só existe se as senha forem criptografas usando o algorítmo do Lan Manager(quem se lembra!), caso este esteja habilitado. E se o indivíduo obtiver acesso de administrador ao servidor. Foi intruduzido um novo algorítmo de criptografia de senhas no SP3 do NT4 (faz tempo!), o NTLM2, que acaba com essa brincadeira. Eu acho que o que está em causa é o facto de que não é utilizado um valor aleatório em cada cifragem (salt) o que faz com que o hash da password "AAAAA" será sempre a mesma em qualquer máquina e que se encontrarmos a password de uma conta por comparação de hash sabemos logo se existe outra conta com a mesma password. No caso do LM, a utilização de valore precalculados fica facilitado pelo facto de naõ ser case-sensitive. O NTLMV2 trás novidades principalmente no mecanismo de autenticação entre o cliente e o servidor (mensagens trocadas e como são trocadas,etc). Mas quanto ao hashing de password a versão NTLM já usava o mesmo hashing desde dos primórdios do NT4. O LM é herança dos Win9x. O hash calculado na autenticação NTLM continua a não utilizar salt e continua a utilizar MD4 (DES) como o seu antecessor. A dificauldade relativamente ao LM é que não sendo case sensitive seria preciso muito mais memória para utilizar os hash precalculados. A utilização do salt não é nova e é conhecida como uma maneira fácil de aumentar o grau de dificuldade no bruteforce de password de um modo geral. Fica bem!
JP PS: Aqui fica um link para mais info.
http://davenport.sourceforge.net/ntlm.html
|
| | | | O hash é diferente para LM e NTLM. Aqui segue o o link com maiores explicações e como desabilitar hashes LM, invalidando esta técnica.
|
| | | | | Boas. Se calhar não me expliquei devidamente: o hash do LM é diferenete do hash do NTLM mas este último é igual ao hash do NTLMv2. Eu queria era dizer que o NTLMv2 não trás nada de novo (o mesmo que o seu antecessor o NTLM) em termos de hash mas traz ao nível do protocolo de autenticação. Fica bem! :)
JP
|
| | | | | O texto que segue abaixo é da autoria do Shadow (que não sabe onde meteu a password do gil) e não meu: Os comentários a este artigo são fenomenais --- vê-se mesmo que ninguém percebeu a porcaria do paper. :) Segue uma tentativa de explicação: O paper original de 1980 descreve uma técnica usando aquilo a que chamaram "chains" para reduzir a informação que é necessário guardar para recuperar rapidamente uma password. Simplificando, suponham que têm uma função de hashing H. Começam por gerar uma password T0, calculam C0 = H(T0). Depois aplicam uma função de redução R em C0 que basicamente converte o hash noutra password: T1 = R(C0). Posto isto calculam C1 = H(T1), T2 = R(C1), C3 = H(T2), ... , Cm = H(Tm-1) e guardam T0 e Cm. Com muitos pares (T0, Cm) constrói-se uma tabela. Depois de ter esta tabela, sabendo um C qualquer pode-se achar o T que o gera de uma maneira mais rápida: começa por se procurar pelo C no conjunto dos valores Cm pré-calculados. Enquanto não for encontrado, calcula-se T = R(C), C = H(T) e repete-se a procura. Uma vez encontrado o Cm, pega-se no T0 correspondente, calcula-se C0 = H(T0) e compara-se com o C original. Se for idêntico, o T0 é a password. Caso contrário, calcula-se T1 = R(C0), C1 = H(T1) e volta-se a comparar, até encontrar o C e o correspondente T. Este método tem um problema --- a função de redução. Esta pode levar a que chains diferentes levem a um determinado valor de T idêntico em alguma parte da chain (colisão), e a partir daí "desemboquem" em sequências idênticas (merge). Ou seja, diferentes T0 podem levar ao mesmo Cm, o que reduz o número de chaves distintas que estão presentes na tabela, e portanto aumenta o espaço necessário para cobrir todo o keyspace. O paper publicado explora uma função de redução alternativa que reduz bastante a probabilidade de haver um merge nas chains, variando a função de redução consoante a posição na chain. Assim, duas chains podem colidir sem merge, o que reduz o espaço necessário para gerar uma tabela que abarque todo o keyspace. Para os que estão entretidos a falar do sal, lembrem-se que podem considerar o sal como fazendo parte da password --- aumenta o espaço de procura, mas não impede que se use um algoritmo deste género. Parece-me que basta alterar o hash (para lhe meter o sal no sítio certo na saída) e a função de redução (para gerar o sal e a password a partir do hash anterior). E pronto, não tem mais nada que saber, parece-me a mim. Ou será que também me enganei e não percebi o paper ? :)
|
| | | | | | | Eu já li isso há uns dias, posso estar já a fazer confusão ou a esquecer-me de alguma coisa, mas aqui vai a ideia com que fiquei. Está dito algures, que o facto de o sal lá estar (no linux) com 12 bits aumenta o tempo de pesquisa em 4096 vezes, ou necessita de uma tabela 4096 vezes maior, para manter o tempo. Só isto por si, transforma os ditos 9 segundos (eram 9 segundos?) em mais de 10 horas (caso mantenhas a tabela). O que dificulta um pouco o processo... O sal, é diferente de máquina para máquina. Por isso, se alguém simplesmente tentar procurar passwords em duas máquinas, ainda que seja a mesma password, como o sal é diferente, vai ter de se recomeçar do zero, em vez de simplesmente comparar uma password encriptada com a outra e ver que são iguais. Isto, vai aumentar também o tempo de procura... Para os que estão entretidos a falar do sal, lembrem-se que podem considerar o sal como fazendo parte da password. Acho que ninguém disse o contrário. O que se discutiu mais foi o facto de windows usar ou não o sal. É inclusivamente dito (como já referi) que o tempo no linux será aumentado em 4096 vezes, ou a memória necessária em 4096 vezes [ou uma combinação menor de ambos]. Acho que isso prova que é possivel fazê-lo... Quanto ao resto, aparte da explicação mais técnica, eu (acho que) tinha entendido que essa seria a base do sistema. Será que não tinha e disse assim tanta asneira?
|
| | | | Está dito algures, que o facto de o sal lá estar (no linux) com 12 bits aumenta o tempo de pesquisa em 4096 vezes, ou necessita de uma tabela 4096 vezes maior, para manter o tempo. Só isto por si, transforma os ditos 9 segundos (eram 9 segundos?) em mais de 10 horas (caso mantenhas a tabela). O que dificulta um pouco o processo... Duvido que tenhas lido isso algures, porque é falso. O sal nunca aumenta o tempo de procura num bruteforce pelo simples facto de que sabes qual é --- o sal é guardado juntamente com o hash. O que aumenta sim seria o tempo e o espaço necessários para calcular e guardar um dicionário de hashes de passwords comuns, por exemplo --- para cada password tens de calcular e guardar 4096 hashes em vez de um para teres em conta o sal. No entanto, isso não tem tanta influência no algoritmo descrito no paper, visto que a ordem de complexidade é diferente (obviamente) de um bruteforce. O sal, é diferente de máquina para máquina. Nope! O sal é diferente de password para password. O que se discutiu mais foi o facto de windows usar ou não o sal. É inclusivamente dito (como já referi) que o tempo no linux será aumentado em 4096 vezes, ou a memória necessária em 4096 vezes [ou uma combinação menor de ambos]. Acho que isso prova que é possivel fazê-lo... Antes de mais, deixa-me dizer que não entendo a insistência no Windows vs. Linux aqui. :) O sal aumenta o tempo e espaço necessário para pré-calcular um dicionário de passwords. O algoritmo reduz o tempo e espaço necessário para pré-calcular um "dicionário" de passwords (ou pelo menos informação suficiente para recuperar rapidamente uma password a partir do hash). A relação entre o número de passwords e o espaço / tempo necessário não é assim tão simples. Um aumento de 4096 vezes no keyspace não leva a um aumento de 4096 vezes no espaço ou no tempo necessário para correr o algoritmo. Se tens dúvidas podes fazer as contas para o espaço que necessitavas para armazenar informação sobre passwords alfanuméricas de 6 letras por exemplo --- mais de 35GB, e isto se armazenares apenas um byte por cada password possível, o que é perfeitamente ridículo --- para entenderes que a relação não pode ser como pensas. Dito de outra maneira, o cracker permite crackar passwords de 78 caracteres em 30 segundos. Reduz o tamanho da password para 76 caracteres e adiciona dois de sal --- o espaço / tempo necessário é o mesmo. E duvido muito que encontres passwords de 76 caracteres todos os dias. :)
|
| | | | | O sal nunca aumenta o tempo de procura num bruteforce pelo simples facto de que sabes qual é --- o sal é guardado juntamente com o hash.
O que aumenta sim seria o tempo e o espaço necessários para calcular e guardar um dicionário de hashes de passwords comuns Então, mas a ideia não é mesmo essa? Tipo, tu tens uma password com 10 caracteres, aos quais o sistema junta (suponhamos, não estou a dizer que isto acontece) mais 10 caracteres aleatórios e depois encriptares, para desencriptar não tens de procurar a tua password. Tens um conjunto de 20 caracteres, dos quais 10 são aleatórios. Independentemende do que demora ser a criação da tabela ou mesmo a pesquisa, se tu precisas de 4096 hashes em comparação com 1, acho que é óbvio qual o sistema mais simples de crackar. Nope! O sal é diferente de password para password. É independente para aquilo a que eu me estava a referir. Eu estava a falar no caso de usares a mesma password em dois computadores. Aí o facto de mudar de um computador para outro é suficiente, mas sim, caso tenhas dois users na mesma máquina com a mesma password, ela vai ser diferente por causa do sal. Dito de outra maneira, o cracker permite crackar passwords de 78 caracteres em 30 segundos. Bem, tendo em conta as estatísticas do site deles, a média é de 92.9 segundos. Acho que não tem lógica pensar em crackar password e tomar só como conta os casos bem sucedidos em que o sistema é rápido. Diz no site "Total number of requests : 4871 with an average of 92.9 s/request". É portanto de esperar 93 segundos por password, já que há também as passwords que o sistema não descodifica e essas vão demorar mais do que os 10 segundos dos casos de sucesso. Reduz o tamanho da password para 76 caracteres e adiciona dois de sal --- o espaço / tempo necessário é o mesmo. Epá, acho que a lógica não é bem essa, sinceramente... Se a minha password tiver 12 caracteres não é porque era para ter 14 mas como há 2 de hash, não preciso de tanto... Escolho uma password e o hash vem depois. Por isso, se tens uma password de 78 caracteres, com o hash não lhe vais tirar 2 caracteres para ficar com 78 à mesma. Vai é ficar com 80. Ou não?
|
| |
|
