Login systeem
1.524 views
Om niet het wiel opnieuw uit hoeven te vinden, welk advies kunnen jullie geven voor een registratie en login systeem??
1. Sla geen gebruikersgegevens (usernames, (gehashte)wachtwoorden) op in cookies. Inloggegevens horen thuis in een database.
2. Sla wachtwoorden gehasht op met [php]password_hash[/php], en vergelijk ze bij je inlog-procedore met [php]password_verify[/php]
3. Gebruik bij sterke voorkeur SSL zodat men niet tussen de lijn mee kan luisteren. Kost niks tot weinig, en met Lets Encrypt bij de meeste hostingproviders zit je meteen goed.
4. Het locken van een sessie die je in de database op slaan aan een IP is een goed idee; bedenk echter dat dit niet voor iedereen mogelijk is (dynamische ip's) - geef de gebruiker dus de mogelijkheid om daarvoor te kiezen.
5. Geef de gebruiker ook de mogelijkheid om zelf te bepalen hoelang een sessie geldig is. Mensen die op school of bij anderen inloggen willen zo snel weer uitgelogd worden na bepaalde inactiviteit.
6. Maak een lijst waarmee gebruikers zelf hun sessies kunnen bekijken en beheren. Informatie zoals ip-adres en user-agent zijn daarbij handig. Je kan eventueel bij het inloggen de gebruiker mogelijkheid geven om een naam te koppelen aan de inlogsessie, zoals thuis of werk.
7. Bouw logging in zodat je bij vermeend misbruik informatie achter de hand hebt.
8. Bij een foute inlog, geef aan dat "het inloggen mislukt is" en meld niks of het een foute username, of een foute wachtwoord is.
9. Zorg voor een anti-bruteforce. Blokkeer een account via een bepaald IP bij een foute inlogpoging, maar ga niet enkel een account blokkeren, want daarmee dupeer je de gebruiker die wel het recht heeft om in te loggen.
2. Sla wachtwoorden gehasht op met [php]password_hash[/php], en vergelijk ze bij je inlog-procedore met [php]password_verify[/php]
3. Gebruik bij sterke voorkeur SSL zodat men niet tussen de lijn mee kan luisteren. Kost niks tot weinig, en met Lets Encrypt bij de meeste hostingproviders zit je meteen goed.
4. Het locken van een sessie die je in de database op slaan aan een IP is een goed idee; bedenk echter dat dit niet voor iedereen mogelijk is (dynamische ip's) - geef de gebruiker dus de mogelijkheid om daarvoor te kiezen.
5. Geef de gebruiker ook de mogelijkheid om zelf te bepalen hoelang een sessie geldig is. Mensen die op school of bij anderen inloggen willen zo snel weer uitgelogd worden na bepaalde inactiviteit.
6. Maak een lijst waarmee gebruikers zelf hun sessies kunnen bekijken en beheren. Informatie zoals ip-adres en user-agent zijn daarbij handig. Je kan eventueel bij het inloggen de gebruiker mogelijkheid geven om een naam te koppelen aan de inlogsessie, zoals thuis of werk.
7. Bouw logging in zodat je bij vermeend misbruik informatie achter de hand hebt.
8. Bij een foute inlog, geef aan dat "het inloggen mislukt is" en meld niks of het een foute username, of een foute wachtwoord is.
9. Zorg voor een anti-bruteforce. Blokkeer een account via een bepaald IP bij een foute inlogpoging, maar ga niet enkel een account blokkeren, want daarmee dupeer je de gebruiker die wel het recht heeft om in te loggen.
Deze vraag komt vaak terug. Wat mij betreft is het enige juiste antwoord: gebruik een framework.
Ik denk alleen niet dat dit het antwoord is waarop je zit te wachten omdat je snel weer verder wilt met hetgeen je nu hebt (Al is dit waarschijnlijk niet professioneel en veilig).
Het tweede zoekresultaat van google leverde dit op:
https://github.com/JoeZwet/php-mysql-login-simple
Hierbij zou ik wel de mysql functies vervangen voor mysqli.
Het derde resultaat is een tutorial: http://w3epic.com/php-mysql-login-system-a-super-simple-tutorial/
Ik denk alleen niet dat dit het antwoord is waarop je zit te wachten omdat je snel weer verder wilt met hetgeen je nu hebt (Al is dit waarschijnlijk niet professioneel en veilig).
Het tweede zoekresultaat van google leverde dit op:
https://github.com/JoeZwet/php-mysql-login-simple
Hierbij zou ik wel de mysql functies vervangen voor mysqli.
Het derde resultaat is een tutorial: http://w3epic.com/php-mysql-login-system-a-super-simple-tutorial/
Een framework is in mijn ogen niet expliciet nodig. Hoewel het in het globaal voor een hele website zeker wel een handig idee kan zijn. ZO heb je meteen ook handige truukjes en functies die je hiervoor kan inpassen.
Beginnend met PHP: Geen framework, en de basisstappen eerst leren.
Ruim bekend in PHP en OO: Kies een framework wat bij je eisen voldoet.
Beginnend met PHP: Geen framework, en de basisstappen eerst leren.
Ruim bekend in PHP en OO: Kies een framework wat bij je eisen voldoet.
Het lijkt mij niet verstandig om beginnende PHP'ers zelf loginsystemen te laten rollen simpelweg omdat ze lang niet alle implicaties kunnen overzien.
Toen ik beginner was, was mijn 'multi-sessie' inlogsysteem ook best veilig te noemen. Als je maar de essentie van 'veiligheid en websites' maar begrijpt. Want als iemand met XXS een cookie kan stelen via een andere deel van de site, dan ligt dat niet aan je inlogsysteem.
Ergo: het kan geen kwaad om als beginner een inlogsysteem te bouwen. Als je maar bewust bent van veiligheid, pitfalls en do & dont's. Laat desnoods een paar mensen de code reviewen.
Ergo: het kan geen kwaad om als beginner een inlogsysteem te bouwen. Als je maar bewust bent van veiligheid, pitfalls en do & dont's. Laat desnoods een paar mensen de code reviewen.
Na enig zoeken vond ik hier een leuk systeem/script en het 'werkte' ook gelijk met slechts één nadeel.
De captha link is niet bereikbaar . Iemand ervaringen met dit systeem en heeft een oplosing (Misschien)???
De captha link is niet bereikbaar . Iemand ervaringen met dit systeem en heeft een oplosing (Misschien)???
Klopt! ReCaptcha is overgenomen door Google en daarna flink doorontwikkeld.
Inmiddels is er ook een ontzichtbare variant gemaakt die de drempel van het overtypen voor gebruikers wegneemt. Daar heb ik nog geen ervaringen mee.
ReCaptcha is leuk voor registreren, maar niet voor inloggen. Bots die proberen in te loggen moeten liever op een 'brute-force wall' stuiten.
Oh ja, en je script waar je naar verwijst stamt uit 2009. Best oud, hoewel het goed in elkaar zit. Dus doorloop alles wel even goed door op veiligheiden. Het kan zijn dat er misschien het verouderde md5() gebruik wordt voor het hashen van de passwords. Ikzelf raad de genoemde password_hash en password_verify aan.
Inmiddels is er ook een ontzichtbare variant gemaakt die de drempel van het overtypen voor gebruikers wegneemt. Daar heb ik nog geen ervaringen mee.
ReCaptcha is leuk voor registreren, maar niet voor inloggen. Bots die proberen in te loggen moeten liever op een 'brute-force wall' stuiten.
Oh ja, en je script waar je naar verwijst stamt uit 2009. Best oud, hoewel het goed in elkaar zit. Dus doorloop alles wel even goed door op veiligheiden. Het kan zijn dat er misschien het verouderde md5() gebruik wordt voor het hashen van de passwords. Ikzelf raad de genoemde password_hash en password_verify aan.
Ik ben ook bezig om mijn inlogsysteem te verbeteren.
Nu heb ik eigenlijk alleen een cookie nodig om wat inloggegevens te onthouden voor bepaalde tijd.
Maar is de optie om inloggegevens voor bepaalde tijd terug te vinden via cookie nog relevant?
Want de meeste browsers vragen al of zij gegevens moeten onthouden.
En wat is het risico als de browser het onthoudt?
Is het ook niet zo dat cookie domeingebonden is?
Dus http//www.mijndomein.nl is anders als mijndomein.nl of www.mijndomein.nl?
Nu heb ik eigenlijk alleen een cookie nodig om wat inloggegevens te onthouden voor bepaalde tijd.
Maar is de optie om inloggegevens voor bepaalde tijd terug te vinden via cookie nog relevant?
Want de meeste browsers vragen al of zij gegevens moeten onthouden.
En wat is het risico als de browser het onthoudt?
Is het ook niet zo dat cookie domeingebonden is?
Dus http//www.mijndomein.nl is anders als mijndomein.nl of www.mijndomein.nl?
Welke inloggegevens wil je onthouden dan? Ik zou zeker geen cookies gebruiken om gebruikernamen en/of wachtwoorden op te slaan. Als een gebruiker dat wilt, dan kan hun browser dat wel. En dan is dat nog veiliger zelfs, dan met een cookie.
Cookies zijn domeingebonden inderdaad, maar kunnen ook direct over meerdere subdomeinen gelden. Zie ook [php]setcookie[/php]. Ook voor je browser zijn er vaak add-ons om Cookies te kunnen beheren.Handig bij het debuggen.
Cookies zijn domeingebonden inderdaad, maar kunnen ook direct over meerdere subdomeinen gelden. Zie ook [php]setcookie[/php]. Ook voor je browser zijn er vaak add-ons om Cookies te kunnen beheren.Handig bij het debuggen.
Onthoud geen inloggegevens, maar een succesvolle inlogpoging (of regel dit via de browser, waarbij het "beveiligingsprobleem" meer naar de computer/gebruiker wordt verplaatst). Je zou bijvoorbeeld een lange random hash kunnen onthouden, zowel in je database alsook in een cookie. Link deze hash in je database aan een gebruiker via een "remember login" tabel. Deze hash is verder compleet "neutraal" in die zin dat deze geen enkele informatie bevat over de gebruiker in kwestie.
Nu, op het moment dat je cookie gestolen wordt (op wat voor manier dan ook) kan iemand met deze hash direct inloggen. Daarom is het zaak dat je aanvullende informatie onthoudt, bijvoorbeeld een IP-adres, een user agent, een combinatie of iets anders. Deze voeg je toe als extra controle in de "remember login" tabel, of in de gebruikers-tabel (waar je bijvoorbeeld het laatst bekende IP bijhoudt).
Wat voor oplossing je ook kiest, het zal altijd een tradeoff zijn tussen veiligheid en gebruikersgemak.
Daarnaast zal je applicatie moeten voorzien in het naadloos automatisch her-inloggen. Althans ik neem aan dat dat mede het doel is? Dat wanneer je sessie tijdens een periode van inactiviteit verloopt, dat je daarna meteen weer verder kunt?
Nu, op het moment dat je cookie gestolen wordt (op wat voor manier dan ook) kan iemand met deze hash direct inloggen. Daarom is het zaak dat je aanvullende informatie onthoudt, bijvoorbeeld een IP-adres, een user agent, een combinatie of iets anders. Deze voeg je toe als extra controle in de "remember login" tabel, of in de gebruikers-tabel (waar je bijvoorbeeld het laatst bekende IP bijhoudt).
Wat voor oplossing je ook kiest, het zal altijd een tradeoff zijn tussen veiligheid en gebruikersgemak.
Daarnaast zal je applicatie moeten voorzien in het naadloos automatisch her-inloggen. Althans ik neem aan dat dat mede het doel is? Dat wanneer je sessie tijdens een periode van inactiviteit verloopt, dat je daarna meteen weer verder kunt?