Användaren bör ha möjlighet att påverka huruvida användarnamnet sparas. Kanske genom att sätta en kryssruta bredvid inloggningsfälten: "Kom ihåg mitt användarnamn på den här datorn"

Om man nu sparar användarnamn, finns det någon nackdel med att spara användarnamnet i klartext som en cookie? Är det bättre med en nyckel som pekar på användaren i databasen? Eller något annat alternativ? Spara en krypterad variant av användarnamnet som cookie? Det kanske duger med någon simpel kryptering och samma statiska nyckel för hela sajten.

Om man sparar användarnamnet i klartext som cookie kanske viss privacy-mjukvara ogillar det?

Jo, men du skrev själv detta: Det var det jag svarade på.

Sen finns det andra lösningar för att hantera dynamiska IP addresser också, som Clarence skrev, räcker det ofta med att använda klass C addressen. En påbyggnad på detta är att användarnamnet avgör vilka klass C-nät addresser som får logga in utan behöva skriva in lösenord, dvs. flera olika klass C tillåts för samma användare. Men det finns andra lösningar också.

Man skulle väll antagligen kunna kolla dom 2, eller möjligtvis 3 första blocken i IP-adressen för att se ifall dem stämmer precis som ni säger.

Chansen att en hacker på 3 försök skulle lyckas använda exakt samma user agent, samma ip-range och dessutom lyckats gissa rätt på den unika-slumpmässiga hashen borde ju vara en chans på bara någon promille?

Nu börjar det bli lite väl OT men visa mig en svensk ISP som påtvingar sina användare att använda deras HTTP-proxy (vilket är vad som krävs för att det du beskriver ska kunna hända).

Om man sparar IP (de 16 eller 24 första bitarna) tillsammans med user agent, och tillåter flera auto-login-rader i DB per användare, kommer man dessutom förbi problemet med om användaren har olika webbläsare/OS hemma och på jobbet. Det kräver förstås att det är olika IP range hemma och på jobbet, men det lär det vara i de flesta fall.

Det räcker väl att tillåta bara ett försök för inloggning via cookie. Det är ju inte så att den normala användaren försöker igen med en annan cookie om det misslyckades första gången.

Jo men om användaren valt att vara ihågkommen på ett annat ställe och blir bannad så snart som den gamla (och ytterst ovetande) cookien försöker att logga in honom är kanske inte så bra. :D

Behöver inte vara olika, man matchar ju alla kriterierna mot db:n.

Man bannar inte användaren.

Kanske så här någonting? (Föreslå gärna förbättringar.)

auto-login-tabell:
user-id (indexerad), ip (16 första bitarna), nyckel (>=128 bitar)
(eventuellt även giltighetstid och user agent)

Man sparar user-id och nyckel som cookies.

När cookie-inloggningsförsök sker:

Angående risken skulle jag säga att "någon promille" är extremt stor risk i det här sammanhanget. I det här fallet är dock risken betydligt mindre än så, men den ökar förstås rejält om angriparen kommer över cookien.

Ja, det är sant, så kan man också göra. I så fall blir det dock ännu viktigare med giltighetsdatum i databasen, annars kommer den att fyllas upp med en massa onödiga rader när användarna uppgraderar webbläsare.