[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

[BjörnJ]

Ursprungligen postat av SimonP

GET domain?UserID=1234&requestKey=BBBBBBBBBBBBBBBBBBBB &timezone=4

timezone behövs inte om man har specat att tiden alltid ska anges i UTC, eller om man använder sig av unix timestamp oformaterad (som ska vara lika hos klient och server även om det är olika tidszoner).

Ursprungligen postat av SimonP

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!");

Här har man problemet att man kan få "false negative" om t.ex. klientens tid är 20090901055959 och serverns tid är 20090901060000. I mitt exempel löste jag det genom att även kolla tiden +/-1 om den första hashen inte matchar.

[SimonP]

Ursprungligen postat av BjörnJ

timezone behövs inte om man har specat att tiden alltid ska anges i UTC, eller om man använder sig av unix timestamp oformaterad (som ska vara lika hos klient och server även om det är olika tidszoner).

Just ja, det verkar fungera, trodde att det skulle bli problem med sommartid då, men att köra UTC är bättre och enklare.

Här har man problemet att man kan få "false negative" om t.ex. klientens tid är 20090901055959 och serverns tid är 20090901060000. I mitt exempel löste jag det genom att även kolla tiden +/-1 om den första hashen inte matchar.

Sjävklart måste man ta hänsyn till detta, det var därför jag fetmarkerade ordet pseudokod, det var ingen fullständig kod.

[Onkelborg]

Nje, det där köper jag inte. Du har inget skydd mot MITM-attacker med ditt förslag. Och jag tycker inte att det är en bra idé att ha nyckeln fullt läslig i serverns databas, vid ev. intrång (även om det kanske bara blir en dumpning av databasen) så blir skadan lätt stor iom. fullt läsliga nycklar, som då även fungerar till api:t.

För att få ofarliga url:er i loggen är det ju bara att lägga auth i någon header istället för i url:en.

Att börja knöla med tidsbegränsade hash skulle väl möjligtvis vara om man saknar ssl, men då tycker jag iofs. att man kanske borde börja fundera på en lösning med public/private key istället.. RSA?

[SimonP]

Ursprungligen postat av Onkelborg

Nje, det där köper jag inte. Du har inget skydd mot MITM-attacker med ditt förslag.

Jo, läs igen, skyddet ligger i att MITM inte kan sniffa nycklar som fungerar någon längre tidperiod, om man tillåter klientens klocka att diffa 20 minuter så kommer nyckeln bara att fungera i 20 minuter. MITM kan heller inte generera egna nycklar.

Och jag tycker inte att det är en bra idé att ha nyckeln fullt läslig i serverns databas, vid ev. intrång (även om det kanske bara blir en dumpning av databasen) så blir skadan lätt stor iom. fullt läsliga nycklar, som då även fungerar till api:t.

Vid ett riktigt intrång i servern har dom full kontroll ändå. Eftersom userkeys är slumpmässiga nummer är skadan inte så stor, bara att generera nya nycklar till användarna. Det är ju inte direkt några kreditkortsnr som lagras i userkeys. Sen är det är oftast lättare att avlyssna trafik än att göra intrång i en server.

Att börja knöla med tidsbegränsade hash skulle väl möjligtvis vara om man saknar ssl, men då tycker jag iofs. att man kanske borde börja fundera på en lösning med public/private key istället.. RSA?

Att använda SSL belastar servern mkt mer och kostar även pengar, om man kan hitta ett sätt som skyddar tillräckligt utan SSL är det bra. Sen är SSL inte supersäkert heller:
http://www.computerworld.com/s/artic...urity_protocol

Det är väldigt många som gör misstaget att enbart förlita sig på SSL, bättre att först bygga säkerhet så långt det går utan SSL, och sen kan man lägga på SSL som ett ytterligare skydd.

[Onkelborg]

Nej, MITM kommer inte sniffa nycklar som gäller ett bra tag, det vet jag, men nycklarna gäller _nu_. Om man som MITM vet exakt vad man vill uträtta så är det bara att hänga på låset.. När nyckeln kommer så kör man.

[SimonP]

Ursprungligen postat av Onkelborg

Nej, MITM kommer inte sniffa nycklar som gäller ett bra tag, det vet jag, men nycklarna gäller _nu_. Om man som MITM vet exakt vad man vill uträtta så är det bara att hänga på låset.. När nyckeln kommer så kör man.

Det är stor skillnad på att få tag på en nyckel/lösenord som fungerar permanent och få tag på en som bara fungerar en kort period. Varje gång som MITM kopplar in sig ökar risken för upptäckt.

[Onkelborg]

Klart risken ökar, men det är fortfarande inte säkert. Vem man vad man vill göra så spelar det ingen roll om man får tag på en nyckel som fungerar 30 sekunder till eller en som fungerar i all evighet.

Vill man skippa ssl så föreslår jag rsa eller något liknande

[SimonP]

Ursprungligen postat av Onkelborg

Klart risken ökar, men det är fortfarande inte säkert. Vem man vad man vill göra så spelar det ingen roll om man får tag på en nyckel som fungerar 30 sekunder till eller en som fungerar i all evighet.

Det finns inget som är 100% säkert. Men vi har olika syn på säkerhet, själv föredrar jag när man gjort så mkt som man kan för att för att försvåra för en eventuell attack.

[Onkelborg]

Jag har iofs samma åsikt, därav att jag inte skulle nöja mig med att hasha ihop nyckel och tid..