在线hashcat解密 Hashing og kryptering? Hvad er en hash værdi, hvad er hash-kryptering, og hvad er hash dekryptering?
Hash og kryptering
Der er en almindelig misforståelse om, at hash og kryptering er det samme. Det er de ikke. Hash er irreversibel. Tag følgende eksempel som et eksempel:
$ echo-n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb-
Vi passerer strengen "Password123" til MD5-algoritmen (algo), som udfører matematiske operationer og returnerer den genererede hexadecimalkodede hash. Den eneste måde at få den samme hash-outputværdi på er at indtaste algo oprindeligt. Der er konflikter, men vi kan tale om det senere.
Outputtet fra de fleste hash-algoritmer er en hexadecimalkodet binær streng med fast længde. Andre, som dette eksempel, bruger en Base64-kodet streng som output. Bemærk, at længden altid er den samme:
{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w =
{SHA} lqdu/Zr6o2dgIER8Up1/7lcUtgw =
{SHA} qYUOwLMlDEuukA5HCT4LR1kQzco =
{SHA} MXZBCpyWJ7TTs1w2kgGJslwNwTg =
{SHA} 2sAPLaUh9Mz0bI + XxKEg7qyABe8=
TL; Dr.
Kryptering er reversibel, hashing er ikke
Jeg vil ikke tale for meget om kryptering (fordi de ting er til bøger), men det er vigtigt at kunne skelne mellem hashstrenge og krypterede strenge. Kryptering fylder normalt en streng, der opfylder en bestemt længde, før kryptering finder sted. Det kræver også en nøgle (eller adgangskode) for at dekryptere. Hvis du bruger en krypteret adgangskode, vil strengen ændre sig afhængigt af længden af inputtet. Hvis du ser en masse ciphertext-adgangskoder, varierer længden, og du beskæftiger dig muligvis med kryptering i stedet for hash. AES-256-CBC Eksempel Krypteret streng og tilhørende almindelig tekst (nøglen er "ASDF"):
foobar | U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = foobarfoobar | U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = foobarfoobarfoobar | U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + ldatuqv2xexeaeoww0xg/EXJUe9aSUz $ kat kryptered_adgangskoder U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz $ for i i `cat encrypted_passwords`; gør ekko $i | openssl enc -base64 -d -aes-256-cbc -pass pass:asdf; ekko; Færdig foobar foobarfoobar foobarfoobarfoobar
Nu tænker du nok: Du har nok ret. At nøglematerialet skal være tilgængeligt for systemet betyder dog, at det i det væsentlige er en plain text master password placeret et sted-enten som en RSA-nøgle eller en password eller en fil, indlejret i en database, hardkodet i en applikation eller en password et sted i hukommelsen. pfft, ingen ' kommer til at bruge asdf som nøglen til at kryptere deres brugeres ' adgangskoder
Brug samme streng for MD5:
foobar | 3858f62230ac3c915f300c664312c63f foobarfoobar | 59faa421729e846dd800dce59943bfc0 foobarfoobarfoobar | 1352aadab322d1a033c27964be0965db
Hash-adgangskoden er langt fra perfekt, faktisk er den lidt dårlig, men den er værre end kryptering på grund af hvad den forsøger at opnå. Brugere vælger det absolutte minimumskrav oftere end not og kan også bruge det på flere websteder. Mange "hacks" er faktisk intet andet end angreb på genbrug af legitimationsoplysninger. Hvis det oprindelige kompromis er at bruge kryptering, er den eneste indsats, som angriberen skal gøre, at finde nøglen til at dekryptere alle adgangskoder. For hash skal de i det mindste gøre en indsats for at knække dem. Når det bruges sammen med moderne algoritmer som sha512crypt, bcrypt, scrypt eller argon2, kan hash-værdier kræve en stor indsats at knække.
Marinering
Tilsætning af salt er at tilføje en streng til adgangskoden før hash. Saltet for hver hash skal være unikt, normalt tilfældigt valgt, fordi pointen er at få den samme plaintext "password" hash til at have en anden værdi hver gang. Det gør livet svært for en password cracker, for for at tjekke ordet "password" for hver af de 1.000 brugere, der har et unikt SALT, skal de gøre det 1.000 gange-én gang pr. bruger/SALT. Det betyder også, at de ikke kan bruge forudkompilerede ordbøger eller regnbuetabeller effektivt (normalt...), fordi de kræver en brugerdefineret per salt.
Hjemmesider roder nogle gange dette op og bruger generisk salt til alle brugere; Dette strider imod formålet.
Her er SHA1-hash med salt:
b353977827f67a4ae0318f3a9447fae1c13d9d90:b8d18ca |___________________________________________| hash | salt | separator
Den klare tekst af denne hash er "adgangskode". Dens saltværdi er "b8d18ca" og bruger SHA1 ($salt.$pass) API. Det betyder, at algoritmen tager adgangskodens almindelige tekst, genererer salt og tilføjer det foran almindelige tekst. Når et websted eller en app forsøger at bekræfte din adgangskode i fremtiden, vil den tage din plaintext-adgangskode som input, læse saltværdien i den gemte Hash, tilføje den foran den adgangskode, du har valgt, og sammenligne den genererede hash-værdi med den gemte hash-værdi. Cracking Hvis du ikke ved, at en del af det er salt, vil hashen producere følgende almindelig tekst:
b8d18capassword
Da algoritmen laver almindelig tekstinput, salt og den genererede hashværdi kan forblive gennemsigtig for brugeren. Ved cracking, hvis algoritmen er salt, skal vi kende saltet, så vi kan levere det, når vi genererer kandidatens almindelige tekst.
Hvis det udføres korrekt, kan saltning gøre revner mere tidskrævende. Med tilfældige salter tvinger du Cracker til at spilde tid på at forsøge at knække hash-værdier, som saltet ikke matcher. Dette udfører nogenlunde den krævede indsats for enhed_speed/number_of_salts, fordi vi skal generere en kandidat til hvert salt. Hvis saltet er statisk, så er matematikken den samme... speed_of_device/1. En anden måde at se dette på:
vores GTX 980 cracks SHA1 ($salt.$pass) ved 3576,8 MH/s eller 3,5 milliarder kandidater pr. sekund Vores hashliste indeholder 1000 unikke salte 3.500.000.000 / 1000 = 3.500.000 kandidater pr. sekund
Dette er tre størrelsesordener langsommere, et tab på 99,9 %. Ved brug af statisk salt ser det sådan ud:
vores GTX 980 cracks SHA1 ($salt.$pass) ved 3576,8 MH/s eller 3,5 milliarder kandidater pr. sekund Vores hashliste indeholder 1 unikt salt 3.500.000.000 / 1 = 3.500.000.000 kandidater pr. sekund
Hvis det ikke giver mening, fortsæt med at læse, vi vil have et smukt diagram senere...
iteration
En anden almindelig forbedring i forhold til blot at "hash denne almindelige tekst" er, at "hash denne almindelige tekst, hash derefter det resultat, og hash derefter det resultat" gentages tusindvis af gange. Dette gør det muligt at prøve en enkelt kandidatadgangskode, når adgangskodeknækkerprogrammet skal udføre tusindvis af operationer. Dette kaldes iteration, loop eller variabel omkostning. Nogle adgangskodehashalgoritmer bruger hårdkodede iterationsrunder; Andre Git. Gør det konfigurerbart i en del af selve Hash. For eksempel bruger md5crypt () MD5, inklusive salt, og cykler nøjagtigt 1000 gange. sha512crypt () bruger sha512, inkluderer et salt og cykler et konfigurerbart antal gange (standard er 5.000).
Iterationer påvirker hovedsageligt beregningscyklusomkostningerne for hash-algoritmen frem for dens hukommelsesforbrug eller andre faktorer. Disse er også vigtige angreb, når designet er optimeret til at modstå visse typer hash-typer, men dette er for ukrudt til at blive diskuteret her.
Effekten af hash-type på crack-hastighed
Lad os se på nogle eksempler for at demonstrere virkningen af hash-algoritmevalg, uanset om det er saltet, ved hjælp af flere iterationer osv. Antag at en angriber indsamler 1.000 brugerhash-værdier fra et inficeret websted, og de ønsker kun at udføre et simpelt angreb, der tester hver adgangskode-hash-værdi-143 millioner kandidatadgangskoder.
Den type hash, som den inficerede hjemmeside bruger, vil have en enorm indflydelse på, hvor lang tid det tager for angriberen at passere angrebet. Her er et (relativ, omtrent) diagram over, hvor mange sekunder det tager at fuldføre angrebet, alt efter hvilken type hash der bruges, hvor standard grafikkort:
Nå, det er ubrugeligt! De stærkeste hash-typer er meget langsommere, men de hurtigere typer bliver bare knust til ingenting. Lad os prøve den samme datastørrelse igen ved hjælp af logaritmisk x-akse tid. Når stængerne bevæger sig fra venstre til højre, vil de stige med 10 til potensen:
Så nogle af hovedpunkterne er: Når du vil knække nogle adgangskode-hash, er enkeltrunder lettere end flere runder og uden salt end med salt. I modsætning hertil, når visse virksomheder eller websteder annoncerer et databrud, der indeholder brugerdata, a) er adgangskoden bedst hashet, ikke blot almindelig tekst; b) De er bedst saltede, ikke bare hashede; c) Det er bedre, at de har brugt kraftfulde multi-runder saltede hash hele tiden, ikke kun enkeltrunder.
Identifikation af hash-type
Før man forsøger at knække en given password-hash, er det op til cracker at finde ud af, hvilken hash-algoritme der bruges til at implementere den. Identifikation af hash-typer er normalt enkel, men ikke altid. Crackers laver ofte velinformerede gæt baseret på spor som hash længde og format. I sidste ende er den eneste måde at være sikker på, om hashtypen gætter korrekt, om hashen er knækket.
Der er nogle fremragende ressourcer til denne opgave her og her, og de viser begge, hvordan almindelige hash-værdier ser ud.
Pakken "hash-identifier" (tilgængelig her) er tilgængelig i Kali Linux, som hjælper med at identificere ukendte hash-typer.
Kollision
Kollision opstår, når to forskellige input resulterer i samme hash-output. Det er dårligt (åbenbart). For adgangskoder kan det betyde, at jeg måske ikke har knækket din egentlige adgangskode, men da jeg fandt et input, der producerer den samme hash-værdi, kan jeg bruge almindelige tekstværdier til at narre systemet til at tro, at adgangskoden er legitim.
Microsoft Office bruger i sin dokumentbeskyttelse en algoritme, der i mange år har været udsat for konflikter. Det er ikke ualmindeligt at opdage flere konflikter for en enkelt hash, som alle låser dokumentet op.
Når en konflikt er fundet, bliver algoritmen faktisk ødelagt. Hvis det sker én gang, er det statistisk set meget sandsynligt, at det vil ske igen. Det eneste, der står i vejen for os, er tid og håndteringsevne. Efterhånden som algoritmer bliver mere robuste, tager det mere kraft og tid at generere kandidatalgoritmer og sammenligne hash-output for at søge efter dem. Som følge heraf bliver designere mere og mere gode til at skabe algoritmer, der er mindre modtagelige for konflikter.