[php] extra security voor weblogin

[RSD]

Zijn er toevallig mensen die extra security items kunnen bedenken voor een weblogin. Ik heb tweakers afgezocht en datgene wat er te vinden was zoals referer check en header checks toegevoegd. Nu vroeg ik me af of er nog meer is, of is dit het einde van de security mbt tot weblogin?

[SWINX]

tja... t meeste is toch wel te faken

Maar dat zijn idd dingen waar je op kunt/moet letten

[DRvDijk]

Ik heb een tabel fakelogins. Daarin staat een UserID en een MD5-hash van een random gegenereerd password. De gebruiker komt (ingelogged) op de pagina. Het PHP script checkt of de UserID - MD5-hash combinatie uit de cookie klopt met een entry in de fakelogins table. Zo ja: Maak een nieuwe random pass, update ouwe MD5-hash in het cookie én in de database. De user gaat verder naar een volgende pagina, waar dit hele verhaal weer opnieuw gecontroleerd wordt. Zo nee: verwijder cookie

Op deze manier kan een user op plek 1 inloggen, op plek 2 inloggen, op plek 1 weer uitloggen en op plek 2 nog ingelogd zijn. Ook kan een user kiezen om globaal uitgelogd te worden (gewoon alle entry's in de fakelogin-table met UserID = die-en-die wissen), alike tweakers.net.
Admins kunnen ook kijken wie er ingelogd is, en die mensen uitloggen (mn handig bij het deactivaten van accounts van ingelogde users).

Hopend dat het duidelijk is.. Commentaar: welkom

[ACM]

SSL-certificaten aanleggen voor al je users...

Wedervraag: Heb je het ook echt nodig? Een goed beveiligde site heeft er vaak weinig extra baat bij dat je dat laatste beetje veiligheid eruit knijpt.

[DRvDijk]

SSL-certificaten.. Da's weer es een leuke zoekterm Ik ga het eens bekijken. Is da't heavily overdone voor een "normale" site (lees een forum, een gastenboek, een members-only pageje)?

[ACM]

client-side certificates is vreselijk overdone in veel gevallen

Vandaar ook mijn wedervraag

[Dennis]

Ok. Nu hebben we 2 topics...

En het antwoord is $_GET & $_SERVER['HTTP_REFERER'] zoals ook in je andere topic al is genoemd...

[Glimi]

Op woensdag 22 mei 2002 01:13 schreef elviver het volgende:
SSL-certificaten.. Da's weer es een leuke zoekterm Ik ga het eens bekijken. Is da't heavily overdone voor een "normale" site (lees een forum, een gastenboek, een members-only pageje)?

Heeel!heeel!heeel!heeel! erg overdone. Ik moet dan een certificaat van jou (door jou gesigned) gaan instellen in m'n browser, zodat jij weet dat ik ik ben. En dit moet je voor elke (welkome?) bezoker aan gaan maken. Echter jij zal wel een signed certificate moeten hebben anders krijg ik een warning van m'n browser. En dat kost veeeeeeeeeeeeeeeeeeeeel geld. Zulke dingen gebruikt de rabobank bij betalen over het internet....

Op dinsdag 21 mei 2002 23:22 schreef RSD het volgende:
Zijn er toevallig mensen die extra security items kunnen bedenken voor een weblogin. Ik heb tweakers afgezocht en datgene wat er te vinden was zoals referer check en header checks toegevoegd. Nu vroeg ik me af of er nog meer is, of is dit het einde van de security mbt tot weblogin?

Nee. Zorg er gewoon voor dat elke user een goed password heeft en dat deze niet onversleuteld verzonden wordt (als je daar zoveel waarde aan hecht.) Dan check je op elke pagina of een variabele in de sessie geset is, die alleen geset wordt op de loginpagina.

Zou voldoende moeten zijn voor de meeste..... En als het dat niet is, dan kun je beter een applicatie schrijven, een server opzetten en de applicatie met de server laten communiceren. Dan geeft je de applicatie alleen aan de mensen die het moeten hebben. Want als het echt veilig moet, moet je het gewoon niet aan internet hangen.

[RSD]

en als het over hele kleine geldtransacties gaat?? dan kun je denken aan 0.1 euro cent ofzo.. dat ze hacken tot daaraan toe, maar ze mogen de boel niet kunnen ophogen. Hoe is dit te realiseren en ze mogen ook niet onder geen bedwing andersmans account kunnen gebruiken. Ik ben een soort spelletje aan het maken. Je kan denken aan het spelen van een spelletje, wat je voor de lol doet, maar er moet wel iets ophet spel staan, niet teveel natuurlijk, maar just for fun. Het is absoluut niet commercieel bedoeld. Want dat zal me toch nooit lukken en daarvoor kan ik niet goed genoeg programmeren om iets te maken. Dus zoals rabobank enzo.. maar het moet wel veilig genoeg zijn.Zodat ik niet opeens met dikke schulden rondloop.

[Dennis]

RSD:
en als het over hele kleine geldtransacties gaat?? dan kun je denken aan 0.1 euro cent ofzo.. dat ze hacken tot daaraan toe, maar ze mogen de boel niet kunnen ophogen. Hoe is dit te realiseren en ze mogen ook niet onder geen bedwing andersmans account kunnen gebruiken. Ik ben een soort spelletje aan het maken. Je kan denken aan het spelen van een spelletje, wat je voor de lol doet, maar er moet wel iets ophet spel staan, niet teveel natuurlijk, maar just for fun. Het is absoluut niet commercieel bedoeld. Want dat zal me toch nooit lukken en daarvoor kan ik niet goed genoeg programmeren om iets te maken. Dus zoals rabobank enzo.. maar het moet wel veilig genoeg zijn.Zodat ik niet opeens met dikke schulden rondloop.

0.1 eurocent

En wat wil je nou eigenlijk? Er lopen nu 4 topics van je en als je die bij elkaar optelt komt het erop neer dat we jouw hele applicatie moeten maken .

[DRvDijk]

Op woensdag 22 mei 2002 07:46 schreef ddc het volgende:
En het antwoord is $_GET & $_SERVER['HTTP_REFERER'] zoals ook in je andere topic al is genoemd...

Die heeft ie dus al..

SSL-certificaten wordt het duz ook niet, daar betaal je dus véél te veel geld voor. RSD: Had je al naar me verhaal gekeken? Met random password in de db opslaan?

[SWINX]

Eigenlijk heeft dcc best wel gelijk

[RSD]

jep, dat deed ik al, ik wil de code wel posten, maardan wordt het topic weer gesloten.. btw is ereen limiet op het aantal posts dan ??? En btw, je moet nix, je mag alles.. maar nee dat was niet mijn bedoeling, ik kom alleen zo af en toe wat probs tegen en die zie ik graag opgelost worden, en als ik jij er niet was (DCK) over die referer, dan zat ik er nu nog mee te kloten.

[Dennis]

RSD:
en als ik jij er niet was (DCK) over die referer, dan zat ik er nu nog mee te kloten.

Volgens mij heet ik ddc Of bedoelde je iets anders?

[RSD]

ik bedoelde jou ja, maar verwar je nogal eens! met D2K

[leonardo1504]

Referer is NIET safe. Dit is gewoon een header die door de client wordt gemaakt en meegestuurd met het request. Kan ten eerste dus gefaked worden en is ten tweede niet required.

[Dennis]

leonardo1504:
Referer is NIET safe. Dit is gewoon een header die door de client wordt gemaakt en meegestuurd met het request. Kan ten eerste dus gefaked worden en is ten tweede niet required.

Niet required. Dat klopt . Daarom kan zo'n stom Norton programma hem ook "disablen".

Maargoed, de gemiddelde gebruiker weet niet hoe die (zonder zo'n Norton troepprogramma) zo'n referer eruit moet halen, dus dat scheelt weer.

In theorie heb je hartstikke gelijk, in praktijk nog steeds maar wel iets minder dus . Overigens is al eens een keer een discussie geweest over referers, en onder normale omstandigheden wordt het afgeraden ivm compatibiliteit, wil je optimale veiligheid (en Norton software verbieden ) kun je er natuurlijk wél op controleren .

[RSD]

en waarpom is norton troep?? heb je betere suggesties dan voor windows beveiligen.. dan zit ik helemaal verkeerd, maar ja.. een verantwoorde beveiliging bestaat er dus niet.

[Dennis]

RSD:
en waarpom is norton troep?? heb je betere suggesties dan voor windows beveiligen.. dan zit ik helemaal verkeerd, maar ja.. een verantwoorde beveiliging bestaat er dus niet.

Voordat mensen daar weer over vallen, dat Norton troep is is mijn mening

Maarre een goed alternatief is ZoneAlarm

[DRvDijk]

RSD: Als je dat al doet zoiets, met een random pass in je cookie dat telkens veranderd.. Dan is het toch al redelijk secure? Ik kan me iig niet voorstellen dat iemand zonder mysql-toegang op mijn mysql-server die random passes kan raden en in zijn cookie kan frotten! Wat is dan nog het enige onsecure? Juist, dat een user de ander's user zijn pass weet

[justmental]

Ik snap het niet helemaal.
Wat wil je voorkomen met extra checks?

Bij mezelf check ik de referer enzo niet.

[RSD]

Dat mensen gaan lopen kutten met allemaal scripts die ze uitvoeren vanaf een andere server.. ik wil het ze onmogelijk maken omdat te doen. MNaar er zijn wel weertrucs om dat te omzeilen.

[justmental]

Op woensdag 22 mei 2002 11:15 schreef RSD het volgende:
Dat mensen gaan lopen kutten met allemaal scripts die ze uitvoeren vanaf een andere server.. ik wil het ze onmogelijk maken omdat te doen. MNaar er zijn wel weertrucs om dat te omzeilen.

Wat zouden ze dan moeten kunnen doen?
Je gastenboek volspammen met een script ofzo?
Dat zouden ze altijd nog met een keyboard macro tooltje kunnen doen ofzo.

Je moet gewoon zorgen dat je applicatie goed in elkaar zit.
Dus check of er 2x hetzelfde achter elkaar gepost wordt.
Of check of er meer dan 10 posts achter elkaar van hetzelfde ip komen.
Dat soort dingen.

[Vulpecula]

Zou ook de sleep(); function erin verwerken. Zodat er niet snel kan worden gebrute forced.

[RSD]

datzijn tips waar ik wataan heb

[Dennis]

RSD:
datzijn tips waar ik wataan heb

Dat betwijfel ik. Je gaat toch niet je scripts met opzet langzamer maken

[creative8500]

Op woensdag 22 mei 2002 11:23 schreef frankschers het volgende:
Zou ook de sleep(); function erin verwerken. Zodat er niet snel kan worden gebrute forced.

Kun je dat wat meer uitleggen? I don't really get it.

[RSD]

nope, da niet, maar is wel handig die van dat IP adres als ze te vaal achter elkaar proberen

[Vulpecula]

Op woensdag 22 mei 2002 11:33 schreef cREATiVe8500 het volgende:

[..]

Kun je dat wat meer uitleggen? I don't really get it.

Kijk eens op http://www.php.net/sleep.

Als laat je het script 1 seconde wachten. Met brute force wordt al in 1 seconde zoveel gebruikersnamen gekozen. 1 seconde kan een bezoeker toch wel wachten? Je kunt ook usleep(); gebruiken dat is in milliseconde. Gebruik het ook alleen wanneer de gebruikersnaam en wachtwoord verkeerd is. Dan kunnen mensen die wel goed ingelogd worden direct door.

[justmental]

Op woensdag 22 mei 2002 12:27 schreef frankschers het volgende:
Kijk eens op http://www.php.net/sleep.

Als laat je het script 1 seconde wachten. Met brute force wordt al in 1 seconde zoveel gebruikersnamen gekozen. 1 seconde kan een bezoeker toch wel wachten? Je kunt ook usleep(); gebruiken dat is in milliseconde.

Dat heeft toch geen zin?
Je kunt toch met meerdere threads brute forcen?

[RSD]

Wat is een thread? Stomme vraag misschien?

mn keyboard is fucked up

[justmental]

Op woensdag 22 mei 2002 12:54 schreef RSD het volgende:
Wat is een thread? Stomme vraag misschien?

mn keyboard is fucked up

Een soort instantie van een programma-runtime.
Je kunt het zien zoals je meerdere browser windows open kunt hebben.
Zo zou je een bruteforce programmaatje meerdere keren op kunnen starten.
Dan zou die sleep z'n functie verliezen.

Bij mijn eigen site ga ik iets inbouwen dat bij 3x fout password van een bepaald ip, dat ip 5 minuten niet meer kan inloggen.
Bij 15x dan 1 dag ofzo.
Lijkt me beter dan zo'n sleep.

[RSD]

dat is zeker leuk.. maar dat wordt alweer een stukej complexer.. ga je dan de tijd op slaan dat ze weer inmogen loggen ofzo?

[kaandorp]

Zit dit topic aandachtig te lezen en vraag me even iets af.
Ik heb voor user-authenticatie gewoon een script gemaakt die in de database checked of iemand toegang heeft, ja of nee.
Als hij toegang heeft wordt er een sessievariabele gevuld met zijn username. Een functie IsLoggedIn() controleert vervolgens of deze persoon ingelogd, en dus geauthoriseerd is.

Is dit dan veilig, of kan zoiets heel simpel worden omzeild.

[justmental]

Op woensdag 22 mei 2002 13:04 schreef RSD het volgende:
dat is zeker leuk.. maar dat wordt alweer een stukej complexer.. ga je dan de tijd op slaan dat ze weer inmogen loggen ofzo?

Dat stuk zit er bij mij al in, voor banregulering ed.

[kaandorp]

Op woensdag 22 mei 2002 13:04 schreef RSD het volgende:
dat is zeker leuk.. maar dat wordt alweer een stukej complexer.. ga je dan de tijd op slaan dat ze weer inmogen loggen ofzo?

Je zet gewoon een datumveld bij de user. Als hij 15 keer verkeerd heeft ingelogd zet je deze datum een dag verder. Bij het inloggen controleer je dan of de huidige datum hoger is dan het datumveld.

[Dennis]

kaandorp:
Zit dit topic aandachtig te lezen en vraag me even iets af.
Ik heb voor user-authenticatie gewoon een script gemaakt die in de database checked of iemand toegang heeft, ja of nee.
Als hij toegang heeft wordt er een sessievariabele gevuld met zijn username. Een functie IsLoggedIn() controleert vervolgens of deze persoon ingelogd, en dus geauthoriseerd is.

Is dit dan veilig, of kan zoiets heel simpel worden omzeild.

Dat is gewoon veilig, maar de gebruiker wil dat je persé vanaf zijn site een bericht plaatst bijvoorbeeld.

Kijk, ik kan hier waarschijnlijk een link maken zoiets als dit:

http://gathering.tweakers.net/postreply.php?Submit=Verstuur&message=Hmmmm,%20slecht%20van%20Topix

De topicstarter wil dat soort dingen en spammen voorkomen. Tevens wil hij niet dat je vanaf andere fora zo'n linkje kan maken als hierboven, en dus referer check.

[RSD]

maar bij T.net doen ze geen referer check dan, want als ik norton aan heb staan, werkt het nog steeds allemaal.. zijn er dan andere manieren...? En ja dat gevoel had ik ook bij het lezen van het stuk text van ACM. Dat een easy login script makkelijk te omzeilen is en ik las laatst ook al iets dat md5 niet zo veilig is. Op phpbuilder.com las ik dat.. kereltje had een functie gemaakt en deed iets van 2.3 miljoen combinaties, dit is nietvoldoende natuurlijk, voor brute force om de md5 te gokken. Maar als je ervan uitgaat dat een passwoord uit 8 tekens bestaat of minder, en dit doe je tot de macht het aantal mogelijke soorten characters, dan en hier gooi je de md5 omheen en dan vergelijke, zo kom jenog aan het paswoord. Dus als je md5 hebt van iemand , dan is dit om te toveren tot een password.

[justmental]

Op woensdag 22 mei 2002 13:40 schreef RSD het volgende:
Dus als je md5 hebt van iemand , dan is dit om te toveren tot een password.

Hoe zou je aan een md5 hash van iemand z'n password moeten komen?
Die hou je natuurlijk server side.
md5 is daar alleen handig om het password niet terug herleidbaar op te slaan.

[RSD]

die staat in iemands database die md('paswoord') als je daar toegang tot hebt is het volgens dat kereltje een fluitje

[justmental]

Op woensdag 22 mei 2002 13:55 schreef RSD het volgende:
die staat in iemands database die md('paswoord') als je daar toegang tot hebt is het volgens dat kereltje een fluitje

Als je al bij de database kan, waarom zou je dan moeilijk doen met een md5?
Kees hoeft ook geen wachtwoorden te hacken om alle private fora te lezen.

[Dennis]

RSD:
die staat in iemands database die md('paswoord') als je daar toegang tot hebt is het volgens dat kereltje een fluitje

1 woord: bullshit

[RSD]

het zijn niet mijn woorden .. maar kan me er wel iets bijvoorstellen.. want je gokt in principe het paswoord, door 2 milj. mogelijkheden. en het md5('paswoord') is altijd hetzelfde. Dus als jij beweert dat je md5 niet kan kraken.. lijkt me wel alleen door het omgekeerd te doen, je gokt het paswoord en gooit er een md5 overheen en vergelijkt het met de md5(paswoord) die je al hebt

[Dennis]

RSD:
het zijn niet mijn woorden .. maar kan me er wel iets bijvoorstellen.. want je gokt in principe het paswoord, door 2 milj. mogelijkheden. en het md5('paswoord') is altijd hetzelfde. Dus als jij beweert dat je md5 niet kan kraken.. lijkt me wel alleen door het omgekeerd te doen, je gokt het paswoord en gooit er een md5 overheen en vergelijkt het met de md5(paswoord) die je al hebt

MD5 is idd niet te kraken, alleen via andersom werken (zoals je later ook aangeeft).

[RSD]

Dus hoe vaker je md5 doet des te moeilijker wordthet om het omgedraaid te kraken is?? want md5(md5(paswoord)) , maakt van bijv 6 characters, iets van 32 characters en om die 32 terug te halen is weer moeilijker dan 5..

[Dennis]

RSD:
Dus hoe vaker je md5 doet des te moeilijker wordthet om het omgedraaid te kraken is?? want md5(md5(paswoord)) , maakt van bijv 6 characters, iets van 32 characters en om die 32 terug te halen is weer moeilijker dan 5..

WAT WIL JE NOU????
Sjonge jonge, je bent echt helemaal fout bezig
Alleen het denken al...

[D2k]

md5 is een onomkeerbaar iets hoor
dus hashes hashen is mega zinloos
ga je eens in de materie verdiepen ajb

[RSD]

jaja ik zeg ook maarwat

[LuCarD]

md5 geeft altijd een string van 32 characters terug.
Als een string van 1000 characters aan de md5 geeft, dan geeft hij nogsteeds 32 characters terug.

Vanuit die 32 characters is onmogelijk om die string van 1000 characters weer te achter halen. Als dat wel zo zou zijn heb je de beste compressie algoritme gevonden die er is.

[RSD]

ik heb het niet over 1000, maar over 6 om die backwards te gokken en ik bedoel dus als je 2x doet, moet je 32 karakters gokken en anders 6, en ja ik weet het gaat nergens over!

Als we nu eens stellen dat iemand een sessie id kan gokken, wat dan? Heeft hij dan beschikking over alle waardes die in de sessie zijn opgeslagen?

[DRvDijk]

Op zich lijkt het me geen slecht idee hoor, md5 van een md5 hash.. Inderdaad om het gokken van passwords kleiner dan 7 tekens..
Pass met 6 tekens (A-Za-z0-9): 1.759452407304813269e+48 mogelijkheden
Pass met 8 tekens: 6.7633350536797022084024e+51 mogelijkheden..
Pass met 32 tekens: 2.0859248397665137523388e+93 mogelijkheden.. Dan ga ik toch voor dat laatste! Da's bepaald moeilijker te raden
_{Gokje: a72jh1bn3ma08fe2lmna641nd25ah88 .. goed?}

[justmental]

Wakie wakie!
Waarom zou je een md5 hash van een md5 hash maken?
Je maakt alleen de kans op een toevalstreffer bij password guessing groter.
Je moet gewoon zorgen dat die md5 hashes alleen server side aanwezig zijn en dat de gebruiker er niet bij kan.

[Dennis]

RSD:
Als we nu eens stellen dat iemand een sessie id kan gokken, wat dan? Heeft hij dan beschikking over alle waardes die in de sessie zijn opgeslagen?

Je kan idd zo'n id gokken ja. Als je nu eens session-id én user-id opslaat clientside, die kans is zo verrekte klein dat je die goed bij elkaar gokt, dat kun je wel verwaarlozen.

[DRvDijk]

Op woensdag 22 mei 2002 15:38 schreef justmental het volgende:
Wakie wakie!
Waarom zou je een md5 hash van een md5 hash maken?
Je maakt alleen de kans op een toevalstreffer bij password guessing groter.

Groter?!?!? Juist kleiner toch???

Je moet gewoon zorgen dat die md5 hashes alleen server side aanwezig zijn en dat de gebruiker er niet bij kan.

Ik heb een client-side MD5-hash van een password.. Maar die is maar 1 keer te gebruiken.. Zie verhaal hierboven (3e post ofzo?)

[justmental]

Op woensdag 22 mei 2002 15:43 schreef elviver het volgende:
Groter?!?!? Juist kleiner toch???

Bij een hash functie verlies je informatie.
Bijvoorbeeld 10 verschillende passwords kunnen dezelfde hash hebben.
Als je die hash nog een keer hashed dan kunnen 100 veschillende passwords dezelfde hash van hash hebben.

Ik heb een client-side MD5-hash van een password.. Maar die is maar 1 keer te gebruiken.. Zie verhaal hierboven (3e post ofzo?)

Waarom zou je dat die identificatie aan de client zijde een hash van een password laten zijn?
Ik zet een 60 chars groot random id in m'n cookie.
Deze kun je server side nog koppelen aan het ip adres voor extra veiligheid.

Zo is er niets password gerelateerds aanwezig aan de client zijde.

Let wel dat sessie kaping dan nog steeds mogelijk zijn, maar dat heeft ACM al mooi besproken in zijn stuk over beveiliging van websites.

[creative8500]

Op woensdag 22 mei 2002 12:59 schreef justmental het volgende:

[..]

Een soort instantie van een programma-runtime.
Je kunt het zien zoals je meerdere browser windows open kunt hebben.
Zo zou je een bruteforce programmaatje meerdere keren op kunnen starten.
Dan zou die sleep z'n functie verliezen.

Bij mijn eigen site ga ik iets inbouwen dat bij 3x fout password van een bepaald ip, dat ip 5 minuten niet meer kan inloggen.
Bij 15x dan 1 dag ofzo.
Lijkt me beter dan zo'n sleep.

Op woensdag 22 mei 2002 12:27 schreef frankschers het volgende:

[..]

Kijk eens op http://www.php.net/sleep.

Als laat je het script 1 seconde wachten. Met brute force wordt al in 1 seconde zoveel gebruikersnamen gekozen. 1 seconde kan een bezoeker toch wel wachten? Je kunt ook usleep(); gebruiken dat is in milliseconde. Gebruik het ook alleen wanneer de gebruikersnaam en wachtwoord verkeerd is. Dan kunnen mensen die wel goed ingelogd worden direct door.

Thx, both of you! Ik ga beide zekers bij m'n loginscript toevoegen Veel dank!
edit: typo - beiden

[DRvDijk]

Op woensdag 22 mei 2002 15:48 schreef justmental het volgende:
Waarom zou je dat die identificatie aan de client zijde een hash van een password laten zijn?
Ik zet een 60 chars groot random id in m'n cookie.
Deze kun je server side nog koppelen aan het ip adres voor extra veiligheid.

Ja, hoeft niet per ce pass te zijn idd.. gewoon random, en bij mij is dat dan ff door dm5() heeb gehaald.. Maar aan een IP koppelen? Neeij, toch maar niet.. Iemand logd in, hangt zijn modem op (inbellers zijn bijna uitgestorven, en dus beschermd ) en belt ergens anders in.. Dan is ie niet meer ingelogd..

Zo is er niets password gerelateerds aanwezig aan de client zijde.

Is er bij mij in princiepe ook niet..

Let wel dat sessie kaping dan nog steeds mogelijk zijn, maar dat heeft ACM al mooi besproken in zijn stuk over beveiliging van websites.

Jah, iemand kan gewoon het cookietje kopieren, en dan is die persoon op die usernaam ingelogd, en de gene van wie de cooke was uitgelogd. De originele eigenaar krijgt een msg van "cookie corrupted!", en wordt geadviseert in te loggen en ff een global logout te doen. Een nieuw password setten kan, maar is niet nodig, aangezien die nooit bij de client is geweest
Maar ACM stuk over beveiliging? Lezen!_{Link toevallig?}

[Verwijderd]

- Om brute force hacking tegen te gaan zou ik als eerste een sleep(3) uitvoeren alvorens je ze een nieuwe kans geeft om in te loggen. Op die manier is de lol er voor hun snel af.

- Ik heb ook wel eens met GD een plaatje met een random getal (1234 ofzo) laten zien met de vraag of ze die even in wilden kloppen.
Dit laatste was voor de mensen die wel een password hadden maar constant met scripts inlogde om alle informatie van de site te leechen.

- Om verspreiding van usernames and passwords tegen te gaan kun je in je member sectie een scriptje met SSI laten starten elke keer als daar een member langskomt. Dit script slaat dan z'n IP nummer en z'n membernaam.
Komt hij per dag vanaf meer dan xx verschillende IP nummers dan block ik z'n userid.

[justmental]

Op woensdag 22 mei 2002 15:54 schreef elviver het volgende:
Maar ACM stuk over beveiliging? Lezen!_{Link toevallig?}

Dat stuk is inmiddels in de P&W faq opgenomen.

[D2k]

Op woensdag 22 mei 2002 16:29 schreef justmental het volgende:

[..]

Dat stuk is inmiddels in de P&W faq opgenomen.

http://gathering.tweakers.net/forum/list_messages/392390/#beveiliging

grmbl zal nog es veeeeeeeeeel moeite don de faq te updaten

_{believe dat was weer vechten met topix:(}

[RSD]

Als we de veiligheid van een website nu eens vergelijken met de veiligheid van een vliegtuig. Bij vliegtuigen gaat het alsvolgt. Een vliegtuig heeft een bepaalde levensduur. Deze levensduur wordt voornamelijk gemeten in starts en landingen, omdat op dat moment de zwaarste belastingen optreden. Zal de kans dat er hier wat fout gaat ook het grootst zijn. Een vliegtuig is hier dus op gedimensioneerd. Echter het is niet onvermijdelijk dat een vliegtuig een crash maakt.

Uit berekeningen, moet blijken dat de kans dat een failure optreedt van een bepaalde grote is. Deze kans is zo dat hij 1 failure mag hebben in bijv. 80.000 starts en landingen. Aangezien vliegtuigen nogal veilig zijn, zou een website ook op deze manier van denken gedimensioneerd moeten worden. Als we er nu vanuit gaan dat er zoveel mensen internet hebben en er zijn zoveel hackers in de wereld. Dan moet je dit vergelijken met het aantal bezoekers dat je op je site hebt staan. Hieruit kun je dan het aantal hack-aanvallen dat jouw site zou kunnen treffen uithalen. Als je dit weet kun je op deze manier de benodigde beveiliging voor je website bepalen... is dit niet een goed idee?

[RSD]

Vind niemand dit een goed idee

[LuCarD]

Op woensdag 22 mei 2002 20:24 schreef RSD het volgende:
Als we de veiligheid van een website nu eens vergelijken met de veiligheid van een vliegtuig. Bij vliegtuigen gaat het alsvolgt. Een vliegtuig heeft een bepaalde levensduur. Deze levensduur wordt voornamelijk gemeten in starts en landingen, omdat op dat moment de zwaarste belastingen optreden. Zal de kans dat er hier wat fout gaat ook het grootst zijn. Een vliegtuig is hier dus op gedimensioneerd. Echter het is niet onvermijdelijk dat een vliegtuig een crash maakt.

Uit berekeningen, moet blijken dat de kans dat een failure optreedt van een bepaalde grote is. Deze kans is zo dat hij 1 failure mag hebben in bijv. 80.000 starts en landingen. Aangezien vliegtuigen nogal veilig zijn, zou een website ook op deze manier van denken gedimensioneerd moeten worden. Als we er nu vanuit gaan dat er zoveel mensen internet hebben en er zijn zoveel hackers in de wereld. Dan moet je dit vergelijken met het aantal bezoekers dat je op je site hebt staan. Hieruit kun je dan het aantal hack-aanvallen dat jouw site zou kunnen treffen uithalen. Als je dit weet kun je op deze manier de benodigde beveiliging voor je website bepalen... is dit niet een goed idee?

Wat je dus bedoelt is een risico analyse houden. En aan de hand daarvan of je het risico: voorkomt, verzekerd of negeert?

Maar dat is meer een management beslissing en niet een programmeers beslissing.

[RSD]

hmmzzz.. bij het inloggen op mijn site, gebruik ik geen cookies, maar dus wel sessies. Bij elke poging om in te loggen stuur ik een sessieid mee. Dit meesturen, gebeurt via een POST(via form) of via een GET (via url). Als ik nu het inlogform voor me heb en ik geef via url de mee dat bijv het id=0 en ik log dan in met het goede paswoord en de goede gebruikersnaam, dan logt hij in. Maar het sessieid is dan dus 0. Hoe kan ik dit voorkomen. Ik wil dus niet dat mensen een eigen id kunnen zetten waarop hij de boel registreert. Hoe is dit te voorkomen. Hebben meer mensen hier last van. Tevens als ik inlog met bijv het id=0 en ik sluit mn browser af en ik ga dan weer naar de inlogpagina en geef het id=0 mee, dan is hij automatisch ingelogt. Ik dacht dat als je je browser afsluit en erna weer opstart dat dan die id niet meer geldig is. Dit is dus wel zo, wat is hier tegen te doen???

[WouZz]

Gast, ga eens wat lezen over sessions enzo.. Check www.phpfreakz.nl of www.phpbuilder.com voor wat leuke tutorials.. Want volgens mij snap je er nog niks van begrijp je het nog niet helemaal..

[RSD]

jawel hoor, begin het al aardig door te krijgen, maar het feit is dus dat ik geen cookies mag gebruiken. Als dat wel zo was, was het een stuk simpeler. En afkraken is niet zo moeilijk, iemand helpen is een kunst!

[Glimi]

Op donderdag 23 mei 2002 22:28 schreef RSD het volgende:
[...]. En afkraken is niet zo moeilijk, iemand helpen is een kunst!

Ik wil niet heeeeeel lullig doen hoor, maar zoeken is ook een kunst

[RSD]

Ja dat is het zeker, zoeken is voor gevorderden

[WouZz]

Op donderdag 23 mei 2002 22:28 schreef RSD het volgende:
jawel hoor, begin het al aardig door te krijgen, maar het feit is dus dat ik geen cookies mag gebruiken. Als dat wel zo was, was het een stuk simpeler. En afkraken is niet zo moeilijk, iemand helpen is een kunst!

Ik bedoel alleen dat als je je een beetje in de stof verdiept zou hebben, het je allemaal een stuk duidelijker zou worden. Zo zou je dan ook weten dat sessions meestal gebruik maken van cookies. En als je zonder sessions wil werken kan dat ook, maar dat moet je wel opletten hoe en wat je in die cookie opslaat...

[RSD]

ik wil dus GEEN cookies gebruiken, maar ALLEEN sessies. Goed lezen zit ik er ook niet meer in tegenwoordig

Hij doet dus het volgende als ik op de login page kom en ik geef een id=0 mee.

PHP:

<?$id=0;session_name('id);session_start();//code en checks?><input type="hidden" name="<?echo $session_name?>" value="<?echo $session_id;?>">?>

Als ik hier de bron van bekijk, staat er name="id" value="0".. snap dat niet eerlijk gezegd. Hij registreerd dus meteen al..

[WouZz]

Op donderdag 23 mei 2002 22:51 schreef RSD het volgende:
ik wil dus GEEN cookies gebruiken, maar ALLEEN sessies. Goed lezen zit ik er ook niet meer in tegenwoordig

As the manual says:

Session handling functions

Session support in PHP consists of a way to preserve certain data across subsequent accesses. This enables you to build more customized applications and increase the appeal of your web site.

If you are familiar with the session management of PHPLIB, you will notice that some concepts are similar to PHP's session support.

A visitor accessing your web site is assigned an unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.

The session support allows you to register arbitrary numbers of variables to be preserved across requests. When a visitor accesses your site, PHP will check automatically (if session.auto_start is set to 1) or on your request (explicitly through session_start() or implicitly through session_register()) whether a specific session id has been sent with the request. If this is the case, the prior saved environment is recreated.

[RSD]

en nu in het Nederlands

Ja ok, dat stukje ken ik, maar er staat nergens dat als ik Id via url meegeef en erna session_name('id'); doe hij als id de waarde nul toekend aan de session_id

[justmental]

Misschien heeft het er niks mee te maken, maar in dat stukje php wat hierboven staat: sassion_name('id);
Lijkt me een beetje raar qua quotjes.

[Dennis]

Feit dat je cruciale variabelen NIET afvangt met specifiek $_GET of $_POST zegt ook al genoeg

[RSD]

Is een IP-check, dus een check zoiets als:

if ($_SERVER['REMOTE_ADDR']=='124.234.21.23') {
login=true;
} else {
;login=false;
}

is dat een beetje veilig, dus veilig genoeg om mensen mee in te laten loggen?
We gaan ervan uit dat de hele groep achter dat ip adres zit en alleen die mensen met dat ip adres mogen gebruik maken van de site, de rest niet. Mijn vraag is dus, is dit makkelijk te faken of niet?

[WouZz]

Voor IP spoofing is wel wat meer nodig dan even een cookie faken.. En bij de meeste ISP's is het zelfs niet eens mogelijk.. Dus wat dat betreft is een IP check vele malen veiliger dan een cookie check..