Sleep - som firewall ?

Skal nok lige nævne at mine sider er meget "PHP-tunge", så det er primært CPU-belastning jeg er bekymret for...

Jeg forstår slet ikke hvordan du overhovedet kan komme til at få den idé at 'sløve' dit site ned for brugerne? Udover det vil det ikke give meget mening, for trafikken er jo stadig genereret og dine PHP filers eksekvering står jo bare og hænger i processen - dine brugere vil bare opleve dit site som unødigt langsomt.

Caching og loadbalancing er den vej man skal gå, hvis man virkelig har behov for at optimere.

Ja, jeg skulle ikke have blandet "gruppe 1" ind i problemet - mudrer det lidt..

Ideen var primært rettet imod brute-force angreb.

Og tanken var at en alm. bruger ikke vil "opleve" nogen forsinkelse selvom php piller næse i 2 sekunder. Men det vil vanskelig/umuliggøre brute-force gætterier.

Du vil ikke kunne undgå brute-forcing, men du kan stoppe processeringen af dine scripts i tide ved hjælp at captcha mekanismer.

Og tungt indhold på visning bør være cachet, hvis du ikke kan undgå proccessering af de elementer.

Ahh ja, det var nok bedre: Random captcha - efter 10-50 requests.
- vil forpurre et brute-force angreb - og kun relativt sjældent genere brugerne (måske ligefrem give en øget følelse af at deres sikkerhed bliver taget alvorligt).

Praktisk:
Inkluderet "øverst" på alle sider - HVIS random(100) == 23.
- så jeg slipper for at holde regnskab for hver enkelt iP...

Læg et svar!

Så kan jeg tilgengæld lægge en solid forsinker ind på error-siderne (404 osv)

Jeg cacher i forvejen så meget som muligt - men der er en afvejning som jeg synes er svær: Om en opgave skal ligge på php-siden, eller lægges ud til javascript i brugerens browser sammen med de "rå data"...

På den ene side er det altid bedst at få flyttet arbejdet væk fra serveren, og de fleste brugere sidder på gigahertz maskiner som intet fornuftigt laver. På den anden side så ER systemet jo den kode som ligger på serveren, hvis det hele ligger i JS, kan enhver jo bare "snuppe" koden og klaske et database-interface bagpå til de "rå data"...

sleep() kommandoen gør jo bare siden langsom? Jeg forstår ikke logikken i at bruge den, heller ikke på error siderne?

Du bruger formegentlig alligevel sessions til dine bruger logins. Hvorfor så ikke bare tjekke hvor mange forsøg der er lavet, og hvis det er over XX, så vis en captcha man skal løse for man får 5 nye forsøg. At bruge random virker ikke som en god løsning, man sagtens komme til at ramme den flere gange som alm. bruger selvom sandsynligheden er 1/100.

Denial-of-service får du svært ved at beskytte dig mod gennem PHP. Selvom du bruger sleep vil der stadig blive oprettet så mange processer at serveren vil holde op med at svare. Jeg vil mene at sleep gøre det værre, ved at de holder i live længere end nødvendigt.
Hvis du er bekymret for DoS, så kan du overveje at bruge f.eks. skyen til at håndtere det. Herudover er DoS ikke noget 99,9999% af websites nogensinde vil blive udsat for. Det bliver typisk kun gjort, hvis dem der har muligheden for det, har en meget specific grund til at gøre det. Jeg ville typisk ikke tage specielle forholdsregler mod det.

Ikke Langsom, blot lidt langsomere. Ikke nok til at almindelige brugere bemærker noget, men nok til at det ikke længere er muligt at "teste" en million iD'er - inden for rimelig (ikke-geologisk) tid.

Jeg bruger ikke sessions, men en cookie med bruger-iD'et i - så det ligner lidt.

Og ja, DoS skal nok stoppes af server-parken - ikke hver enkelt lille (virtuelle!) maskine : )

Man kan vel sende 1.000 eller 10.000 afsted ad gangen, hvis man ønsker at bryde den. Så bør en lille forsinkelse på hver ingen større forskel. Og dit random() gør jo, at hvis man får en captcha, så prøver man bare igen, og så får man ingen næste gang.

Den eneste pålidelige metode jeg kan se, er at gøre så man kun har f.eks. 5 forsøg pr. brugernavn pr. 24 timer, og man ellers får en captcha. Det andet ligner symptom-behandling i mit hoved.

Hm.. det kan der jo være noget om... shit!

Men det kan en session vel ikke kurere - hvis tølperen bare starter 1.000 sessions op paralelt ?

Tråden har vist taget en sjov drejning i forhold til kapacitet?

Bruteforce angreb (som nok er mere relevant i forhold til DoS) er typisk services der er sat op til at gentage et specifikt mønster for at undgå det manuelle repetitive arbejde; problemet med automatik er at man ikke kan tage højde for tilfældige variabler.

Indarbejd en CRSF tilgang til loginsiden.
Genererer et tilfældig token i en session og send det med som et hidden input felt i din loginform og kontroller op mod din session.
Tillad timeout fejl ved at tillade 3-5 fejlagtige tokens for derefter at blokere IP'en i et døgn.

Je, det var dumt at forsøge at blande "kapacitet" ind i billedet.

Problemet er, at mit system er "inherently" sårbart overfor brute-force angreb:

Når brugeren registrerer sig, oprettes et "Bruger-iD" (tilfældig 12-cifret int: 100.000.000.000 - 999.999.999.999) som lægges i en cookie - Kommer man til sitet med denne cookie: Læseadgang!
Brugeren kan vælge at beskytte skriveadgangen med et password - eller lade være!
- i bekræftende fald: endnu en cookie som checkes inden hver opdatering af data.

Grunden til denne "åben-dør-login" er, at brugerne kan være helt små børn 3-4 år, så derfor skal login-proceduren være så smertefri som overhovedet muligt = ikke kræve tekstuel-hukommelse.

Min frygt er, at en hacker kan "teste" millioner af potentielle bruger-iD'er på kort tid, og dermed, selvom der ER mange at teste, tilsidst, få adgang.
Derfor ideen om at lægge en kort pause ind før systemet svarer på et kontakt-forsøg.
- Men det nytter jo kun, hvis hun venter på svar fra det forrige forsøg, før hun prøver det næste...

Alternativt: 2 (eller 5!) "iD-cookies" - bare for at øge "udfaldsrummet"

Lav en cookie, som nygeneres med entry for hver sidevisning med et tilfældig token (128 bit sha1, f.eks) og kontroller det op mod databasen?

Ah, én hurdle mere - der vil være flere brugere (browsere) med samme iD-cookie (typisk familier).
- Så hvis jeg nygenererer iD-cookien, så falder alle de andre af (hvis jeg har forstået dig korrekt ?)

Der er vel ikke noget i vejen for at tilknytte mere end et token for hvert bruger id?

Så skal jeg liige forstå:

Ved hver sidevisning, ændres en token, som dels gemmes i db, dels gives til brugeren (i et hidden field).
- ved næste henvendelse skal token'nen fremvises og matche dén i db (?)

Vil det ikke "gå i fisk" utroligt let - hvis brugeren forlader sitet uden at logge ud, f.eks.

Nej, cookieen vil indeholde en unik streng af en art.
Ved hver sidevisning kontrollerer du cookiens indhold op mod databasen:

Utestet...

Jeg tænker lige højt..

Altså gemme det egentlige Bruger-iD bag en "engangs-token".

Det flytter så hackerens gætte-arbejde over på token-cookien i stedet for Bruger-iD'et. Med det aberdabei, at hvis hun gætter rigtigt, så bliver min bruger hægtet helt af - nu er det kun hackeren som kender den aktuelle token - tilgengæld vil brugeren blive opmærksom på at "der er noget galt".. Og det er bedre : )

Plus, selvfølgelig, at en token på 40 hex-tegn er helt enormt meget sværere at "gætte" end en 12-cifret int. Men hackerens udfordring er principielt den samme. Fidusen ved at ændre token hele tiden, er at hackeren ikke længere kan udelukke tokens hun allerede har forsøgt - hun kan dog stadig være heldig at ramme én som er valid (helt vildt absurd usandsynligt heldig)..

Men, efter at have været på som regulær bruger, og SET hvad hun er oppe imod, opgiver hun brute-force-metoden på forhånd : )

Og så er det relativt let at "indkapsle" i en funktion:
$userDataRecord = sesamSesam( $_COOKIE['secret_token'] );

Så skal jeg bare finde en måde at tilknytte nye familiemedlemmer ('s browsere), dvs. tilføje en ekstra token til det samme Bruger-iD...

- Far (smiler og) klikker på "Create Barn" og modtager en særlig URL med den nye token i en parameter, som han "overfører" til den lille ny browser - og vupti: Han er en Rigtig Mand.

Og når Junior (igen!) glemmer sin bærbare i bussen, går Far ind og lukker for Token nr... 19!

Så langt så godt + ekstra bonus at den unikke Bruger-iD aldrig forlader serveren : )

Men risikoen er at kæden falder af, mellem ændring af token i db og opdatering af token-cookie ude hos brugeren - min kode fejler.. nej brugeren lukker sin browser midt i en transaktion. Eller bare at brugeren har systemet åbent i to vinduer.. whatever: Cookie matcher ikke længere token i db!
- Far får mistanke om hackere i nabolaget, og løber ud med øksen... Nogen må gøre noget!!

Måske en lille "rotation" af de seneste 3-5 valide tokens, som man kan falde tilbage på..
- Men det gør det jo noget mere omstændeligt at udstede en ny token (det skal checkes at den ikke allerede findes i 3-5 db-indexes)...
Nej, jeg knalder da bare time() ind foran, så er den garanteret unik.


Det ligner sgu en løsning : D
- skal nok liige sove på det, inden jeg splitter det nuværende ad..

Hej Repox
Jeg er bange for at det går i fisk, når en bruger benytter mange forskellige browsere/PC'er..
- en "rotation" på den seneste håndfuld tokens vil ikke være nok.

Har du en af dine sædvanlige elegante løsninger på det problem ?

Ku' i øvrigt også bruge dit input i en relateret tråd => http://www.eksperten.dk/spm/917652

Der er nok ikke nogen reel elegant løsning på det her.

Som jeg umiddelbart opfatter det, er der egentlig ikke en reel loginprocess, men det er valgfrit om man vil tilknytte et kodeord til sit tilfældigt genererede ID?

Jeg vil mene at det ikke er helt ved siden af at forlange en - eksempelvis - firecifret pin kode til login sammen med sit bruger id. Børn er ret gode til tal - pin koden bør du selv generere.

Så ville det umiddelbart være en bedre idé at gemme bruger id'et i en cookie og således autoudfylde det i login fasen. Når pinkoden er brugt kan du sætte en autologin-cookie som udløber om time()+30 dage.

For at undgå bruteforce-angreb ville det nemmeste absolut være at blokere en IP i en halv time (eller lignende) efter fem fejlslagne forsøg istedet for at blokere bruger id'et.

På den måde kommer du udover token cookien og kan på en sikker måde give den autologin cookie til din bruger på en nem måde.

Sådan bliver det!

I stedet for en pinkode man skal huske, vil jeg dog benytte en kort captcha (3 tal/bogstaver)
- som "holder" i ... 8 timer.

Plus iP-banning (en time) allerede efter første forkerte bruger-iD cookie.
- ingen uskyldige brugere vil (kan) ændre på en cookie jeg har udstedt.
Findes der en bruger-iD cookie, ER den valid - eller også er der ugler i mosen.

Læg et svar (begge to) Point'ene er i uhørt grad fortjent!
40 til repox og 20 til intenz for at afsløre min naivitet : )

Du fik et svar fra mig her.