Dekryptering af md5-kode

Det kan du ikke. Fordelen med md5 er netop at det ikke kan dekrypteres.

Man vil normalt tildele brugeren et nyt password som man fremsender og beder brugeren om at skifte password ved første login.

Havde det på fornemmelsen :D
Men det vil så sige at flere store brugersystemer, ikke krypterer deres passwords, siden at man kan få fremsendt sit password?

med rainbow Crack projektet kan du "dekrypterer" alle md5 hashede passwords på 16 karakterer og nedefter på omkring 4 minutter. Søg på Rainbow crack i google

Tager for lang tid. :D

16 tegn og nedefter? øhhh, så må det vist være meget begrænset hvilke tegn der må bruges

Rainbow crack kan dekrypterer alle passwords fra 16 tegn og nedefter, Store og små bogstaver, tal og specialtegn. De skal nemlig ikke delrypteres, de skal bare slås op i en meget stor table og det tager ca 4 minutter når man gør det distribueret i et grid

hvor finder du den tabel? Den må være rigtig meget stor

Den man kan hente inde på deres hjemmeside er ikke ret stor, ikke i forhold til at skulle knække så komplicerede hashes

Selve databasen er så kæmpestor at den vist ikke likker på en server, men mange fordelt ud over nettet så selve opslagene foretages samtidig på mange maskiner, det er derfor det kan gøres så hurtigt.

Jeg husker ikke om rainbow crack er gratis, men ved at opslag i tabellen er muligt fra diverse hacker linux distributioner. Hvordan det foregår fra windows ved jeg ikke

Jeg kunne også godt tænke mig at se en kilde til de alle op til 16 tegn på 4 minutter.

søg på rainbow crack det er derude. De 4 minutter er måske ovenikøbet et gammelt tal. Husk vi taler om distribueret samtidig søgning i mange databaser. Databasen er relativt simpel og betsår dybest set af to koloner, en med alle mulige kombinationer af 16 tegn og den anden kolone med hver muligheds tilsvarende md5 hashværdi. Så har du en hashværdi skal den "bare" findes i databasen så har du passswordet

Da jeg havde det samme problem, løste jeg ved at sende et link, der hed noget i retning af nytpassword.php?pass=[MD5], der lavede jeg så et db-opslag ($sql="SELECT * FROM users where md5=".addslashes($_GET['pass'])."\"") og en havde en form, hvorpå brugeren kunne indtaste et nyt password, med validering og hele balladen.

Det virkede perfekt

/y

bufferzone>

Hvis den beskrivelse var korrekt så ville 16 tegn kræve
70^16*(16+16) bytes hvilker er ca. 3 milliarder 500 GB diske per indbygger på
jorden.

Den tror jeg ikke på.

Nu er Rainbow tables faktisk en speciel form for dictionaries hvor man ikke gemmer
alle værdier.

Ifølge http://www.antsight.com/zsl/rainbowcrack/ kan de gemme 2901713047668 keys
på 36 GB.

Hvis key/GB ratioen er den samme for 16 lange passwords, så er det kun
en million 500 GB diske per indbygger på jorden.

Den tror jeg heller ikke på.

Mangler du ikke den halvdel der er søgeordet før det bliver hashet. Om man tror på det eller ej, så har rainbow crack projektet betydet at der i dag tales seriøst om two factor. Hvor langt de er nået ved jeg ikke og jeg ved heller ikke om man bruger disk teknologi. til den slags. Jeg har set den slags store tabeller der skulle gennemtravles nærmest fra ende til anden indtil man havde et resultat gennemført på bånd (Husker ikke om det var et eksperiment) hvor man faktisk kunne opnå ganske høje søgehastigheder

I første udregning har jeg regnet med 16 bytes til plain text og 16 bytes til hash.

<ole>

bufferzone >> Umiddelbart ser Arnes udregning helt korrekt ud - og hvad 'man' taler om på nettet, skal man nok tage med et vist gran salt (og ofte med et ton salt!). Det samme gælder mange af de eksempler folk opstiller.

F.eks. er det blevet et nærmest uigendriveligt faktum, at innerHTML er dramatisk hurtigere end DOM til data indsættelse i et dokument i forbindelse med Ajax. Årsagen er, at quirksmode.org har lavet et eksempel, der tydelig viser, at det forholder sig sådan.

Sagen er blot, at han i et laaaangt loop kun tester med indsættelse af ét tegn i et element. Laver man samme test med lidt større datamængder, får man helt andre resultater - f.eks. at DOM i Firefox kan være op til 15 gange hurtigere end innerHTML!

Samme site har 'begavet' os med lignende performance test omkring skift af CSS-klasse kontra skift af de enkelte style properties. Igen er det kun én test, der skal til at få skræmmende mange kodere til at slå fast som et uigendriveligt faktum, at klasseskift performer bedst.
Ikke desto mindre har roenving og jeg ved flere lejligheder lavet eksempler i yderst realistiske dokumenter, hvor klasseskift tager flere sekunder længere end skift af de enkelte style propeties.

Werner Heisenberg sagde engang noget i stil med:
    "Det, vi oplever, er ikke virkeligheden - men virkeligheden udsat for vores måde at spørge på"

Man skal passe meget på med, hvad man lægger i de eksempler, man får forevist - samt at lytte til, hvad 'man' taler om  ;o)

/mvh
</bole>

Jeg kunne ikke finde på at betvivle Arnes beregninger, men hele denne diskussion er noget teoretisk, især fordi jeg ikke er nøjagtig nok i mine udsagn. Se det er således.

Da "Crackingen" af passwordet i virkeligheden er et opslag i databasen, kunne vi teoretisk lige så godt finde det korrekte password til hasværdigen ved første opslag som ved sidste. De 4 minutter er derfor ikke et udtryk for hvor lang tid det ville tage at gennemlæse alle records i databasen, eller for den sags skyld hvor mange records der i virkeligheden er. De 4 minutter er en statisk værdi der siger noget om hvor lang tid det gennemsnitligt vil tage at slå et password op og hvis jeg husker korrekt (det er 5 år siden jeg sidst regnede på denne slags opgaver) så er det ikke engang et gennemsnit for alle passwords, men et udtryk for hvornår halvdelen af passwords vil være fundet.

Stadig under forudsætning af at jeg husker korrekt, så vil de 4 minutter altså være den tid det tager at finde 50 % af passwords, herunder både de dårlige, de korte, de direkte tåbelige.

Man skal huske at de fleste passwords er lavet af mennesker og de fleste af dem ikke er særlig gode, hvilket for mig betyder at de 4 minutter nok er et ret sobert tal for en given organisation og den så bruger 16 karakterer som sine passwords.

Jeg beklager min lidt løse formulering og skal gøre opmærksom på at jeg er i tvivl om de 50 % både som procent sats og om det er fundne passwords eller om det er 50 % af alle records. Min tid har ikke lige været til atjeg har kunne læse ordentligt op på det. Problemstillingen er i alle tilfælde virkelig nok og skulle jeg have ramt helt forkert og det faktisk tager hele 20 minutter at finde et password, så ville jeg ikke betragte denne tidsudvidelse i forhold til de 4 minutter som et fald for princippet faktisk ikke engang om det skulle tage en dag

statisk = statistisk

Lige nu er det vist ikke antallet af minutter, men størrelsen på tabellen der virker mest underligt. Ikke nok med at den skal være helt enormt stor, det vil også tage pænt lang tid at lave den.

Det er ikke LM hashes du tænker på? De kan jo deles op i to dele, med 7 tegn i hver. Så behøver tabellen ikke være nær så stor for at bryde et komplekst password på op til 14 tegn

Er I ikke kommet lidt off-topic????

/y

Hvis det ikke er muligt at gemme en sådan database p.g.a. størrelsen, så er truslen jo
noget teoretisk.

Og et normalt dictionary attack er kun et database opslag, men brug af rainbow
tables er faktisk en kombination af mange udregninger og database opslag.

>> y  Nu er det sådan at jeg tilfældigvis har gemt alle oplysninger i arrays, så din kode fra før virker ikke helt. :)

Men jeg finder selv ud af at lave noget lignende, så svært er det vel ikke. Det jeg var interesseret i var om det var muligt at 'dekrypterer' koden.

>> Alle
Hvad synes i egentlig om at gemme alle brugeroplysninger i arrays?

Ps. det er helt okay med mig at spørgsmålet bevæger sig væk fra det oprindelige...

Om man læser alle brugeroplysninger op i memory ved app start eller henter oplysninger
om den enkelte bruger når de skal bruges har ikke så stor sikkerheds betydning.

De ligger jo på disk i begge tilfælde.

Så gør du således:
if(in_array($_GET[pass],$brugerarray)) {
  //her mailes
  }

/y

kan sagtens lave koden, det er ikke det jeg er interesseret i. Og nej den ville ikke se sådan ud...

Vil gerne hører jeres meninger om at bruge arrays i stedet for mysql. Er det f.eks. et hak ned/op i sikkerheden??

Jeg vil mene, at vedligeholdelsen er lettere med mysql fremfor med arrays.

Mht sikkerheden tror jeg den er nogenlunde den samme

når du siger vedligeholdelse, hvad mener du så?

Så mener jeg tilføjelse, fjernelse og opdatering af modtagerne. Skalering er også noget lettere med mysql.

Men det er jo det jeg plejer at bruge, hvis du forstår

/y

har jeg ingen problemer med. Bruger streg_replace() til det...

Hvis du har en fil 'array.php' med et array:
    <?php $arr = array("en", "to", 3, "fire", 5, "seks") ?>

Så kan du inkludere den og opdatere array'et - som array - for til sidst at bruge PHP5's json_encode til at udskrive en ny array-streng:

<?php
include("array.php");

$arr[] = "syv";
$arr[] = "otte";
$arr[] = "ni";
$arr[] = "ti";

$sArr = json_encode($arr);
$sArr = preg_replace("/\[|\]/", "", $sArr);

$fp = fopen("array.php", "w");
fwrite($fp, "<?php \$arr=array(".$sArr.") ?>");
fclose($fp);
?>

- eller du kan også:

<?php
include("array.php");

$arr[] = "syv";
$arr[] = "otte";
$arr[] = "ni";
$arr[] = "ti";

$fp = fopen("array.php", "w");
fwrite($fp, "<?php \$arr=array('".implode("','", $arr)."') ?>");
fclose($fp);
?>

mente selvfølgelig preg_replace...

Men det jeg bruger virker fint nok...

Det nederste eksempel, kan du kort forklarer hvad der sker i tredje sidste linje?

Jeg åbner filen 'array.php' - som jo indeholder mit array - og gør klar til at læse den:
    http://dk.php.net/manual/da/function.fopen.php

Fordelen ved denne fremgangsmåde er, at jeg ikke behøver sidde og fedte med en streng, når jeg skal opdatere array'et. I stedet kan rette array'et med alle de array-funktioner, PHP tilbyder - og tilslut skrive det ud  =)

Jeg kender godt fopen, men ikke implode. Så hvidt jeg ved bruges implode da til at indsætte et/flere tegn imellem det specificerede tegn, så hvordan virker linjen:

fwrite($fp, "<?php \$arr=array('".implode("','", $arr)."') ?>");

nåh lukker spørgsmålet da det ikke længere er aktivt...

Spørgsmålet var:

"Jeg har nemlig gemt den i en krypteret form med md5(), så hvordan dekrypterer jeg?"

og hvad var det rigtige svar ?

At det vist ikke er muligt :D

Det fik du så svar på allerede i 02/03-2008 17:52:49.

Men desuden stillede du en del opfølgningsspørgsmål som dui også fik svar på.

... så hvorfor tager du så selv dine point igen?

Din fremgangsmåde strider lodret mod gængs, god skik på Eksperten. Da du er rimelig ny i dette forum, ville det nok være en god idé at kikke lidt her: http://expfaq.dk/

Det må i meget undskylde.

Men for det første så det ikke ud til at der var aktivitet længere.
For det andet drejer det sig ikke om så mange point, og for det tredje, ved jeg ikke hvem der skulle have disse point.

Men jeg er da klar på at oprette et par ekstra (tomme) spørgsmål og så give jeg nogle point, som en slags erstatning.

Det er for mig slet ikke et spørgsmål om points - eller for den sags skyld om Eksperten. Det mindste, man kan gøre, når folk kommer vrimlende for at hjælpe én, når man kalder, er at sige tak for hjælpen - uanset kontekst  ;o)

Som sagt undskyld. - Og tak for hjælpen ;)

1) Aktiviteten i dine spørgsmål afhænger jo af om sprøgsmålet er besvaret eller ej, og om du selv yder en aktiv indsats. Hvis dit spørgsmål er besvaret er der jo ingen grundt til yderligere aktivitet, andet end fra din side.

2) Om et spørgsmål er på 100 eller 15 point ændre intet ved om man skal være taknemlig for de svar man får. Antallet af point skal udelukkende afhænge af spørgsmålets omfang. Hvis et spørgsmål er besvaret tilstrækkeligt eller har været medvirkende til at spørgeren har fået løst sit problem, skal den som har skrevet svaret, vel som minimum have mulighed for at modtage point for sin ulejlighed og hjælp.

3) Hvem der skal have point afhænger af hvem der har svaret på dit spørgsmål. Hvis der er flere, så er der flere som skal dele point. Men det er op til dig at bedømme hvem der skal have point for rigtig svar.

Men altsammen er jeg sikker på står i reglerne eller på http://www.expfaq.dk

Så vi enige om at jeg har dummet mig?

Det kan vi godt være enig om ... med det vil vi ikke bære nag over.

Som spørger er det dit ansvar at fordele de point du har udlovet for at få et svar. Hvis der ikke er nogen som har lagt et Svar så beder du dem simpelthen bare om at lægge et sådan at du kan give dem point. :^)

Du kan spørge: Hvorfor lægger folk ikke bare et svar hvis de gerne vil have point? Svaret på dette er at der er dem som gerne vil vente med at lægge et svar før at det er 100 % sikkert at spørgeren faktisk har fået løst sit problem. Derfor.

Det vil jeg så være ekstra påpasselig med fremover.