Andra punkter att tänka på:
1. Du är sårbar för bruteforce
En ordboksattack skulle knäcka ditt lösenord. Eftersom de allra flesta användare har ett osäkert lösenord är det bara en tidsfråga. Använd captcha eller logga in ogiltiga poster. Eller lägg till en fördröjning när lösenordet är felaktigt.
Som överste Shrapnel sa, ett regnbågsbord är inte ett problem för dig eftersom de används när någon har en massa hash och vill knäcka dem. Salt används för att få ett visst skydd mot ett regnbågsbord, och detta är inte ditt fall.
2. Du skickar lösenord i klartext
Om någon sniffar på din inloggning (t.ex. wifi) är du dömd. Det finns några javascript-libs som kan kryptera vad som helst med hjälp av offentliga nycklar. Om du inte vill använda SSL, kryptera inloggningen/lösenordet, skicka till servern, dekryptera med den privata nyckeln och du är säkrare.
3. Överväg att använda förberedda uttalanden på MySQL
Att använda förberedda satser hjälper mot SQL-injektion, eftersom det säkert kan köras även med skadlig indata:
$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();
4. Förmedla inte validering på klientsidan
På ditt inloggningsformulär vidarebefordrar du en javascript-funktion som hindrar Enter-tangenten att fungera. Vad händer om jag inaktiverar Javascript? Du kan använda ett dolt fält (t.ex. ), använd din funktion för att förhindra Enter-nyckel, OCH använd en onSubmit()-funktion för att ändra FormIsValid till 1 innan skicka formuläret. På din server, verifiera FormIsValid.
5. Du är sårbar för sessionskapning
Din session sparas på en cookie, som standard heter PHPSESSID. Om en angripare kan få den cookien kan den skicka den till din server och stjäla din session. För att förhindra det kan du spara användarens IP-adress och användaragent i sessionen och jämföra värdet som tas emot från sessionen vid varje begäran. Om värdena inte stämmer överens kan användarens IP-adress ha ändrats eller så kan sessionen ha kapats.
6. Du kan vara sårbar för sessionsfixering
Som nämnts ovan, om någon övertygar din administratör att få tillgång till någon webbplats, och den här webbplatsen skickar en begäran till din webbplats med ett PHPSESSID på begäran, kommer din webbplats att skapa sessionen, bearbeta inloggningen/lösenordet och ange att användaruppgifterna är felaktiga . Inte illa förrän nu.
Senare loggar din administratör in på din portal, sessionen finns redan, inloggningen och lösenordet matchar och sessionen UPPDATERAS. Variabeln giltig nu är 1.
Så fort variabeln har uppdaterats har angriparen full åtkomst till din portal, eftersom han känner till PHPSESSID, din webbplats förhindrar inte sessionskapning eller sessionsfixering.
För att undvika sessionsfixering och kapning, se #5.