Online hashcat dekódolás Hash és titkosítás? Mi a hash érték, mi a hash titkosítás, mi a hash dekódolás
Hash és titkosítás
Gyakori tévhit van, hogy a hash és a titkosítás ugyanaz. Ők nem. A hash visszafordíthatatlan. Vegyük példaként a következő példát:
$ echo-n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb -
A "Password123" karakterláncot átadjuk az MD5 algoritmusnak (algo), amely matematikai műveleteket hajt végre, és visszaadja a generált hexadecimális kódolt hash-t. Az egyetlen módja annak, hogy ugyanazt a hash kimeneti értéket kapja, ha eredetileg beviteli az algo-t. Vannak konfliktusok, de később megbeszélhetjük.
A legtöbb hash algoritmus kimenete hexadecimális kódolású fix hosszúságú bináris karakterlánc. Mások, például ez a példa, kimenetként base64 kódolt karakterláncot használnak. Vegye figyelembe, hogy a hossz mindig ugyanaz:
{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w =
{SHA} lqdu/Zr6o2dgIER8Up1/7lcUtgw =
{SHA} qYUOwLMlDEuukA5HCT4LR1kQzco =
{SHA} MXZBCpyWJ7TTs1w2kgGJslwNwTg =
{SHA} 2sAPLaUh9Mz0bI + XxKEg7qyABe8=
TL; Dr.
A titkosítás visszafordítható, a hash nem
Nem szeretnék túl sokat beszélni a titkosításról (mert azok a dolgok könyveknek szólnak), de fontos, hogy tudjunk különbséget tenni a hash és a titkosított karakterláncok között. A titkosítás általában kitölti a karakterláncot, hogy megfeleljen egy adott hosszúságnak, mielőtt a titkosítás megtörténne. A visszafejtéshez kulcs (vagy jelszó) is szükséges. Ha titkosított jelszót használ, a string a bemenet hosszától függően változik. Ha egy csomó titkosított jelszót lát, amelyek hosszúsága változó, előfordulhat, hogy titkosítással foglalkozik a hash helyett. AES-256-CBC Példa Titkosított karakterlánc és a kapcsolódó sima szöveg (kulcs "ASDF"):
foobar | U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = foobarfoobar | U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = foobarfoobarfoobar | U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + ldatuqv2xexeaeoww0xg/EXJUe9aSUz $ cat encrypted_passwords U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz $ for i in `cat encrypted_passwords`; do echo $i | openssl enc -base64 -d -aes-256-cbc -pass pass:asdf; visszhang; Kész foobar foobarfoobar foobarfoobarfoobar
Most azt gondolhatod: valószínűleg igazad van. Azonban az, hogy a kulcsfontosságú anyagnak elérhetőnek kell lennie a rendszer számára, azt jelenti, hogy lényegében egy sima szöveges mesterjelszó található valahol – akár RSA kulcsként, akár jelszóban vagy fájlban, adatbázisba ágyazva, keményen kódolva az alkalmazásban vagy valahol a memóriában. pfft, senki ' nem fogja használni az ASDF-et kulcsként felhasználói '
jelszavak titkosításához Ugyanaz a karakterlánc az MD5 használatával:
foobar | 3858f62230ac3c915f300c664312c63f foobarfoobar | 59faa421729e846dd800dce59943bfc0 foobarfoobarfoobar | 1352aadab322d1a033c27964be0965db
A hash jelszó korántsem tökéletes, sőt kicsit rossz, de rosszabb, mint a titkosítás, mert mit próbál elérni. A felhasználók gyakrabban választják ki az abszolút minimális követelményeket, mint a not, és több webhelyen is használhatják. Sok "hack" valójában nem más, mint hitelesítő újrafelhasználási támadás. Ha a kezdeti kompromisszum a titkosítás használata, akkor az egyetlen erőfeszítés, amit a támadónak meg kell tennie, az az, hogy megtalálja a kulcsot, amely megfejti az összes jelszót. A hash esetében legalább erőfeszítést kell tenniük, hogy feltörjék őket. Ha modern algoritmusokkal, például sha512crypt, bcrypt, scrypt vagy Argon2-vel használjuk, a hash értékek feltörése nagy erőfeszítést igényelhet.
pácolás
A sózás egy karakterlánc hozzáadása a jelszóhoz a hash előtt. Minden hash sójának egyedinek kell lennie, általában véletlenszerűen kiválasztva, mert a lényeg az, hogy ugyanannak a sima szövegű "jelszó" hash értékének minden alkalommal más értéke legyen. Ez megnehezíti a jelszótörők életét, hiszen ahhoz, hogy az 1000 felhasználó közül minden egyes felhasználónál ellenőrizzék a "jelszó" szót, minden felhasználónak van egy egyedi sója, ezerszer-felhasználónként/sónként egyszer-meg kell csinálniuk a munkát. Ez azt is jelenti, hogy nem tudják hatékonyan használni az előre összeállított szótárakat vagy a szivárvány táblákat (általában...), mert egyéni sónként kell nekik.
A weboldal néha elrontja ezt, és univerzális sót használ minden felhasználónak; Ez ellentétes a céllal.
Íme a sózott SHA1 hash:
b353977827f67a4ae0318f3a9447fae1c13d9d90: b8d18ca |___________________________________________| hash | só | elválasztó
Ennek a hash egyszerű szövege a "jelszó". A só értéke "b8d18ca", és az SHA1 ($salt.$pass) API-t használja. Ez azt jelenti, hogy az algoritmus megkapja a jelszó egyszerű szövegét, generálja a sót, és hozzáadja azt a sima szöveg elé. Amikor egy webhely vagy alkalmazás megpróbálja ellenőrizni a jelszavát a jövőben, bemenetként veszi az egyszerű szövegű jelszavát, elolvassa a salt értéket a tárolt hash-ben, hozzáadja a kiválasztott jelszó elé, és összehasonlítja a generált Hash értéket a tárolt Hash értékkel. Cracking Ha nem tudja, hogy egy része só, a hash a következő sima szöveget generálja:
b8d18capassword
Mivel az algoritmus sima szöveget ad be, a só és a generált hash értékek átláthatóak maradhatnak a felhasználó számára. A repedéskor, ha az algoritmus sóos, ismernünk kell a sót, hogy a jelölt egyszerű szövegek generálásakor biztosíthassuk.
A sózás megfelelően végrehajtva időigényesebbé teheti a repedést. A véletlenszerű sóval arra kényszeríti a Cracker-t, hogy időt vesztegetjen azzal, hogy megpróbálja feltörni a hash értéket, amelynek a salt nem egyezik. Ez nagyjából megteszi a device_speed/number_of_salts szükséges erőfeszítést, mert minden sóhoz jelöltet kell generálnunk. Ha a só statikus, akkor a matematikai műveletek ugyanazok... speed_of_device/1. Egy másik módja annak, hogy ezt nézze:
A mi GTX 980 cracks SHA1 ($salt.$pass) at 3576,8 MH/s vagy 3,5 milliárd jelölt per second hashlistánk 1000 egyedi sót tartalmaz 3 500 000 000 / 1000 = 3 500 000 jelöltek másodpercenként
Ez három nagyságrenddel lassabb, 99,9%-os veszteség. Statikus sóval így néz ki:
Our GTX 980 cracks SHA1 ($salt.$pass) at 3576,8 MH/s vagy 3,5 milliárd jelölt per second hashlistánk tartalmaz 1 egyedi sót 3 500 000 000 / 1 = 3 500 000 000 jelöltek másodpercenként
Ha ennek nincs értelme, olvass tovább, később lesz egy gyönyörű diagram...
iteráció
Egy másik gyakori fejlesztés az egyszerű „hash this plaintext "-hez képest, hogy „hash this plaintext, majd hash azt az eredményt, majd hash azt az eredményt" ezerszer ismétlődik. Ez lehetővé teszi, hogy egyetlen jelölt jelszó megpróbálása során a jelszófeltörő programnak több ezerszer kell végrehajtania. Ezt iterációnak, ciklusnak vagy változó költségnek nevezik. Egyes jelszó-hash algoritmusok keményen kódolt iterációs köröket használnak; Egyéb Git. Ezután magának a Hash részében konfigurálható. Például az md5crypt () MD5-öt használ, beleértve a sót is, és pontosan 1000-szer ciklik. Az sha512crypt () az SHA512-et használja, beleértve a sót, és konfigurálható számú ciklust (alapértelmezett 5000).
Az iteráció elsősorban a hash algoritmus számítási ciklusköltségét befolyásolja, nem pedig a memóriahasználatát vagy egyéb tényezőket. Ezek szintén fontos támadások, amikor a tervezés optimalizálva ellenáll bizonyos típusú hash típusoknak, de ez túl gyomos ahhoz, hogy itt megvitassák.
A hash típus hatása a feltörési sebességre
Nézzünk néhány példát a hash algoritmus kiválasztásának hatásainak bemutatására, legyen szó akár sózott, több iteráció használatáról stb. Tegyük fel, hogy egy támadó 1000 felhasználó hashértékét gyűjtött össze valamelyik fertőzött webhelyről, és csak egy egyszerű támadást akarnak végrehajtani, tesztelve minden jelszó hashértékét-143 millió jelölt jelszót.
A fertőzött weboldal által használt hash típus óriási hatással lesz arra, hogy a támadónak ez a támadás során szükséges idő alatt. Itt egy diagram, hogy (relatív, nagyjából) mennyi másodpercbe telik a támadás befejezése, a használt hash típusától függően, ahol a standard grafikus kártya:
Hát az nem használ! A legerősebb hash típus jóval lassabb, de a gyorsabb típus egyszerűen ellapozódik a semmiig. Próbáljuk meg újra ugyanazt az adatméretet logaritmikus X tengely idővel. Ahogy a sávok balról jobbra mozognak, 10-es hatványra nőnek:
Tehát néhány lényeg: egyetlen kör könnyebb, mint több kör, és só nélkül, mint sóval, amikor fel akarsz törni néhány jelszó hash-t. Ezzel szemben, amikor bizonyos cégek vagy webhelyek felhasználói adatokat tartalmazó adatszivárgást jelentenek be, a) a jelszót a legjobb, ha hash-ot végeztek, nem csak sima szöveget; b) jobb, ha sózottak, nem csak hash; c) Jobb lenne, ha erős, többkörös sózott hash-t használnának, nem csak egy kört.
A hash típusok azonosítása
Mielőtt megpróbálná feltörni az adott jelszóhash-t, a feltörő feladata, hogy kitalálja, melyik hash algoritmust használják annak megvalósításához. A hash típusok azonosítása általában egyszerű, de nem mindig. A kekszek gyakran tájékozott sejtéseket tesznek nyomok alapján, mint például a hash hossza és formátuma. Végső soron az egyetlen módja annak, hogy meggyőződjünk arról, hogy a hash típusú találgatás helyes-e, ha a hash feltört-e.
Itt és itt található néhány kiváló forrás ehhez a feladathoz, mindkettő megmutatja, hogy milyen a közös hash érték.
A Kali Linuxban elérhető a "hash-identifier" csomag (itt elérhető), amely segít az ismeretlen hash típusok azonosításában.
ütközés
Ütközés akkor lép fel, ha két különböző bemenet ugyanazt a hash kimenetet eredményezi. Rossz volt (nyilván). A jelszavak esetében ez azt jelentheti, hogy valószínűleg nem törtem fel a tényleges jelszavadat, de mivel találtam egy bemenetet, amely ugyanazt a hash értéket produkálja, sima szöveges értékkel becsaphatom a rendszert, hogy azt gondolja, hogy a jelszó legitim.
A Microsoft Office olyan algoritmust használ, amely évek óta konfliktusokra hajlamos a dokumentumvédelmében. Nem ritka, hogy egyetlen hash több ütközést találnak, amelyek mindegyike feloldja a dokumentumot.
Az algoritmus gyakorlatilag tönkremegy, amint ütközést találnak. Ha egyszer megtörténik, akkor statisztikailag nagy valószínűséggel újra megtörténik. Csak az idő és a feldolgozási képesség akadályozza minket. Ahogy az algoritmusok robusztusabbá válnak, több képességet és időt igényel a jelölt algoritmusok generálása és a hash kimenetek összehasonlítása a keresésük érdekében. Ennek eredményeként a tervezők egyre jobban tudnak olyan algoritmusokat létrehozni, amelyek kevésbé hajlamosak a konfliktusokra.