Password recovery s vyuzitim GPU

Proč bych měl zjišťovat heslo do Windows několik dnů s využitím GPU, když jej můžu mít zjištěné za pár sekund s pomocí jiného softu...

pokial viem, tak soft, ktory by to zvladol za par sekund neexistuje

Ale existuje, osobne jsem jej zkousel. Dokonce je to OpenSource

trochu sa orientujem v password recovery nastrojoch a som si isty, ze ziadny z komercnych alebo free nastrojov nedokaze zistit 8 miestne alfanumericke heslo za par sekund ak ma k dispozicii len NTLM hash

JaFi má rád duhu...

ani s tabulkami, keby sa ti ich podarilo nejako ziskat by to nebolo take rychle
napr. tabulky 1-7 znakov mixalpha-numeric NTLM maju 30 GB

Takze jsem testoval.
6-místné (pouze čísla) - 3s
8-místné (velká, malá písmena, čísla) - 36s
Program má k dispozici hash tabulky, jejich nacitani po startu trvalo 146s. Takze to 8-mistne heslo bylo zjisteno asi za 180s od startu programu

Jinak ty tabulky maji stovky MB

Ja jsem cekal, ze se pujde touhle cestou, ale necekal jsem, ze to pujde takhle pomalu, hodne trvalo nez se tento nastroj obejevil. IMHO nemuzes strovant "rainbow table" s "brutal force", mozna je to rychlejsi na nejakem vzorku ale hash tabulky nejsou obecne. Z praktickeho hlediska souhlasim, nicmene tento GPU nastroj jde na to jinou metodou, ktere nevadi soleni pri hashovani apod ... imho nezatracovat 20x rychlejsi program existujici jinou metodou, ktera ma sve mouchy.

Hlavne by si lide meli uvedomit ze timto se stalo bezpecne heslo, takove ktere je o jeden znak dalsi nez "vcera" - 20x na GPU = rychlejši pri Trible Sli a "Quard" CrossFire (Crossfire na X2) tak 60x a to uz je skoro jeden ASCII znak (z tech co se normalne pouzivaj).

BTW: Matka mela jedoduche heslo _neco_ a rovnou jsem ji rekl, ze jeji jedoduche heslo je na prd a jedinej kdo se tam s tim heslem nemuze dostat je ona sama , (CapsLocky,FNka,Shifty..)

S tabulkami jsi schopny zjistit alphanumericke heslo do delky 14 znaku vecelku rychle, z bootovaciho CD trva kompletni projeti tabulek do 1h a to se da zvladnout i bez vykradeni SAM.
Takze pokud chces bezpecne heslo, mělo by "zatím" stačit pouzivat diaritiku, která se nevyskytuje v US ASCII a delka kolem 8 znaků.

Zdravim,

dost ma to prekvapilo - ze je aj tato oblast - tak lahko zranitelna aj pri dost dlhom hashovanom hesle.

t.j. mal by som jednu otazku: Je mozne, ze sa budem namahat zbytocne pri vytvarani dlheho hesla, pretoze nejaky desif. nastroj prideli k hash cielu ine zdroj. heslo a aj tak sa prihlasi (je to mozne)

napr. vymyslim si 30 znakove heslo, z ktoreho vznikne nehaky hash.
a desifr. nastroj z daneho hash vyrobi napr. 14 znakove hoslo, ktore bude mat rovnaky hash ?
(a ja zbytcne stracam cas s 30 znakovym heslom ?)

t.j. je mozne, ze existuje pre 2 alebo viac roznych zdroj. hesiel, prave jeden cielovy Hash, aj ked si to autori Hash. algoritmov nechcu pripustit?

Sorry za nie uplne odbornu terminologiu, ale snad som to napisal aspon trochu zrozumitelne.

ano, kolizie hashov su mozne
avsak to co popisujes zatial nikdo nedokazal, keby sa to niekomu podarilo, znamenalo by to velky prelom v problematike bezpecnosti

diky za odpoved,

bohuzial, este sa mame na co "tesit"

2) mozno existuju vhodne tipy, ake pisat hesla, aby to bolo co najprobl. desifrovatelne, aj napriek koliziam Hashov

3) nebolo by na case vymysliet-implementovat x-radovo lepsie hash-e (snad uz na nejakom byte nezalezi - nech uz nesetria byty ale nas)

dikes

2) mozno existuju vhodne tipy, ake pisat hesla, aby to bolo co najprobl. desifrovatelne, aj napriek koliziam Hashov

3) nebolo by na case vymysliet-implementovat x-radovo lepsie hash-e (snad uz na nejakom byte nezalezi - nech uz nesetria byty ale nas)

vsak su vymyslene aj implementovane

napr WinRAR od 2.9 ma AES (Rijndael) 128-bit, Brute Force uz na heslo 1-4 znakov, pri uvazovani vsetkych tlacitelnych znakov vychadza asi na 28 dni pri rychlosti 34 hesiel/s
t.j heslo nemusi byt extremne dlhe, staci ak obsahuje vhodne zvolene znaky

Tipy vyplivaji z toho co jsou ty kolize -
nema cenu psat delsi heslo nez je hashovani, pak to zarucene ma kolizi(kolize-bude jich hafo), ktera je kratsi nez original heslo. A pak musi byt heslo dostatecne dlouhe.

Dostatecne dlouhe hashovani se pouziva tam, kde je to nutne - banky:1024 či 2048. Algoritmy na to máme SHA-256 neni problem sehnat implemntaci v libovlném jazyce..a jine.. Ale zatim si lidi myslej,ze to tak nehori. To co psal JaFi je jen porovnani dvou hashu a pokud souhlasi, podivani se do sve tabulky, co je original (tabulky vznikly predpocitanim jednou). Tam se ceka, ze nebude nalezena kolize, ale originalni heslo.(i kdyz je mozne, ze to najde kolizni heslo). Nicmene i ty tabulky jsou NEUVERITELNE male, aby se dalo spohlehat na nalezeni kolize. (2na128- tedy "1000 TB" dat.JaFi ma jedno Cédéčko )

Ano

,to ze budes mit 30ti znakove heslo na 128bitovém hashovani je preurceno k tomu, aby byla nalezeno kolizni heslo kolem 16 max17 znaku. (nepravdepodobne, ale muze to teoreticky kolidovat s 2znakým heslem.

Autori algoritmu o tom vedi, jinak to ani nejde-hash musi mit rozumnou delku (8-128znaku) a musi umet kodovat i GBtové soubory.Tudis tam ty kolize jsou,vzdy byly a budou).Autori delaji jako ze tam nejsou, protoze nejsme schopni je nalézt. Nemam na to dostatecny vykon CPU a ted ani GPU.

Existuji dve ulohy:
a) Nalezeni dvou hesel/souboru/zdroju se stejným otiskem - slozitost 2na(N/2) tedy 2na64 u 128bit hashovani- Obcas jde ta funkce prolomit najit v ni system a slozitost klesne(pak je spatna a nemela by se dal pouzivat) jako to udela V.Klima s MD5.- Jde Treba vytvorit smlouvy jednu na 3000,druhou na 50000 se stejným otiskem. Problem je,ze smlouva musi byt na stejny hash "doplněna" -nejake znaky. Ale zarovan musi davat smysl...

b)ziskani z hashe heslo - slozitost 2naN-tedy 2na128 u 128bit hashovani. Toto zatim nejsme schopni realizovat a na tom vetsinou stoji. Obsac se najde nejakej hack funkce,kterej tvrdi,ze nasel system a ze umi najit heslo z hashe ve slozitosti 2na(N-neco). Ale zatim "neco" bylo male a pro prakticke duvody stale neuzitecne.(BTW: vypocet hesla z hashe najde NECO co odpovida hashy - tedy velmi nepravdepodobne, ze to bude original - tedy taky kolize)

-diky obidvom za odborne a napriek tomu zrozumitelne odpovede

-tiez mi je viacmenej jasne, ze ak je dlzka hash - kratka a konstantna, tak pre rozne dlhe zdroje musia existovat rovnake hash retazce, lebo keby nie, tak mame velmi efektny algoritmus kompresie - co je nezmysel.

-myslel som len, ze pomoze byt trochu velkorisejsi k poctu bitov Hash a pripadne kombinacie viacerych vhodnych Hash algoritmov (vsak uz mame X-jadierok )

tak nech sa tie jadierka nepouzivaju len na hackovanie, ale aj na lepsie zabezpecovanie.

inak poucne citanie.

Ja vetsinou pouzivam bezpecna hesla (ne vsude ) Takze me tyto nastroje netrapi. Ale jsem prekvapene, ze je to takto rychle. (Ovsem ve skole nam vtloukali do hlavy , ze do "budoucna" se zanedbavaj konstaty a kouka se jen na asymptickou slozitost a ta je stejna jako u brutal force).

vsetko zalezi na implementacii, v pripade, ze je pouzity LM hash, tak bezpecne heslo prakticky neexistuje

Prosim ta o pomoc napis mi na facebook jozef bikar je to dvolezite dakujem

mám dotaz...dá se takovýto program použít k prolomení hesla třeba na webu jako je rajce.net?