Andere punten om over na te denken:
Een woordenboekaanval zou uw wachtwoord kraken. Aangezien de overgrote meerderheid van de gebruikers een onveilig wachtwoord heeft, is het slechts een kwestie van tijd. Gebruik captcha of log ongeldige invoer in. Of voeg wat vertraging toe wanneer het wachtwoord onjuist is.
Zoals kolonel Shrapnel zei, een regenboogtafel is voor jou geen probleem, omdat ze worden gebruikt wanneer iemand een hoop hashes heeft en ze wil kraken. Zout wordt gebruikt om enige bescherming te krijgen tegen een regenboogtafel, en dit is niet jouw geval.
Als iemand je login besnuffelt (bijvoorbeeld wifi), ben je ten dode opgeschreven. Er zijn enkele javascript-bibliotheken die alles kunnen versleutelen met openbare sleutels. Als u geen SSL wilt gebruiken, versleutelt u de login/het wachtwoord, verzendt u het naar de server, ontsleutelt u met de privésleutel en bent u veiliger.
Het gebruik van voorbereide instructies helpt tegen SQL-injectie, omdat het veilig kan worden uitgevoerd, zelfs met kwaadwillende invoer:
$dbc = new mysqli("mysql_server_ip", "mysqluser", "mysqlpass", "dbname");
$statement = $db_connection->prepare("SELECT * FROM table WHERE thing='?'");
$statement->bind_param("i", $thing);
$statement->execute();
Op uw inlogformulier geeft u een javascript-functie door waardoor de Enter-toets niet werkt. Wat als ik Javascript uitschakel? Je zou een verborgen veld kunnen gebruiken (bijv. het formulier verzenden. Verifieer FormIsValid op uw server.
Uw sessie wordt opgeslagen in een cookie, standaard genaamd PHPSESSID. Als een aanvaller die cookie kan krijgen, kan hij deze naar uw server sturen en uw sessie stelen. Om dit te voorkomen, kunt u het IP-adres van de gebruiker en de user-agent in de sessie opslaan en de waarde die van de sessie wordt ontvangen bij elk verzoek vergelijken. Als de waarden niet overeenkomen, is het IP-adres van de gebruiker mogelijk gewijzigd of is de sessie gekaapt.
Zoals hierboven vermeld, als iemand uw beheerder overtuigt om toegang te krijgen tot een site en deze site een verzoek naar uw site stuurt met een PHPSESSID op het verzoek, zou uw site de sessie maken, de login/het wachtwoord verwerken en aangeven dat de inloggegevens onjuist zijn . Tot nu toe niet slecht.
Later logt uw beheerder in op uw portal, de sessie bestaat al, de login en het wachtwoord komen overeen en de sessie wordt BIJGEWERKT. De variabele geldig nu is het 1.
Zodra de variabele is bijgewerkt, heeft de aanvaller volledige toegang tot uw portal, omdat hij de PHPSESSID kent, uw site verhindert sessiekaping of sessiefixatie niet.
Zie #5 om sessiefixatie en kaping te voorkomen.