Praxis är väl att det spelar ingen roll om det gäller icke känslig data. Det vanligaste exemplet på data som lagras oskyddad på klienten är tex språkval för en site, om användaren vill ha större typsnitt etc. Men detta behöver ju inte lagras i klartext för det. Ett språkval kan ju lika gärna vara siffran '1' som att det skulle stå 'us-en' eller dylikt.

Regeln man kan tillämpa är väl den att om data behöver krypteras så är det ändå för känsligt för att ö.h.t lagras på klienten.

Jag hade valt att endast lagra en unik identifierare för att automatinloggningsfunktionen.
Kommer någon över cookien så kommer dom in på sidan, men man kommer aldrig åt lösenordet vilket är väldigt viktigt eftersom många har samma lösenord på flera ställen.

Default så lagrar PHP all sessionsdata i filer istället för i minnet som är fallet med ASP. I de fall jag pratar så har webbserveranvändaren helt enkelt haft läsrättigheter i den mappen där filerna ligger samt på filerna. Inga konstigheter eller specialfall på något sätt. :)

Jag är på din linje med att enbart lagra user-id i sessionen, mer behövs inte. Möjligen att man som sagt lagrar IP för att låsa sessionen till IP-adressen.

Nu börjar det här bli lite uttjatat... :)

Att lagra känsliga uppgifter i en cookie bör man vara försiktigt med, själv sparar jag inga egna uppgifter i cookies, det som enda som lagras i cookies är PHPs egna slumpnummer PHPSESSID.

Så här gör jag för att få minimera säkerhetsproblem:

Pseudo-kod för Login-sida med PHP:

1. Visa login sidan för klienten, klienten fyller i uppgifterna och POSTar

2. Rensa POST variablerna från ej tillåtna tecken och kontrollera ev. tomma fält

3. session_start() för att skapa PHP sessionen (PHP skapar cookien PHPSESSID)

4. Om variabel $_SESSION['count'] ej satt, sätt den till 1

5. Om variabel $_SESSION['count'] == 5, presentera en sida som säger "För många
felaktiga försök, prova igen om xx minuter", exit;

6. Kontrollera användarnamn och lösenord mot min databas

7. Om fel användarnamn eller lösen, öka $_SESSION['count'] med 1 och gå tillbaka till punkt 1.

8. Om anv.namn + lösenord stämmer:
Skapa $_SESSION['hash'] = md5(PHPSESSID + user_id + $_SERVER['REMOTE_ADDR])
Skapa $_SESSION['userid'] = userid från databasen

9. Visa klientens skyddade sida


Underliggande skyddade sidor startas alltid med check_login();

Pseudo-kod:

funktionen check_login()
{
session_start();

kolla att $_SESSION['hash']==md5(PHPSESSID + $_SESSION['userid'] + $_SERVER['REMOTE_ADDR])

Om det ej stämmer , presentera inloggningsidan, exit;
Om ok, bara att gå vidare och visa den skyddade sidan för klienten
}

SimonP: Ett tips är att lagra antalet misslyckade försök i databasen istället för i sessionen, eftersom en angripare kan använda ett script som raderar sessionscookien efter varje misslyckat försök och på så sätt få en ny session för varje försök.
I övrigt tycker jag det ser bra ut!

Absolut, det är kan man göra, dock får man lite mer SQL belastning, men det kan det vara värt i vissa fall


På en ny sida som jag håller på med kommer jag att skippa PHPs sessionshantering, och göra en en egen sessionshantering i MYSQL, där mysql tabellen är av MEMORY-typen för att få bra prestanda och slippa hårddiskbaserade lösningar, PHPs egna sessioner lagras som default på serverns hårdisk.

Har man egen server så är det snabbt gjort att ändra i php.ini så att sessionshanteringen ligger i minnet, men att bygga en egen sessionshantering är ju också ett alternativ! :)

En bra grej att göra är att typecast'a värden som är integers om du tar in dessa från användaren. typ

$id = (int)$_POST['id'];

Så blir det inga problem i databasen sen :)

Nja, det är väl inget som ingår i en standard PHP installation ?
Jag testade med session.save_handler = mm på två Windows servrar och det funkade inte.

Har inte testat på linux servrarna ännu.

Jag har aldrig testat i Windows, det kanske inte finns stöd för det helt enkelt...
Om inte annat så är det bara att skapa en ramdrive ange den som session.save_path