[authentication samen maken]+php->mysql functies verleerd
Quote:
Dat is niet helemaal waar, in de meeste installaties zal pdo zelf wel geactiveerd zijn, maar zul je de betreffende drivers vaak nog wel moeten activeren. Controleer dus ook of je host deze drivers wel geinstalleerd heeft en zo niet, vraag of ze die willen activeren.Verder hoef je niks in je php.ini te doen want in PHP5 staan standaard alle pdo extenties enabled
Probleem is dat pgsql niet overal wordt ondersteund(tenminste niet zo veel als mysql).
edit:
Was mij voor :). Ik wou preciesdat vragen en jij geeft mij daar dus gelijk antwoord op :).
@Thijs:
Ik gebruik nu een usb stick om op te programmeren enz. Ik gebruik om alles te testen 'Usb Webserver v7.00'. Niet echt een server, maar voldoende om mee te testen enz. Maar daar blijkt dus dat er geen PDO drivers zijn(zit php5 op). Staat dan dit:
PDO
PDO support enabled
PDO drivers no value
Hoe kan je dan als je bv op een server zit met geen PDO drivers toch pdo gebruiken. Rest het dan alleen om het de hoster te vragen te installeren?
edit2:
Meestal word de PDO geactiveerd, maar de drivers niet geinstalleerd. Dat kan je dus vragen aan de Hoster door dat in de php.ini te doen.
Quote:
extension=php_pdo.dll
extension=php_pdo_firebird.dll
extension=php_pdo_informix.dll
extension=php_pdo_mssql.dll
extension=php_pdo_mysql.dll
extension=php_pdo_oci.dll
extension=php_pdo_oci8.dll
extension=php_pdo_odbc.dll
extension=php_pdo_pgsql.dll
extension=php_pdo_sqlite.dll
extension=php_pdo_firebird.dll
extension=php_pdo_informix.dll
extension=php_pdo_mssql.dll
extension=php_pdo_mysql.dll
extension=php_pdo_oci.dll
extension=php_pdo_oci8.dll
extension=php_pdo_odbc.dll
extension=php_pdo_pgsql.dll
extension=php_pdo_sqlite.dll
Maar het kan dus ook(wat wel minder handig is en misschien nog wel meerdere nadelen hebben) tijdens de runtime worden geactiveerd. De drivers zijn er dus wel maar niet geinstalleerd/geactiveerd. Dat kan je doen door de functie dl — Loads a PHP extension at runtime int dl ( string $library ) http://nl2.php.net/manual/nl/function.dl.php.
Ga me dus even eerst verdiepen in DPO(Tutorials lezen/printen). En denk dat ik pgSQL ga gebruiken(is toch wel makkelijk aan te passen toch later naar bv mysql).
Gewijzigd op 01/01/1970 01:00:00 door DDragonz
Vind dus nu alleen tuts met linux als besturingssysteem.
edit:
wow, ben nu via de Ubuntu live cd op phphulp.nl, maar is iets te langzaam :P. Dus word het toch installeren.
Gewijzigd op 01/01/1970 01:00:00 door DDragonz
Ten eerste Cookies:
Cookies kunnen worden gestolen en worden nagemaakt. Maar betekend dit nou dat ik het niet veilig kan maken, want ik heb nu iets in gedachten waarmee het misschien wel veilig is... Als je in de gebruikers sql de inlogip op slaat en in de cookie een string plaatst als deze: md5($loginip.$loginid). De id is dan natuurlijk van de gebruiker. Bij het inloggen worde dan deze cookie gemaakt en in de sql de ip adres toegevoegd/verandert. Zo kan je er ook voor zorgen dat je met 1 account maar op een pc(ip-adres) tegenlijk kan. Met sessions is dit toch veilig, maar ook veilig voor cookies? Of zie ik iets over het hoofd? Ik wil dan instel mogenlijkheid, om bv ip adressen toe tevoegen (iedere gebruiker zijn eigen). Waar het veilig is om cookies te gebruiken zodat ze ingelogd blijven en niet de heletijd in moeten loggen. Snap je?
Ten tweede:
Ik heb een dik 34(als ik het mhu goed kan herinneren) bladzijdes geprint over hack vrij programmeren(is niet volledig, maar bevat de belangrijkste dingen). Daar staat onder andere in hoe je een brute force tegen kan gaan in een inlog systeem. Een van de punten is dat je niet mag vrijgeven nadat een inlog is mislukt of de wachtwoord verkeerd is. Zo weet de hacker dat de gebruiker bestaat enz. Je zou dan bv moeten geven: Het inloggen is mislukt! Probeer opnieuw... oke, dat is dan geen probleem. Maar wat ik mij bedacht is dat wanneer iemand achter wil komen of een gebruikersnaam, naam of email al bestaat. Je gewoon naar de registratie pagina moet gaan en daar probeer als de betreffende persoon te registreren. En meestal geeft de registratie proces aan dat de naam of email al bezet is of niet. Zo kan je dan als nog als hacker achter komen of iemand of een gebruikersnaam in gebruik is.
Dan kan je toch net zo goed zeggen dat de wachtwoord niet klopt met het betreffende gebruikersnaam(niet dat ik dat ga doen, maar toch ).
Ik hoop dat jullie mij dit kunnen verhelderen :)
grtz DDragonz
Ik zou met het oog op de gebruiksvriendelijkheid het ip-adres waarmee ingelogd wordt niet in de users tabel opslaan, maar eerder in een aparte tabel waarin je het ip aan een user_id koppelt. Op die manier is het mogelijk om ook op een andere locatie in te loggen zonder dat je cookie op de ene locatie ongeldig wordt. Verder moet je er rekening mee houden dat binnen een netwerk voor de buitenwereld iedereen hetzelfde ip-adres heeft, en dat de cookie dus altijd nog binnen het netwerk gestolen en misbruikt kan worden.
Wat betreft je tweede punt, ik zou het gewoon lekker algemeen houden met iets als 'Inloggen mislukt, controleer je inloggegevens'. Inderdaad, men zou er via een registratie pagina achter kunnen komen of een gebruikersnaam bestaat. Maar het invullen van een heel registratieformulier is voor sommigen al teveel moeite om te achterhalen of een gebruikersnaam bestaat of niet. Het is niet nodig om deze informatie al tijdens het inloggen kenbaar te maken, dus ik zou het lekker achterwege laten.
1.
Cookie's gebruiken kan altijd, alleen je moet nooit inlog gegevens plaatsen in een cookie, wil er mee zeggen dat je dus geen account naam en wachtwoord daar in gaat opslaan.
Ik sla meestal andere gegevens op, zo wie zo in MD5 formaat en een hele boel nep gegevens, en veel al is een MD5 hash gebaseerd op 2 gegevens, bijvoorbeeld het userid + e-mail adres, en sla ik bijvoorbeeld een datum/tijd op zoals : 12:31:00 008-12-1971
En dan zou je denken dat dit echt om een tijd gaat, maar ik kan hier mee ook een userid bedoelen , kortom : 123100008121971
Dus een item in het cookie kan best bij mij een parameter hebben voor het wachtwoord, maar dat is het totaal niet.
Ik zeg maar zo, probeer ze altijd te misleiden...
2.
Brute forcen kun je voorkomen door het IP adres te monitor, stel je voor dat je in 1 minuut tijd 50 requests krijgt van een IP naar de webserver, en dus jou script aanspreekt. dan monitor je dat, en zodra dit gebeurt zorg je ervoor dat de IP voor een tijdje wordt gebanned.
Maar zo kun je nog best wel veel bedenken om iets tegen te gaan, de meeste hackers zijn amateurs die wat lezen en het willen uitproberen, gewoon ontmoedigen door ze de indruk te geven dat het bij jou allemaal te veel tijd kost.
Als ze een automatische bot/programma gebruiken hoef dat niet moeilijke te zijn om er even snel achter te komen of een naam/gebruikersnaam/email al eens is gebruikt of niet via de registratie pagina. Nu tegen woordig de captcha ook worden gekraakt is het ook veel moeilijke :P.
@Blache and Danny:
Maar id het is allemaal veel te veel werk voor iemand. Heb toevallig vandaag in php 5 complete handboek een stukje tekst gelezen in de authentication gedeelte dat alle beveiliginen meer een drempel is voor hackers. Je probeert het zo hoog mogenlijk te maken zo dat geen scriptkiddies enz het lukt. Tegen een echte criminele hacker kan je moeilijk iets doen.
Ik weet nu wat ik moet doen dankje :)... laat wel weer horen als ik over meer dingen iets moet vragen. :)