Shared Secrets

Door Sgreehder op dinsdag 16 april 2013 15:59 - Reacties (1)
Categorie: Perpetuum, Views: 2.594

Zoals beschreven in een vorige blog, worden via mijn Perpetuum-client wat gegevens verzameld die worden doorgezet naar mijn website, zodat spelers niet hoeven te zijn ingelogd om te zien wat er zoal in het spel omgaat. Inmiddels heb ik deze informatie uitgebreid. Het gaat nu om:

• Conversaties in-game channels en IRC
• Notificaties in-game channels en IRC (dit bestaat met name uit inloggen/uitloggen)
• Intrusion events (dit zijn de tijden dat player-owned outposts kwetsbaar zijn geweest en wie aanspraak heeft gemaakt op een toekomstige overname)
• Wallet-transacties

Het mag duidelijk zijn dat ik nu kan volgen wie aan mij (in-game) geld stuurt. Ik wil dit doorzetten naar een systeem waarmee in-game geld kan worden overgezet naar de website, om 'premium'-diensten af te nemen (wat dit precies gaat inhouden moet ik nog vorm geven), maar ook om leukigheidjes (zoals een lotterij) makkelijker te kunnen realiseren.

Met dat soort faciliteiten begint het dus ook interessanter te worden om misbruik te maken van de website. Het systeem wat ik gebruik om de gegevens door te zetten is momenteel gebaseerd op een POST request via cURL. Een IP-check lijkt mij in elk geval niet betrouwbaar genoeg om na te gaan of nieuwe data daadwerkelijk van mijn computer afkomt. Een mogelijkheid is HTTP basic access authentication, maar ik gebruik momenteel shared-hosting waarbij SSL niet mogelijk is, dus waterdicht is het dan zeker niet. Er is gelukkig een goed alternatief: keyed-hash message authentication code, of HMAC.

HMAC functioneert op basis van een hash-algoritme (zoals SHA512), waarmee de te sturen data in combinatie met een 'shared secret' (een sleutel) kan worden gehashed naar een MAC (message authentication code). De server ontvangt daarop de data met aantekening (signature), en vergelijkt de MAC op basis van de gedeelde sleutel. Als deze hetzelfde is, wordt de data goedgekeurd voor verwerking.

Het versturen van de data:


code:
1
2
3
4
5
$data = serialize($transfers);
$hmac = hash_hmac('sha512', $data, $sharedSecret);

curl_setopt($ch, CURLOPT_URL, $transfersUpdateURL . '&sign=' . urlencode($hmac));
curl_setopt($ch, CURLOPT_POSTFIELDS, ('transfers=' . urlencode($data)));



En het controleren van de afkomst aan de andere kant:


code:
1
2
3
4
5
$signature = isset($_GET['sign']) ? $_GET['sign'] : '';
$hmac = hash_hmac('sha512', $_POST['transfers'], $config['shared-secret']);
if ($hmac !== $signature) { 
    exit;
}



De voornaamste kwetsbaarheid tegen HMAC is een brute-force aanval (met de lengte van de keys al een aardige opgave op zichzelf), maar dit kan eventueel eenvoudig worden opgelost met een SSL-verbinding.

Volgende: Livestream 'coding jam' 04-'13 Livestream 'coding jam'

Reacties


Door Tweakers user Eagle Creek, woensdag 17 april 2013 09:18

Als jij SHA512 gebruikt met een fatsoenlijk lange key (die je dan ook nog eens af en toe een schop geeft), denk ik dat er weinigen zijn die de tijd/zin/resources hebben om die te gaan kraken.

Wel leuke oplossing trouwens, heb het nog niet eerder voorbij zien komen :). (althans, niet als oplossing voor een dergelijk probleem)

Reageren is niet meer mogelijk