Login system og sikkerhed

1. Du kan løse det på mange måder..
mange bruger sessions til at gemme om man er logget ind.. og tjekker så i toppen af hvert site om man er logget ind...

2. Kodeordet skal selvfølgelig krypteres :) - Brugernavnet skal ikke krypteres, da du skal kunne hente det tilbage igen..

3. Sessions er langt bedre end cookies, eftersom indeholdet af cookies kan ses på den lokale maskine. Sessions kan også opsnuses, hi-jackes eller hvad du nu vil kalde det, men det kræver lidt mere teknisk snilde. En ideel løsning ville selvfølgelig være SSL :)

4. Du tænker på funktionen usleep(usec); som ikke virker i win32. Den eneste fordel jeg umiddelbart kunne se ved brugen af dette, er at det går længere tid mellem loginforsøgene, fordi det tager længere tid at få en fejlmeddelse. Denne kode kan bruges istedet for usleep();

function usleepWindows($usec){
  $start = gettimeofday();
  do {
      $stop = gettimeofday();
      $timePassed = 1000000 * ($stop['sec'] - $start['sec']) + $stop['usec'] - $start['usec'];
  }
  while ($timePassed < $usec);
}

usleepWindows(200000);

bah, forskellen mellem sleep(); og usleep(); er bare at i den ene funktion skal forsinkelsen opgives i sekunder og i den anden funktion i mikrosekunder :D

fynbo > Vedrørende punkt 4 var det i kommentarerne på www.php.net/sleep jeg fandt den påstand

1) Det er absolut nødvendigt. Som hovedregel kan du ikke regne med noget som helst du modtager fra klienten. Dette er den vigtigste regel overhovedt.

"Consider all input hostile until proven otherwise and code accordingly."

2) Krypter al vital information som klienten har adgang til.

3) Som udgangspunkt er PHP's session mekanisme som den kommer IKKE sikker.

Jeg vil IKKE anbefale dig at bruge PHP's indbyggede SESSION mekanisme SOM DEN ER pr. default. Der er væsentlige sikkerhedsproblemer (faktisk har Eksperten.dk ét af problemerne - i må selv regne ud hvilket).

Læs i den forbindelse : http://www.webkreator.com/php/configuration/php-session-security.html

Du kan godt bruge SESSION mekanismen i PHP, hvis du implementerer din egen session håndtering, og har helt styr på hvad du gør i denne forbindelse.

Anvend eventuelt: http://www.n3rds.com.ar/files/docs/php_sessions/sess_handler.txt

4) Det er ikke sandt, og ikke noget du skal stole på. Du kan indføre anden form for sikkerhed, der blokere en given IP, ved et vist antal forkerte loginforsøg etc.

5) En log over alle transaktioner og et system til at gennemse dine logs.

Jeg kan varmt anbefale dig at læse:

"OWASP Guide to Building Secure Web Applications and Web Services" 
http://www.owasp.org/guide/

Den indeholder mange af de fornuftige overvejelser du gør dig og mere til.

1. nej. tværtimod vil det kræve at du sender kodeord/brugernavn frem og tilbage hele tiden så de er nemmere at aflytte.

2,3. undgå at gemme i en cookie, den kan andre med adgang til computeren hurtigt finde. Det er til gengæld ret så sikkert at gemme i en session på serveren.

4. mange hackere benytter sig at at en computer kan afprøve tusinder af kombinationer i sekundet. Ved at forsinke responsen med en lille sleep(1) koster det dem tusind gange så lang tid. Legitime brugere der kender et korrekt kodeord bemærker knapt nok forsinkelsen.

5. sikkert :)

Takker, det er lidt at fundere over i hvert fald :) Men der synes at være lidt uenighed omkring nogen ting.

1. Hvis man nu vægter for/imod argumenterne, hvad vejer så mest :)

2. Vel ingen tvivl, gang i MD5 :)

3. Her må vi også kunne komme frem til en mere fast konklusion. Hvis vi antager at det er på egen server, hvor jeg har styr på konfigurationen og der kun køres et site på den server. Men sessions er vel stadig den mest sikre metode, hvis man skal have funktionaliteten.

Hvor kan man evt. finde ud af hvordan SSL fungerer?

4. Må indrømme at her virker jakoba's svar ikke helt dumt, men det er vel så også den eneste forklaring

1. Det drejer sig om sikkerhed. Så jeg gentager gerne:

"Consider all input hostile until proven otherwise and code accordingly."

Dette betyder, at du skal checke de informationer du får fra brugeren, med den oplysninger du ved er korrekte, og det skal du gøre for hver eneste side.

3. Jeg håber du har læst mine links. Hvis man er omhyggelig kan det bestemt blive godt.

4. Det er ikke relevant. Det bør aldrig være muligt at foretage tusinder (end ikke 10) på hinanden følgende mislykkedes login forsøg.

SSL er glimrende til nogle ting. Men brug det ikke som en sovepude. De andre ting skal også være på plads.

mercur8 > Du har ganske ret med henhold til at tjekke input grundigt, lige netop det har jeg altid gjort meget ud af, og var bare i tvivl om det var nødvendigt at tjekke brugernavn og kodeord på alle sider når nu register_globals er slået fra som default (og altid hos mig)

Synes ofte det er svært at finde helt klare informationer omkring sikkerhed, hvor der ikke er for og imod argumenter hele tiden, og en masse "tvivl" omkring hvad der nu er rigtigt eller ej.

Jeg har læst dine links, men vil nok gå dem igennem en gang eller 10 mere, for at være sikker på jeg ikke overså det vigtigste :)

Punkt 4... Kan du jo have helt ret i, men man kan vel heller ikke være sikker med din løsning... Man kan vel ikke være sikker på at vedkommende bruger den samme IP under hvert forsøg... Er nok ude i extremer, men en sådan person ville vel gøre alt for at skjule sig selv, og ville vel aldrig have fast IP, og der kunne vel skiftes automatisk en gang imellem, eller tager jeg fejl, er trods alt kun et gæt da jeg aldrig selv har beskæftiget mig med at bryde ind nogen som helst steder :)

At du skal checke de modtagne oplysninger mod databasen, har ikke noget at gøre med om register_globals er ON eller OFF. Bemærk at man også kan placere de variable man sender til dit script i de array's man har lyst til.

Ja, du må prøve at sammenstykke noget udfra de råd du får og læser dig til. Og den erfaring du selv gør. Den vigtigste er (som det ligner du gør) at researche godt på området, inden man kaster sig over programmeringen. Og så hele tiden tænke sig om. Der hvor det oftest går galt, med den her slags web autoriserings systemer, er manglende validering af brugerinput og sql injections. Ting der er uddybet i OWASP guiden også.

Ja IP'en kan også skifte. Den brugernøgle du anvender skal være tilstrækkelig unik og tilstrækkelig lang til, at den ikke umiddelbart kan brute-forces. Jeg siger ikke dit sleep halløj ikke kan bruges, men det er bare ikke det, der alene gør den del af dit system sikkert.

"Bemærk at man også kan placere de variable man sender til dit script i de array's man har lyst til"

Hvordan det? Hvis det er sandt, kan jeg ikke se hvorfor man har slået register_globals fra som default... Det var vel (bl.a.) for at skaffe sig af med det (lidt for typiske) sikkerhedshul.

...

Jep, forsøger heletiden at blive klogere, ikke kun på dette område :)

De array's er da bestemt også en god ting. Dem skal du endelig fortsætte med at bruge. Du har langt bedre styr på alle dine variable, og ved hvor de kommer fra. Endvidere holder det dine interne variable helt adskilt fra det, der kommer fra brugeren.

Man ville aldrig fra klienten kunne ændre resultatet af scriptet <?= echo $foo; ?> med register globals off (aldrig kunne ændre værdien af $foo). Det ville man jo kunne tidligere (eller med register globals on)

Og når du eg. checker $_POST['user_status'] for en værdi, ved du at variablen virkeligt er post'ed til scriptet. Men lad os sige, du har denne variabel user_status på din side i en <input type='hidden' name='user_status' value='normal'>. Jeg kan ikke umiddelbart ændre denne værdi ved at sende ?user_stauts=admin el. lign via GET i url'en. Men jeg kan jo ændre den at udføre nedenstående (eg. telnet til din server på port 80):

POST /foo.php HTTP/1.0
Accept: */*
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0
Host: www.foo.com
Content-Length: 17
Pragma: no-cache
Connection: keep-alive

user_status=admin

Nu ville jeg så i et rigtigt usikkert system kunne udgive mig for at være admin.
Det er det jeg mener, når jeg skriver, at man kan placere de variable man sender til dit script i de array's man har lyst til.

Håber det gav lidt mening.

Nåe, jamen så er vi jo enige på det punkt, misforstod dig bare :)

Er vist så tid til at lukke, vil mene jeg har fået svar på mit spm... Takker alle 3, mercur8 må nok løbe med points i denne omgang