WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   "Kom ihåg mig" - säkraste sättet (https://www.wn.se/forum/showthread.php?t=38651)

BoXon 2009-08-22 13:25

"Kom ihåg mig" - säkraste sättet
 
Hej!

Sitter och programmerar en inloggning som jag vill ska ha en "kom ihåg mig" funktion.

Jag funderar dock vad som är säkrast att göra? Min ide just nu är att lagra
användarens uppgifter i hans egen cookie fil, och med dessa sedan göra en
virtuell inloggning (och med en session kontrollera att detta bara görs vid första besöket, och inte vid varje uppdatering). Och sedan som vanligt sätta
en session som dör när man stänger sidan. Min sida går ju så säker som den
kan, men hur är det med användarens säkerhet?

Förslag och synpunkter mottages. :)

_Michael_ 2009-08-22 13:46

En bra idé kan vara att i användarens cookie endast spara en nyckel (ej kopplad till användarens lösenord) och i db:n spara t.ex. dennes user agent.
Det försvårar för någon som kommit över användarens cookie att själv logga in med den.
Varje gång som någon gör en "vanlig" inloggning med sitt användarnamn samt lösenord kan man i databasen då spara en ny nyckel och user agent vilket gör den tidigare cookien inaktuell. Låt oss säga att användaren sitter på en dator där andra har tillgång (Internetcafé eller vad som helst) och av misstag/okunskap valt att bli ihåg kommen, då löser det sig självt när användaren loggar in på nästa ställe. För de som vill använda funktionen på t.ex. både hemmet och arbetet uppstår såklart problem...

Magnus_A 2009-08-22 15:03

Spontant tycker jag inte att man ska lagra annat än en nyckel i användarens kakburk, själva inställningarna lägger man i databas eller dylikt.

BoXon 2009-08-22 15:04

Borde detta kunna fungera bra då?

Kom ihåg mig:

1. Generera en sträng med slumpade tecken
2. Spara tecknen & user agent i databasen
3. Sätt en cookie med samma tecken
4. Skapa en session för användaren

Vid nästa besök:

Finns en cookie men ingen session:
1. Kolla om den matchar någon med samma ID & user agent.
2. Gör den det: Skapa en session för användaren & generera ny sträng som sparas i cookien & databasen
Om inte: Ta bort cookien.

_Michael_ 2009-08-22 15:18

Citat:

Originally posted by BoXon@Aug 22 2009, 15:04
Borde detta kunna fungera bra då?

Kom ihåg mig:

1. Generera en sträng med slumpade tecken
2. Spara tecknen & user agent i databasen
3. Sätt en cookie med samma tecken
4. Skapa en session för användaren

Vid nästa besök:

Finns en cookie men ingen session:
1. Kolla om den matchar någon med samma ID & user agent.
2. Gör den det: Skapa en session för användaren & generera ny sträng som sparas i cookien & databasen
Om inte: Ta bort cookien.

Mycket säkrare än så är det nog svårt att få en kom ihåg mig-funktion :)

SimonP 2009-08-22 15:19

Att enbart använda User Agent som salt ger inte speciellt mkt säkerhet, lägg även på IP-nr så får du en betydligt säkrare "kom ihåg".

_Michael_ 2009-08-22 15:21

Citat:

Originally posted by SimonP@Aug 22 2009, 15:19
Att enbart använda User Agent som salt ger inte speciellt mkt säkerhet, lägg även på IP-nr så får du en betydligt säkrare "kom ihåg".
Sant men väldigt många användare får då problem för att de har dynamiskt IP...

crazzy 2009-08-22 15:40

Citat:

Ursprungligen postat av _Michael_
Citat:

Ursprungligen postat av SimonP
Att enbart använda User Agent som salt ger inte speciellt mkt säkerhet, lägg även på IP-nr så får du en betydligt säkrare kom ihåg.

Sant men väldigt många användare får då problem för att de har dynamiskt IP...

Jag har dynamiskt ip, men jag har haft samma ip sen jag flyttade hit... (ett halvår)

BjörnJ 2009-08-22 15:42

Hur lång bör nyckeln vara? Minst 128 bitar antar jag.

Bör man även sätta user-id (eller annan unik integer) som cookie och i "auto-login-tabellen"? Alltså för att ha en indexerad integer att söka efter i databasen.

Det kan nog vara bra att spara giltighetstid också i databasen.

Man kanske även bör ha koll på om det kommer många inloggningsförsök med olika nycklar från samma IP inom en viss tid.

Angående att spara user agent så höjer det förstås säkerheten, men som sagt kan det ställa till problem om användaren vill ha autoinloggning både på jobbet och hemma, eller om hen har flera olika webbläsare på sin dator.

Cookien kanske bör ha en viss giltighetstid som aldrig förnyas, så att cookien kommer att försvinna efter ett tag från publika datorer om någon skulle ha gjort misstaget att vällja "kom ihåg inloggning" på en sådan dator. När cookiens gilitighetstid tar slut raderas den och användaren blir tvungen att logga in igen.

Om användaren väljer att logga ut bör cookien raderas.

Draqir 2009-08-22 15:47

User agent är inte direkt alltid statiskt. Beror på vad du har för ISP, ibland kan det växla under bara ett enda request. :P

BjörnJ 2009-08-22 15:47

Timeout när jag försöker spara redigerat inlägg. :(
Citat:

Originally posted by BjörnJ@Aug 22 2009, 15:42
Om användaren väljer att logga ut bör cookien raderas.
Och även radera nyckeln ur databasen.

BjörnJ 2009-08-22 15:50

Citat:

Originally posted by Draqir@Aug 22 2009, 15:47
User agent är inte direkt alltid statiskt. Beror på vad du har för ISP, ibland kan det växla under bara ett enda request.
Hm? En ISP ändrar väl aldrig user agent i HTTP requests som går genom deras nät? Eller? (Om man inte kör via proxy förstås.)

_Michael_ 2009-08-22 15:55

Längden på nyckeln har väl i praktiken ingen direkt betydelse. Bättre att se över antalet inloggningsförsök från samma IP.
Men ur en hackares synvikel är det mycket lättare att köra en wordlistattack på lösenordet än på en unik sträng.

Att spara gilltighetstiden i databasen eller att låta cookie:n dö efter en viss period har väl ingen betydelse?

Att cookie:n raderas när man manuellt loggar ut är en självklarhet. Om att använda user agent ger högre säkerhet men leder som sagt till problem för vissa. Där är det en avägning vad som är att föredra.

Angående att matcha IP så ger det även problem för det som bär med sig datorn...

EDIT:
ISP har ju ingen koppling till användarens user agent. Det som däremot kan ändra user agent är ju uppgradering av webbläsare eller OS

BoXon 2009-08-22 16:00

Skall genomföra ett litet test på det jag själv skrev förut. Angående att man inte kan bli ihågkommen på flera olika platser så tycker jag nog mest att det är positivt. Som sagt, skulle man av misstag kryssa i kom ihåg mig någonstans så är det ju ogjort nästa gång man loggar in. :)

SimonP 2009-08-22 16:03

Citat:

Originally posted by _Michael_@Aug 22 2009, 14:21
men väldigt många användare får då problem för att de har dynamiskt IP...
Självklart, men det är ändå rätt sällan man får nytt IP, mitt har jag nu haft i 4 mån.

Men som sagt, enbart User agent gör det inte svårare för en hacker, det handlar om sekunder så har man testat vilken User agent som validerar gentemot cookien.

_Michael_ 2009-08-22 16:16

Citat:

Originally posted by SimonP@Aug 22 2009, 16:03
Men som sagt, enbart User agent gör det inte svårare för en hacker, det handlar om sekunder så har man testat vilken User agent som validerar gentemot cookien.
Nej, en någorlunda duktig hacker lär testa samma user agent (Som man för övrigt troligen kommit över långt innan man fått tag på cookie:n). Det svåra i allt är givetvis att man inte vet vad som matchas.
Sen kan man alltid argumentera för att ett system ska vara säkert även om en hacker känner till alla säkerhetsåtgärder och algoritmer så ur det perspektivet är kom ihåg mig inte speciellt säkert...

Sen krävs det ganska speciella omständigheter för att man ska lägga ner tiden på att komma över en cookie när det övergripande problemet är att användare tenderar att välja extremt svaga lösenord.

BoXon 2009-08-22 16:28

En hacker har ändå väldigt liten chans att lyckas om han endast har 3 försök innan han blir IP-bannad, vilket är fallet på mina webbplatser. :)

Här är min början, vad tycks?
Citat:

<?php
ob_start();
session_start();

if(!isset($_SESSION['user'])) {
if(isset($_COOKIE['userkey'])) {

$sql = mysql_query("SELECT user FROM web_users WHERE userkey='".mres($_COOKIE['userkey'])."' AND useragent='".mres($_SERVER['HTTP_USER_AGENT'])."' ");

if(mysql_num_rows($sql) <> 0) {

// Lyckad inloggning, arrangera en ny nyckel...
$_SESSION['user'] = mysql_result($sql, 0, 'user');
$randValue = randomValue('128', '3');
mysql_query("UPDATE web_users SET userkey='".$randValue."', useragent='".mres($_SERVER['HTTP_USER_AGENT'])."'");
setcookie('userkey', $randValue);

}else{

// Ta bort felaktig nyckel...
setcookie('userkey');

}

}

}
?>


SimonP 2009-08-22 16:38

Citat:


... Det svåra i allt är givetvis att man inte vet vad som matchas.

Det är inte ett dugg svårt om man bara använder User agent.

Citat:


Sen kan man alltid argumentera för att ett system ska vara säkert även om en hacker känner till alla säkerhetsåtgärder och algoritmer så ur det perspektivet är kom ihåg mig inte speciellt säkert...

Man behöver inte veta någonting om någon algoritm ifall den baseras på cookievärdet + User agent.

Det var trådskaparen som ville veta det "säkraste sättet".

Citat:


Sen krävs det ganska speciella omständigheter för att man ska lägga ner tiden på att komma över en cookie när det övergripande problemet är att användare tenderar att välja extremt svaga lösenord.

Om någon snor en cookie via ett XSS hål i sidan spelar det ingen roll om användaren har ett extrem komplicerat lösenord! När det gäller cookies har siteägaren lika mkt ansvar att skydda dessa på bästa sätt, det är en viss skillnad på detta och om användaren själv valt en svagt lösenord, då får han/hon skylla sig själv.

tartareandesire 2009-08-22 16:46

Citat:

Ursprungligen postat av SimonP
Citat:

Ursprungligen postat av _Michael_
men väldigt många användare får då problem för att de har dynamiskt IP...

Självklart, men det är ändå rätt sällan man får nytt IP, mitt har jag nu haft i 4 mån.
Men som sagt, enbart User agent gör det inte svårare för en hacker, det handlar om sekunder så har man testat vilken User agent som validerar gentemot cookien.

Nja, det varierar en hel del. Det blir inte så lyckat att utgå från sig själv och sedan tro att den statistiken gäller =) På en plats man kan ha tre olika IP-nummer på en dag medan man på nästa ställe sitter med ett och samma i flera månader trots att man har dynamiskt IP.

_Michael_ 2009-08-22 16:49

Citat:

Originally posted by SimonP@Aug 22 2009, 16:38
Citat:

Det var trådskaparen som ville veta det "säkraste sättet"..

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

IP är säkrare men fungerar inte för alla.

Så värst mycket mer går inte att göra...

BjörnJ 2009-08-22 16:50

På vissa ställen blir man påtvingad en ny IP varje dygn, även om all utrustning inklusive dator har varit påslagen hela tiden.

SimonP 2009-08-22 16:54

Citat:

Originally posted by tartareandesire@Aug 22 2009, 15:46
Nja, det varierar en hel del. Det blir inte så lyckat att utgå från sig själv och sedan tro att den statistiken gäller =) På en plats man kan ha tre olika IP-nummer på en dag medan man på nästa ställe sitter med ett och samma i flera månader trots att man har dynamiskt IP.
Nja, jag utgår inte bara från mig själv, utan mer generellt, har tillgång till olika 5 olika ISP:er och det är sällan dom byter.

Personligen tycker jag inte man ska ha "kom ihåg"-funktioner, dom flesta webbläsare klarar själva av att spara inloggning + lösenord, och då är det upp till användaren hur han vill göra, inte siteägaren. Betydligt enklare och i många fall säkrare.

tartareandesire 2009-08-22 16:58

Citat:

Ursprungligen postat av SimonP
Citat:

Ursprungligen postat av tartareandesire
Nja, det varierar en hel del. Det blir inte så lyckat att utgå från sig själv och sedan tro att den statistiken gäller =) På en plats man kan ha tre olika IP-nummer på en dag medan man på nästa ställe sitter med ett och samma i flera månader trots att man har dynamiskt IP.

Nja, jag utgår inte bara från mig själv, utan mer generellt, har tillgång till olika 5 olika ISP:er och det är sällan dom byter.
Personligen tycker jag inte man ska ha kom ihåg-funktioner, dom flesta webbläsare klarar själva av att spara inloggning + lösenord, och då är det upp till användaren hur han vill göra, inte siteägaren. Betydligt enklare och i många fall säkrare.

Jo, men vad jag försökte få fram var att det finns en hel del som har ett nytt IP-nummer i princip varje dag (inte samma som föregående dag alltså).

Annars håller jag med dig, det finns inte längre någon större poäng med att göra egna kom ihåg mig-funktioner.

BjörnJ 2009-08-22 16:58

Ett mellanalternativ är att komma ihåg användarnamnet, så användaren bara behöver skriva lösenord för att logga in. Markören kan placeras i lösenordsrutan automatiskt om användarnamn är satt.

SimonP 2009-08-22 17:00

Citat:

Originally posted by _Michael_@Aug 22 2009, 15:49
Och det säkraste sättet är dessvärre inte speciellt säkert.

IP är säkrare men fungerar inte för alla.

Så värst mycket mer går inte att göra...

Jo, det är faktiskt mkt säkrare, dom flesta cookie-stealing attackerna skulle förhindras. Det går ej att fejka IP-nr om man ska kunna ha tvåvägs-kommunikation, medans vilken 15-åring som helskt kan fejka en User agent. Men som sagt, det bästa är att undvika "serverside-kom-ihåg-funktioner".

Draqir 2009-08-22 17:02

Citat:

Ursprungligen postat av BjörnJ
Citat:

Ursprungligen postat av Draqir
User agent är inte direkt alltid statiskt. Beror på vad du har för ISP, ibland kan det växla under bara ett enda request.

Hm? En ISP ändrar väl aldrig user agent i HTTP requests som går genom deras nät? Eller? (Om man inte kör via proxy förstås.)

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.

BoXon 2009-08-22 17:06

Citat:

Originally posted by BjörnJ@Aug 22 2009, 16:58
Ett mellanalternativ är att komma ihåg användarnamnet, så användaren bara behöver skriva lösenord för att logga in. Markören kan placeras i lösenordsrutan automatiskt om användarnamn är satt.
Du slog huvudet på spiken! :huh:

Det låter som det absolut bästa alternativet, och bra mycket enklare!

Däremot så kommer nog många användare bli lite fundersamma på att deras användarnamn blir ihågkommet men inte resten. :(

Ang. detta med dynamisk IP så får jag en ny IP ungefär varje gång som jag startar om datorn.

_Michael_ 2009-08-22 17:12

Citat:

Originally posted by SimonP@Aug 22 2009, 17:00
Jo, det är faktiskt mkt säkrare, dom flesta cookie-stealing attackerna skulle förhindras. Det går ej att fejka IP-nr om man ska kunna ha tvåvägs-kommunikation, medans vilken 15-åring som helskt kan fejka en User agent. Men som sagt, det bästa är att undvika "serverside-kom-ihåg-funktioner".
Frågan är inte om det är/hur mycket säkrare att matcha mot IP. Det är givetvis enormt mycket säkrare men vad hjälper det om det inte fungerar över huvutaget vissa?

Clarence 2009-08-22 17:13

Citat:

Originally posted by BoXon@Aug 22 2009, 16:06
Ang. detta med dynamisk IP så får jag en ny IP ungefär varje gång som jag startar om datorn.
Fast förmodligen har du samma C- eller iallafall B-klass fortfarande. Därav kan man komma jämföra mot t ex 192.168.xxx.xxx istället för 192.168.0.1 för att få en mer lagom kombination av säkerhet och användarbarhet i det som tidigare diskuterades. Denna funktion finns bland annat i Vbulletin av färdiga programvaror om jag inte minns fel. Speciellt 3g-uppkopplingar ger i min erfarenhet väldigt ofta nya IP-adresser som ligger lite längre ifrån varandra.

Draqir 2009-08-22 17:18

"Kom ihåg mig" - säkraste sättet

VPN kryptering, inbyggt tillägg som stegar igenom fördefinerade sha-256 strängar genom ett tillägg i webbläsaren som bakas in vid varje request... Ehm. En lite mer normal lösning;

Använd mcrypt med t.ex. blowfish på ett liknande sätt

Kod:

class Cookie {
  private $created;
  private $userid;
  private $version;
  private $td;
  private $cookie;

  private $cypher  = 'blowfish';
  private $mode    = 'cfb';
  private $key = 'choose a better key';

  private $cookiename = 'USERAUTH';
  private $myversion = '1';
  private $expiration = '600';
  private $warning  = '300';
  private $glue = '|';

 
  public function __construct($userid = false) {
  $this->td = mcrypt_module_open ($this->cypher, '', $this->mode, '');
  if($userid) {
    $this->userid = $userid;
    return;
  }
  else {
    if(array_key_exists($this->cookiename, $_COOKIE)) {
    $buffer = $this->_unpackage($_COOKIE[$this->cookiename]);
    }
    else {
    throw new AuthException("No Cookie");
    }
  }
  }
  public function set() {
  $cookie = $this->_package();
  set_cookie($this->cookiename, $cookie, 0);
  }
  public function logout() {
  set_cookie($this->cookiename);
  }
  public function validate() {
  if(!$this->version || !$this->created || !$this->userid) {
    throw new AuthException("Malformed cookie");
  }
  if ($this->version != $this->myversion) {
    throw new AuthException("Version mismatch");
  }
  if (time() - $this->created > $this->expiration) {
    throw new AuthException("Cookie expired");
  } else if ( time() - $this->created > $this->resettime) {
    $this->set();
  }
  }

  private function _package() {
  $parts = array($this->myversion, time(), $this->userid);
  $cookie = implode($glue, $parts);
  return $this->_encrypt($cookie);
  }
  private function _unpackage($cookie) {
  $buffer = $this->_decrypt($cookie);
  list($this->version, $this->created, $this->userid) = explode($glue, $buffer);
  if($this->version != $this->myversion ||
    !$this->created ||
    !$this->userid)
  {
    throw new AuthException();
  }
  }
  private function _encrypt($plaintext) {
  $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);
  mcrypt_generic_init ($this->td, $this->key, $iv);
  $crypttext = mcrypt_generic ($this->td, $plaintext);
  mcrypt_generic_deinit ($this->td);
  return $iv.$crypttext;
  }
  private function _decrypt($crypttext) {
  $ivsize = mcrypt_get_iv_size($this->td);
  $iv = substr($crypttext, 0, $ivsize);
  $crypttext = substr($crypttext, $ivsize);
  mcrypt_generic_init ($this->td, $this->key, $iv);
  $plaintext = mdecrypt_generic ($this->td, $crypttext);
  mcrypt_generic_deinit ($this->td);
  return $plaintext;
  }
  private function _reissue() {
  $this->created = time();
  }
 }


BjörnJ 2009-08-22 17:18

Citat:

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 2009-08-22 17:23

Citat:

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:
Citat:

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 2009-08-22 17:38

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 2009-08-22 18:28

Citat:

Ursprungligen postat av Draqir
Citat:

Originally posted by -BjörnJ@Aug 22 2009, 15:50
Citat:

Ursprungligen postat av Draqir
User agent är inte direkt alltid statiskt. Beror på vad du har för ISP, ibland kan det växla under bara ett enda request.

Hm? En ISP ändrar väl aldrig user agent i HTTP requests som går genom deras nät? Eller? (Om man inte kör via proxy förstås.)


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 2009-08-22 18:30

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 2009-08-22 18:37

Citat:

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 2009-08-22 18:43

Citat:

Ursprungligen postat av BjörnJ
Citat:

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?

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

_Michael_ 2009-08-22 19:26

Citat:

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 2009-08-22 19:27

Citat:

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:
Kod:

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
}


Citat:

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 2009-08-22 19:35

Citat:

Ursprungligen postat av _Michael_
Citat:

Ursprungligen postat av BjörnJ
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.

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.


Alla tider är GMT +2. Klockan är nu 07:08.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson