[BjörnJ]

Originally posted by BoXon@Aug 22 2009, 17:06
Däremot så kommer nog många användare bli lite fundersamma på att deras användarnamn blir ihågkommet men inte resten.

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?

[SimonP]

Originally posted by _Michael_@Aug 22 2009, 16:12
Frågan är inte om det är/hur mycket säkrare att matcha mot IP. Det är givetvis enormt mycket säkrare

Jo, men du skrev själv detta:

Och det säkraste sättet är dessvärre inte speciellt säkert.

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å.

[BoXon]

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?

[MMC]

Ursprungligen postat av Draqir

Många ISP proxy clusters orsakar olika User agents strings, eftersom de aggressivt försöker minimera antalet HTTP requests (ganska självklart egentligen). Ett exempel;
Om alla här inne sitter på samma ISP och hämtar samma bild vid ungefär samma tidpunkt kommer i många fall bara ett HTTP request gå ut, vilket sparar väldigt mycket bandbredd och bandbredd är pengar. Du kan inte ens förvänta dig att ett IP är samma under en request (hämtning av bilder, filer etc). Detta går enkelt att se på vilken välbesökt sida som helst med ett någorlunda avancerat statistikskript. Så förlita er aldrig på att IP / user agent ska vara samma hela tiden.

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).

[BjörnJ]

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.

[BjörnJ]

Originally posted by BoXon@Aug 22 2009, 17:38
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?

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.

[BoXon]

Ursprungligen postat av BjörnJ

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.

[_Michael_]

Originally posted by BjörnJ@Aug 22 2009, 18:30
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.

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

[BjörnJ]

Ursprungligen postat av BoXon

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.

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:

 if(user-id och IP finns i auto-login-tabellen)
{
 if(nyckel korrekt)
  logga in automatiskt
 else
 {
  radera raden från DB
  radera cookie
  banna IP för autoinloggning (under en viss tid), vanlig inloggning fungerar fortfarande
 }
}
else
{
 radera cookie
 banna IP för autoinloggning (under en viss tid), vanlig inloggning fungerar fortfarande
}

Ursprungligen postat av BoXon

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?

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.

[BjörnJ]

Ursprungligen postat av _Michael_

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

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.