Serveroberoende inloggning - (kommentarer)

Sitter och funderar lite, bygger en webbsida där användaren kommer slussas mellan olika webservrar, domäner och till helt andra applikationer t.ex Windows Media Server (som i sin tur kommer ha en separat verifiering av användaren för att kolla av om användaren har nog med tid för att se en film) osv.

Normalt bygger jag inloggningsystem med hjälp av sessioner, vilket i det här fallet kommer fungera mindre bra. Så funderar på följande:

1. Användaren loggar in.

2. Stämmer allt skapas en sträng, t.ex (användarid + användarnamn + salt + microtime) som körs genom sha512, som blir en 128 tecken hex sträng, ungefär såhär: 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043

3. Strängen sparas i dben med användarid, ip och en timestamp

4. Under hela vistelsen på webbsiten kollas strängen av för att verifiera användaren.

5. Väljer en användare att kolla en film skickas korrekt data till media servern + strängen, media servern kollar av databasen via strängen + ip om användaren har tillräckligt med tid.

Självklart är strängen tidsbaserad och tas bort vid inaktivitet, skulle även kunna göra att den uppdateras vid varje request, inloggning osv sker via https.

Sitter och funderar på om detta är en säker, smart och smidig lösning. Är medveten om att session hijacking han förekomma, men känns som jag förebyggt det ganska bra genom att dra till med sha512 istället för en vanlig md5 kryptering + ip check.

Skulle kunna skriva en sessions hanterare via databas och lägga verifieringen där men vill undvika det då jag senare kommer köra load balancing på webservrarna via Zends programvara vilket använder filbaserad sessionshantering såvitt jag vet.

Några kommentarer?

De flesta fristående användarservrar brukar bygga på att man vid inloggning får ett sessions-ID, och sen varje gång en applikation vill verifiera att man är inloggad kollar den att sessions-ID:t och användar-ID:t användaren presenterar finns i listan över aktiva sessioner. Så ja, din lösning låter funkis.

Jag skulle dock rekommendera att du har med någon slumpsträng i det du hashar (så det blir användarid + användarnamn + salt + microtime + några slumpsiffror) för att sessions-ID:n inte ska vara helt deterministiska (eftersom det gör dem lättare att fejka).

Det blir dock inte säkrare för att du använder SHA1 istället för MD5. Anledningen till att man inte ska använda MD5 för att hasha t.ex. lösenord är för att MD5 är möjlig att reversera, men det är inte det du är oroad för här. Hur hashen byggdes upp är mindre intressant, det är ju själva sessions-ID:t man vill åt, har man väl fått tag på det kan man ju påstå att det är man själv som har sessionen. Risken för sådant är väl inte helt jätteenorm - särskilt inte om du gör en IP-check - men vill du vara helt säker är det SSL som gäller.