Beveiliging van inlogsysteem

- Inloggen via HTTPS als het even kan.
- session_regenerate() aanroepen na een succesvolle login.
- prepared statements (correct) gebruiken.
- password_verify() gebruiken.
- rate limiting
- de applicatie met de database laten verbinden met een account dat zo weinig mogelijk rechten heeft. Als je applictie SQL-injection toe laat maar het account niets kan droppen of alteren maar alleen kan lezen en beperkte tabellen kan updaten blijft de schade alsnog beperkt.
Maar het liefst heb je een applicatie die geen SQL-injection toe laat EN verbind met de database als een account met beperkte rechten. Ook wel bepend als Defence in Depth en Least Privilege Principle.

Als je code hebt geschreven, plaats het dan op dit forum en vraag op feedback.

PS. Als je op een shared server zit dan is het mogelijk dat andere op de zelfde server de sessies van jou gebruikers kunnen uitlezen en wijzigen. Hoort niet te kunnen als de server goed opgezet is... dus een hash zoals Wouter zegt is dan een stuk moeilijker om te vervalsen dan een user id, aangezien veel applicaties de user id info lekken.

@Dos: Is rate limiting het aantal login-pogingen beperken? Hoe zou je dit aanpakken?

Verder bedoel je denk ik session_regenerate_id?

Nee, wat sessies kan de gebruiker aanpassen. Dan kan iemand dus gewoon voordoen alsof hij de administrator is, door gewoon even zijn ID in te voeren.

Wait, what?

PS. Als je op een shared server zit dan is het mogelijk dat andere op de zelfde server de sessies van jou gebruikers kunnen uitlezen en wijzigen. Hoort niet te kunnen als de server goed opgezet is... dus een hash zoals Wouter zegt is dan een stuk moeilijker om te vervalsen dan een user id, aangezien veel applicaties de user id info lekken.

Of je zorgt er gewoon voor dat jouw sessie-bestanden naar jouw webruimte worden weggeschreven via session_save_path(). Wel zorgen dat dit een folder buiten je document root is uiteraard...

@Michael R: het is niet zozeer dat je loginscript veilig is, maar meer dat je je code op een zodanige manier opgezet is, zodat deze veilig is in het gebruik. Dit zal voor een deel staan of vallen met hoe je omgaat met INPUT en OUTPUT. Denk bij INPUT aan formulieren ($_POST), querystring-parameters ($_GET) et cetera. Ook OUTPUT kan gevaarlijk zijn, iemand kan bijvoorbeeld in staat zijn om JavaScript af te drukken en hiermee uit te voeren, tenzij je deze "onklaar" maakt.

"Veiligheid" is niet in één groot enkel onderwerp te vangen, het is een samenspel van verschillende dingen. Ik zou zeggen ga op onderzoek uit, bijvoorbeeld: hoe werken sessies, kijk hoe je veilig queries kunt uitvoeren, kijk hoe je veilig kunt omgaan met user input, kijk hoe je veilig kunt omgaan met user output. Zoek uit hoe escaping in verschillende contexten werkt, zorg voor, bij voorkeur, een enkele character encoding in alles wat je doet.

Als je de volgende stelregel in alles wat je doet toepast, of in ieder geval in je achterhoofd houdt, kom je al een heel eind:

filter input, escape output.

Moet je natuurlijk wel snappen wat dit inhoudt :-).