[SimonP]

Ursprungligen postat av Onkelborg

Mja, alltså, det är något sådant jag tänker. Nyckeln ska vara slumpmässig, skulle användaren tappa bort sin nyckel så genererar man bara en ny. Nyckeln bör vara sparad hashad på servern.
Att börja greja med datum och hasha en nyckel känns overkill, man kommer fortfarande inte ifrån problemet med att nyckeln finns fullt läsbar i klienten.

Fast tanken är att man ska skydda trafiken, att skydda data som finns lokalt på klientens dator är en annan avdelning.

Om man skyddar själva överföringen mellan klient och server med SSL så fyller ett sådant hash ingen funktion.

Jo, det gör det, serverloggarna kommer bara att innehålla en engångsnyckel, inte nån permanent fungerande nyckel. HTTPS skyddar inte loggarna vid GET anrop.

Däremot, om man inte nyttjar SSL så kan det finnas en poäng med hashad nyckel. Det skyddar dock bara mot framtida attacker

Nej, det skyddar både framtida och gamla, så länge det förflutit X antal minuter i tid, eftersom man hashat med en tidsstämpel/datum.

en attack som man-in-the-middle är dock fortfarande utsatt - bara att ändra innehållet on-the-fly. (Även om det går att skaffa sig skydd där också: signera all data som skickas över med nyckel + datum, kontrollera på servern..)

En nyckel som man hittar genom en MITM attack kommer bara att fungera under en begränsad tid, eftersom man hashar allt tillsammans med datumstämpeln. En MITM kan inte ändra innehållet on-the-fly eftersom han inte vet userkey:n som genererade den slutliga hashsumman.

Jag tror det är dags att förklara förslaget lite bättre, åtminstone det protokoll som jag tänkt mig:

Serverns databas innehåller:
-UserID = en vanlig unik counter
-userkey = en lång slumpmässigt genererad "nyckel"

Klienten skickar detta:
GET domain?UserID=1234&requestKey=BBBBBBBBBBBBBBBBBBBB &timezone=4

"requestKey" skapas genom SHA1(userkey+datumstämpel) på klientsidan. Här får inte datumstämplarna vara för hårt satta, klientens klocka kan diffa med många minuter, kanske en stämpel som innehåller YYYYMMDDHH eller ännu mer noggrannt, men allt beror på klienterna och vilka krav man har. Serverns klocka synkas enkelt med NTP, så den går alltid rätt.

Servern verifierar med denna pseudokod:
$time=time(YYYYMMDDHH)(+-timezone);
$userkey = hämtas ifrån databasen, UserID används för att söka
if (requestKey == SHA1($userkey+$time) process_client_request();
else die("Wrong passhash or wrong timestamp!");

Summering:
-Userkey skickas aldrig i klartext
-Det går ej att modifiera keys som blivit sniffade
-Sniffade nycklar fungerar bara under en kort period
-Genom att lägga på SSL försvårar man avlyssning (men det är knappt värt det eftersom man ändå använder tidsbegränsade nycklar)
-SQL injections är egentligen det enda farliga hotet utifrån, men det är mkt enkelt att skydda sig mot genom att filtrera indata
-Säkerheten går som sagt att förbättra ytterligare genom att lägga på en IP-nr koll, men det beror på hur systemet skall användas om det fungerar eller ej