[Onkelborg]

Ursprungligen postat av BjörnJ

Om man vill skicka nyckeln hashad (t.ex. sha1(datum + nyckel)) måste man väl spara den i klartext på serversidan. Finns det några bra sätt att skydda nyckeln på serversidan? Det går ju att få lite extra skydd genom att spara den krypterad i databasen och ha en statisk nyckel i skriptet, men frågan är om det är värt besväret.

I det här fallet bör man nog skapa en nyckel automatiskt, och inte låta användaren ändra nyckel på annat sätt än att skapa en ny slumpmässig nyckel. Detta för att dels få en stark nyckel, och dels för att skydda användaren; det är inte möjligt att ange en nyckel (som sparas i klartext hos både klienten och servern) som användaren använder på något annat ställe. Denna nyckel används enbart för api. För vanlig inloggning används ett annat lösenord på vanligt sätt.

Om man använder datum som salt, tänk på att klienten och servern ska ange datumet enligt samma tidszon.

Vad sägs om en lösning i stil med följande?
$salt=round(timestamp/100);
User-id samt sha1($salt + nyckel) skickas som http auth.

Det kräver att klockorna på båda sidor går någorlunda rätt. För ökad säkerhet, dela med 10 istället om man är säker på att klockorna går nästan exakt rätt.

Servern kontrollerar:
$salt=round(timestamp/100);
if($http_pass==sha1($salt + nyckel) || $http_pass==sha1(($salt+1) + nyckel) || $http_pass==sha1(($salt-1) + nyckel))

Alternativ:
Använd hela timestamp som salt. Skicka med även salt i requesten (tillsammans med user-id och hash). Servern kontrollerar att salt inte skiljer sig för mycket från aktuell timestamp.

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. Om man skyddar själva överföringen mellan klient och server med SSL så fyller ett sådant hash ingen funktion.

Däremot, om man inte nyttjar SSL så kan det finnas en poäng med hashad nyckel. Det skyddar dock bara mot framtida attacker, 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..)

Personligen så tror jag dock att det inte är så realistiskt att man kan räkna med att klockorna går särskilt rätt i båda ändarna..

Kan man köra med SSL så fixar man många problem