[Onkelborg]

Jag är kluven, ur säkerhetsperspektiv är det nog bäst att bara fylla i användarnamn och ingenting mer, men å andra sidan.. Det är väldigt smidigt när man slipper logga in i tid och otid

[Draqir]

Originally posted by MMC@Aug 22 2009, 18:28
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).

Många modempooler kör med det fortfarande. I Sverige är det dock ovanligt, de flesta av oss har bredband.

[Onkelborg]

[Forumbugg]

[SimonP]

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

Risken att hackern använder samma IP range är väldigt liten, men det spelar ingen roll, så länge inte hackern har fått tag i cookievärdet är det i praktiken helt omöjligt att gissa sig till cookien, det räcker då med en slumpmässig kod, IP-nr och User agent är inte till för detta.

Problemet är att XSS-hål är vanliga, väldigt många sidor har sådana hål. Det jag pratar om är om hackern lyckats få tag i cookien via XSS, det är då som det viktigt att cookien är knuten till ett IP.

Att enbart banna IP-nr är också fel, därför att det är enkelt att byta IP-nr och fortsätta en wordlist/bruteforce attack ifrån ett nytt fräscht IP nr.
Nej ,det är kontot som skall låsas vid X antal felaktiga inloggningsförsök, och efter XX antal minuter blir det automatiskt upplåst, precis som dom flesta bankerna har det, även dom bättre forumen fungerar på detta sätt, t.ex. vBulletin.

[dotvoid]

Lång diskussion. Och jag som trodde enda skillnaden var att man satte olika livslängd på sessionen beroende på om användare kryssar i "kom ihåg mig" eller inte...

[SimonP]

Originally posted by dotvoid@Aug 24 2009, 13:19
Lång diskussion. Och jag som trodde enda skillnaden var att man satte olika livslängd på sessionen beroende på om användare kryssar i "kom ihåg mig" eller inte...

Trådskaparen använde ordet "säkraste", det hade varit mkt enklare annars...

[dotvoid]

Fast hittills har det bara diskuterats två olika sätt att använda cookies. Antingen direkt eller indirekt via den inbyggda sessionshanteringen.

Det är meningslöst att ha två parallella sessioner där den ena sessionen används för att skapa den andra. Det i sig tillför ingen säkerhet alls. Tvärtom.

Att kontrollera annan data i tillägg till det cookievärde som sätts direkt eller indirekt, som t ex user agent, tillför lite men inte mycket. Att kontrollera ip tillför mer men innebär också vissa nackdelar med de som sitter bakom proxykluster som ovan nämnts. T ex i USA har det sistnämnda varit ett stort problem iom främst America Online.

Så länge man använder sig av cookies för sessionshanteringen är det enda man kan göra för att öka säkerheten att i övrigt på webbsajten jobba hårt för att användarens cookie-värden inte kan läcka till tredje part. Det kräver mycket och noggrant arbete.

Räcker inte den säkerheten återstår bara att övergå till https.

[SimonP]

Originally posted by dotvoid@Aug 24 2009, 14:53
Att kontrollera ip tillför mer men innebär också vissa nackdelar med de som sitter bakom proxykluster som ovan nämnts. T ex i USA har det sistnämnda varit ett stort problem iom främst America Online.

Visst, om besökaren får väldigt spridda IP nr blir det förstås problem, om det t.ex bara handlar om olika klass C nät går det att lösa.

Om man inte behöver en "serverside-kom-ihåg"-funktion bör man alltid lägga på en IP-nr-koll i sessionhanteringen, eftersom användaren då loggar in varje gång får den nystartade sessionen rätt IP att hålla reda på.

[dotvoid]

Återigen. Det finns mycket stora ISP som faktiskt ändrar subnet mitt i sessioner. Återigen kan jag peka på AOL som ett bra exempel. Det finns fler. Därmed måste man vara medveten att detta förr eller senare kan komma att sätta krokben för någon (eller flera) användare. Sedan får man själv sätta det i relation till vad man uppnår.

Dessutom förstår jag inte vad en "serverside-kom-ihåg"-funktion innebär. Server-side till skillnad mot vad? Sessioner hanteras normalt genom att man skapar en cookie med ett värde (sessionsid) som unikt identifierar en unik user agent (en användare/webbläsare). Cookien lagras hos klienten. Det värdet associerar man med viss data man sparar på servern, antingen i filer, arbetsminne eller databas. Att spara icke-kritisk data direkt i en cookie är ok men inte kritisk data som sessiondata eller inloggningsuppgifter. (Det andra sättet är att lägga ett sessionsid direkt i url:en men det är en sämre lösning och diskuteras inte).

Något annat som kan diskuteras är att många webbläsare har funktionalitet för att komma ihåg formulärdata och därmed kan fylla i ett loginformulär åt dig. Det har inget med sessioner att göra.

Jag tror nog det är läge att läsa på lite. Exempelvis är Chris Schifletts genomgång väldigt grundlig.
http://shiflett.org/articles/the-truth-about-sessions
http://shiflett.org/articles/session-hijacking

[SimonP]

Återigen. Det finns mycket stora ISP som faktiskt ändrar subnet mitt i sessioner. Återigen kan jag peka på AOL som ett bra exempel. Det finns fler. Därmed måste man vara medveten att detta förr eller senare kan komma att sätta krokben för någon (eller flera) användare. Sedan får man själv sätta det i relation till vad man uppnår.

Om dom får nytt IP mitt under sessionen får dom logga in igen, många sidor som har verkligt höga krav på säkerhet gör så. Om det skulle vara så att man har en ISP som byter IP väldigt ofta, t.ex AOL så är det bara att skippa IP-nr koll på dessa, det är ändå få ISP som byter IP så ofta.

Något annat som kan diskuteras är att många webbläsare har funktionalitet för att komma ihåg formulärdata och därmed kan fylla i ett loginformulär åt dig. Det har inget med sessioner att göra.

Jag har inte sagt att det är en session heller, jag menade att det är ett annat alternativ.

Jag tror nog det är läge att läsa på lite. Exempelvis är Chris Schifletts genomgång väldigt grundlig.
http://shiflett.org/articles/the-truth-about-sessions
http://shiflett.org/articles/session-hijacking

Läs kommentarerna till artikeln på denna sida:
http://shiflett.org/articles/session-hijacking
Flera som anser att IP-nr koll är det enda säkra.
Prova logga in på en svensk bank, byt sen IP och se vad som händer.