PHP Login Without MySql

[redman]

http://sourceforge.net/projects/php-login/

Is dit programma aan te raden, is het veilig of is het alleen maar om problemen vragen?

[Dima_2005]

Nee, het is niet veilig. Maar hangt af van het doeleind. Volgens mij is het even onveilig als pak maar password protecten met een .htaccess

Waarom wil je geen Mysql gebruiken?

[ubremoved_539]

Motiveer eens waarom het niet veilig is...

[Dima_2005]

Om te beginnen moet je zeker zijn dat het in orde is. Dus dat je bestanden toevallig niet downloadbaar zijn / van een andere site benaderbaar.
Dan natuurlijk moet je random word wijzigen anders is het gemakkelijk te brute-forcen.
Enfin, geweldige beveiliging is het dus niet,het is te kraken mits wat wil. (net als veel andere login-scripts)

Ik zie ook een potentiele injectie-mogelijkheid / buffer overflow / ...

Maar goed, voor kleinschalig (weinig gevoelige info) gebruik is het goed genoeg, al ben ik van mening dat je beter toch .htaccess beveiliging opzet in dit geval.

[redman]

Dat de php bestanden niet downloadbaar mogen zijn snap ik.
Bruteforce dacht ik op te lossen door CAPTCHA.
Injectie mogelijkheden heb ik nog niet bekeken.

Mijn website is een blog die ik zelf heb geprogrammeerd. (Ik weet het, er zijn veel kant en klare oplossingen)
Draait op een mysql server behalve de login.

Ik heb een tijdje geprogrammeerd maar niet in php en vermits er niet zoveel werk niet meer is aan de blog had ik geen goesting om mijn login gedeelte volledig te herschrijven.

Misschien moet ik dat toch doen?

[Dima_2005]

Voor brute-froce kun je captcha omzeilen door altijd te refreshen met een andere SESSION-cookie van login.

Staat er veel geheims op de blog?
Herschrijven moet niet perse, maar je kunt extra beveiligen door bv. de md5 nogmaals te salten. (eventueel nog een sha1 erbovenop)
Als je met database werkt, moet je ook voorzichtig zijn. Maar kun je dan ook session storen op de server om fraude te voorkomen van de sessions.

Ga je touwens deze login gebruiken om in te loggen om content toe te voegen/te wijzigen?
Vergeet trouwens niet dat je op elke pagina dan gaat moeten nakijken of je ingelogd bent, typische beginnersfout.

[Génicus]

mits de bestanden niet te downloaden zijn lijkt mij dat een veilig script. Gebruik voor de zekerheid wel een wachtwoord dat je zeker nergens anders gebruikt, zelfs geen afgeleide ofzo.
Maar denk eraan dat security bij een volgende webapp aan de basis ligt en niet iets bij te voegen is later, dan maak je bijna zo goed als zeker fouten.

[ubremoved_539]

Ik zie ook een potentiele injectie-mogelijkheid / buffer overflow / ...

Ik zie niet in wat dit met mySQL anders zou zijn (de risico's worden daar alléén maar groter) ?

Maar goed, voor kleinschalig (weinig gevoelige info) gebruik is het goed genoeg

Dat is ook de intentie van het scriptje... het scriptje zou er trouwens haast identiek hetzelfde uitzien maar dan gewoon het paswoord uit een database gaan halen.

[ubremoved_539]

Voor brute-froce kun je captcha omzeilen door altijd te refreshen met een andere SESSION-cookie van login.

Op het moment dat je de captcha te zien krijg is er zelfs nog geen sessie... zie dus ook niet in wat je bedoelt. Welke captcha je te zien krijgt is random at server niveau, dus daar heb je geen impact op... je zal hem dus steeds moeten oplossen (gewoon in je POST wel de captcha referentie salten op een manier dat deze niet herbruikbaar is).

[Dima_2005]

r2504:

Met MYSQL kun je de sessies registreren in de database. Injectie kun je ook gemakkelijker vermijden door myssql_escape_string te gebruiken.
Dus in feite kan client niks meer aan zijn kant prutsen. Het wordt gekoppeld aan een session_ID (wel opletten, die is gevoelig voor man-in-the-middle, dus daar moet je nog een extra beveiliging over gooien met een unieke cookie bv.)

Enfin, alles is hackable, persoonlijk zou ik het niet te erg vertrouwen, maar goed. Zolang je een beetje voorzichtig bent met je coderen en je doet zeker een check van de session elke keer op de juiste manier, ben je RELATIEF veilig volgens mij.

Ik ben misschien een beetje paranoia, maar je kan nooit veilig genoeg zijn, nadat er een site van mij eens gehacked werd, werd ik veel voorzichtiger met beveiliging. (trouwens, dezelfde fout: login/password/hash allemaal client-side bewaard, wat dus gebruteforced)

Op het moment dat je de captcha te zien krijg is er zelfs nog geen sessie... zie dus ook niet in wat je bedoelt. Welke captcha je te zien krijgt is random at server niveau, dus daar heb je geen impact op... je zal hem dus steeds moeten oplossen (gewoon in je POST wel de captcha referentie salten op een manier dat deze niet herbruikbaar is).

Als je naar de pagina gaat met een reeds bestaande session-cookie, krijg je geen login-formulier te zien toch? Je krijgt direct beveiligde deel te zien.

[redman]

Vergeet trouwens niet dat je op elke pagina dan gaat moeten nakijken of je ingelogd bent, typische beginnersfout.

Zo slecht geprogrammeerd is het nu ook niet hoor

[Dima_2005]

Zei ik ook niet, maar je vergeet het toch rap. Weet nog een grote bedrijf had dit eens een paar jaar geleden. Gewoon index2.php ipv index.php et voila, je bent ingelogd

[ubremoved_539]

Als je naar de pagina gaat met een reeds bestaande session-cookie, krijg je geen login-formulier te zien toch? Je krijgt direct beveiligde deel te zien.

Je gaat dus session id's bruteforcen... tja, dat kan je met mySQL ook.

Je opmerkingen zijn terecht... maar ik zie het verschil niet tussen met of zonder database.

[redman]

Als je dus "myssql_escape_string" bij elke SQL string gebruikt, wat ik heb gedaan, ben je dus veilig voor alle soorten SQL injectie?

[Dima_2005]

Ja, maar bij MySQL heb je een sessionID, deze kun je nogmaals extra beveiligen door bv. aan een IP vast te koppellen, laten verallen, altijd vernieuwen aan de hand van tijdstip,...

Even een voorbeeld:
nu:
Je zoekt brute-force de hash, eenmaal je deze hebt kun je altijd inloggen.

Mysql
Je MOET eerst inloggen om je sessionID in de database te krijgen. Dan kijkt het na of de session in de database bestaat of niet/ of deze niet vervalen is/juiste IP.
SessionID wordt ook anders gegenereerd, dus deze is compleet random ipv een vaste hash.
Dus je hebt nog geen juiste session-cookie die je toegang verleent, want je moet eerst username+password ontdekken. En hier kun je dan nog eens extra beveiligen door x aantal verkeerde logins, captachas enz.

Snap je het verschil? Je hebt een heel extra niveau van beveiliging omdat je sessie op de server bewaard wordt. Enige risico is als je inlogt met een man-in-the-middle / sniffer, dat je dan de juiste IP en sessionID hebt die je dan kunt spoofen.

Als je dus "myssql_escape_string" bij elke SQL string gebruikt, wat ik heb gedaan, ben je dus veilig voor alle soorten SQL injectie?

Absoluut veilig niet, maar voor 95% wel ja. Dit is goed genoeg, tenzij je met militaire info werkt

[ubremoved_539]

Ja, maar bij MySQL heb je een sessionID, deze kun je nogmaals extra beveiligen door bv. aan een IP vast te koppellen, laten verallen, altijd vernieuwen aan de hand van tijdstip,...

Was even in Java aan het denken... kent PHP het concept niet van een application context waarin je dingen kan stockeren ?

[meon]

Herschrijven moet niet perse, maar je kunt extra beveiligen door bv. de md5 nogmaals te salten. (eventueel nog een sha1 erbovenop)

Hashes hashen VERKLEINT de entropie en maakt het dus MINDER veilig.
Wat je moet doen is een SALT toevoegen; dat helpt tegen rainbow tables, zelfs bij MD5 (waar je relatief snel collisions kan creëren ondertussen)

Was even in Java aan het denken... kent PHP het concept niet van een application context waarin je dingen kan stockeren ?

Ik vermoed dat $_SESSION daar het meeste op lijkt... Is een grote variabele, bijgehouden op server on disk waar ge alles uit de sessie in kunt stockeren. Aangezien PHP dit gewoon via een cookie bijhoudt aan de client-kant bestaat de kans op cookie theft, dus moet je de validatie van die gegevens nog elders bijhouden (bijvoorbeeld in DB).

Als je dus "myssql_escape_string" bij elke SQL string gebruikt, wat ik heb gedaan, ben je dus veilig voor alle soorten SQL injectie?

Gebruik eens prepared statements in plaats van een SQL-commando op te bouwen? http://php.net/manual/en/mysqli.prepare.php

[Dima_2005]

Dat bedoelde ik trouwens: bv. sha1(md5().$salt).$salt2

[meon]

Nah, da's weinig zinvol. Gebruik dan gewoon een zwaarder hashingmechanisme ipv het uzelf complex te maken:

Code: Selecteer alles

hash('sha256',$_POST['pass'].APP_SALT)