Er det vanskelig å lage sin egen login-side?

[????????]

De som vil hacke finner bedre løsninger enn å finne det ut med PHP, og dessuten så man f.eks. hacke sql serveren for å få tak i passordet og de som gjør det er vel så proffe at de har ikke noe problem med å "dekryptere" en md5() hash.

[The Red Devil]

Ein md5() hash må jo bli brute forcet. Så til meir innviklet passord du har til lengre tar det å "dekryptere" det.

 

Har fått til vane å lage eit lite script som tester at brukeren har brukt både små og store bokstaver og iallefall eit tall og at passordet er iallefall på 8 bokstaver/tall. Pluss den sjekker at passordet ikkje er det samme som brukernavn osv.

 

Er nok kansje litt irreterende for visse brukere, når dei får opp feilmelding om at passordet ikkje er sikkert nok.

 

Men det gjør iallefall litt vanskelegere å dekrypte passorda.

Endret 21. juli 2004 av The Red Devil

[Blodhemn]

En 4 karakters streng med a-z som mulige karakterer gir oss 25^4 mulige kombinasjoner.

 

La oss anta at du ikke har en ferdiglaget tabell der du har de forskjellige kombinasjonene knyttet opp mot en md5() hash av det ordet.

25^4 = 390625 mulige forskjellige kombinasjoner. Klarer du lage et PHP script som sjekker 390625 _unike_ kombinasjoner på 8 sekunder? PHP er raskt, men er det så raskt?

 

Statistisk sett så vil man aldri heller trenge å sjekke alle de mulige kombinasjonene. Sansynligheten for at den siste kombinasjonen man prøver er riktig er ikke stor.

 

Skulle gjerne sett hvor lang tid dette scriptet ville brukt på en bare litt værre streng.

a-zA-z og fire tegn vil gi oss 50 ^ 4 = 6 250 000. Det skal ikke mye til før det er så mange mulige kombinasjoner at å putte det inn i en database vil virke absurd.

 

I all ærlighet så var dette et ordbok ord, og det er mulig at det ble bruteforcet på denne måten.

Men kan vi være sikre at eneste måten å knekke en md5 hash er å bruteforce den?

Hvis det er eneste måten så er det ikke spesiellt vanskelig å beskytte seg mot det. Det er bare å salte passordet så mye at det vil ta latterlig lang tid å knekke den.

[Torbjørn]

Det er bare å prøve det...

 

hashen nedenfor er fra en 4 bokstavers kode a-z (bare små)

 

det tok 4.3 sek på en P4 2.4 GHz XEON, og 5.8 sek på en P4 2.0 GHz og 10 sek på en P3 1 GHz

 

<?php
$hash="63a9f0ea7bb98050796b649e85481845";

for($i=0;$i<26;$i++){
 for($j=0;$j<26;$j++){
   for($k=0;$k<26;$k++){
     for($l=0;$l<26;$l++){
       $code = chr($i+97) . chr($j+97) . chr($k+97) . chr($l+97);
       if(md5($code) == $hash){
         echo "svar = $code\n";
         exit;
       }
     }
   }
 }
}

echo "fant ikke svaret - er det virkelig 4 bokstaver a-z?\n";

?>

[Blodhemn]

Hah. Jau.. det var raskt

 

Koden nevnt tidligere visste ikke hvor mange karakterer det var på forhånd. Så egentlig måtte den teste flere muligheter. Matte er ikke mitt sterkeste felt. Men tror den må sjekke så mange forskjellige kombinasjoner som dette før den finner løsningen:

 

25+25^2+25^3+25^4

 

Men, selvfølgelig. Det ville ikke ta så mye lengre tid det. Spesielt ikke hvis det er så raskt som det er.

Endret 22. juli 2004 av Blodhemn

[Blodhemn]

Selv bruker jeg en saltet og kryptert user_agent streng.

Er vell gjerne AOL som kjører et merkelig og ødelegende system på ip'er for sine brukere.

Slik at IP for en AOL bruker kan forandres når som helst, har valgt og ikke bruke IP pga det.

 

Skal siden være "helt" sikker med tanke på å overta session til en bruker bør du vell også bruke ssl. Om brukernavn og passord sendes i klartekst og noen lytter etter dette vil de jo bare kunne bruke det for å logge seg selv inn som brukeren.

George Schlossnagle skriver i "Advanced PHP Programming" at enkelte ISPers proxyer gjør noe av det samme med User Agent informasjonen som de gjør med IP, og at å bruke User Agent til det formålet er omtrent like dårlig som å bruke Remote IP.

 

Edit: Skrev feil navn på boka

Endret 24. juli 2004 av Blodhemn

[????????]

Dette er et stort konfliktområde for en programmerer, redusere sikkerheten for brukervennlighet/funksjonalitet? Det er ikke ikke et lett spørsmål å ta standpunk til, men det er en ting en burde vurdere først. Hvilket "marked" er scriptet lagd for?

 

AOL brukere vet at de har problemer med mange login sider, og at de må av og til logge inn flere ganger - hvis de kommer inn i det hele tatt. Når det gjelder fjerning av user agent grunnet en proxy server, så betyr dette at proxy serveren må "filtrere" det bort - og det er det heldig vis ikke mange som gjør.

 

Chris Shiflett, som er forfatter av boken HTTP Developer's Handbook - foreslår nettopp bruken av USER_AGENT i en artikel som han skrev rundt jul for PHPmag. Artikelen er faktisk lagt ut gratis på nettet, klikk her for å lese den.

 

Som sagt så er det avhengig av hvilket "marked" man har som kundegruppe, og nettopp en det er verdt å inkludere brukere som har sånne "problemer". Dersom man kanskje vil få en del slike brukere på siden vil det kanskje være verdt å redusere sikkerheten på scriptet.

 

Uansett så er det noe som burde avdekkes av en tracker. Har du en litt stor side er du avhangig av en tracker for å se surfemønsteret til de besøkende. Den burde registrere data som USER_AGENT, og da er det lett å se hvis det er mange brukere som enten mangler eller har varierende USER_AGENT.

 

Det kan være lurt å starte med å lage scriptet så sikkert som mulig, og så eventuelt "redusere" det litt dersom det er et stort behov for det.

[Lurifaksen]

Slenger inn et spørsmål her:

 

Hvordan går det å bruke .htaccess til login?

 

Jeg har begrenset tilgangen til området med htaccess, og lagt til noen brukere. Jeg bruker verken cookies eller session. En bruker som er innlogget, identifiseres med "$_SERVER['PHP_AUTH_USER']" (brukernavnet han logget inn med).

 

Er dette en horribel måte å gjøre det på? (i mitt tilfelle er det ikke noe krise om noen logger inn med andres brukernavn, ingen vil heller forsøke å "hacke" seg tilgang, men er det allikevel en håpløs måte å gjøre det på?).

[Torbjørn]

nei, det er en funksjonell og sikker måte å gjøre det på...

[????????]

Jeg har fått et par meldinger(PM) om "dekoding" av md5. Selv så er jeg PHP programmerer og følger bare med på temaet, så jeg kan desverre ikke svare på alle mulighetene for å dekryptere en md5 hash. Det er viktig å merke seg følgende, for å dekryptere en hash er det ikke nødvendig å kjøre en bruteforce for hver gang. Mer avanserte hackere benytter seg av rainbow tables.

 

Det er veldig avhengig av hvordan man "salter" passordet for hvor sikkert det skal være. Dersom man legger til "12345" på starten så vil det ikke være noe problem å finne det ut, for vil det være likt på alle passordene. Løsningen er like dårlig dersom man legger til det et sted i passordet før man krypterer det. Eneste fordelen med et er at da vil det kanskje ta lengre tid å dekryptere det for de som kun bruker brute force.

 

Det er derfor viktig at en ikke tror lenge at det holder med å gjøre en slik enkel "salting".

[joffar]

Har hørt at sha1 skal være noe tryggere enn md5, er det noen som har hørt noe mere om dette?

[klasse]

<?php
$hash="63a9f0ea7bb98050796b649e85481845";

for($i=0;$i<26;$i++){
 for($j=0;$j<26;$j++){
   for($k=0;$k<26;$k++){
     for($l=0;$l<26;$l++){
       $code = chr($i+97) . chr($j+97) . chr($k+97) . chr($l+97);
       if(md5($code) == $hash){
         echo "svar = $code\n";
         exit;
       }
     }
   }
 }
}

echo "fant ikke svaret - er det virkelig 4 bokstaver a-z?\n";

?>

Does anyone know how to rewrite this to a recursive function ? I really suck at recursives...

[Akke]

Hvis siden er norsk og for norske lesere, er egentlig AOL problematikken noe å bry seg om?