API Authentifizierung Design und Hackbarkeit

Question

Frage: Ist diese API-Authentifizierungstechnik leicht hackbar?

apiKey = "123456789" 
apiCallId = "1256341451" 
apiSecret = "67d48e91ab2b7471d4be2a8c2e007d13" 
sig = md5(apiKey + apiCallId + apiSecret) = 09c297a354219f173bfc49c2e203ce03 

wo

• apiKey: einige eindeutige Kennung für den Benutzer
• apiCallId: eine eindeutige ganze Zahl, die im Wert (zB UNIX Zeitstempel) zuzunehmen muss
• apiSecret: string nur bekannt an den Benutzer und uns - nicht in URL übergeben
• sig: "unhackable" Signatur dieses API-Aufrufs - MD5 Hash

Beispiel API-Aufruf:

http://api.domain.com/?apiKey=123456789&apiCallId=1256341451&sig=09c297a354219f173bfc49c2e203ce03&param1=x&param2=y 

Diese API erfordert keine Sitzung, und ist nicht für eine dritte Partei im Namen eines Benutzers zu verwenden entworfen. Stattdessen soll es vom Benutzer selbst verwendet werden.

Ich mag die Einfachheit dieser. Die Anforderung von apiCallId ist einzigartig, und immer zu erhöhen bedeutet eine sig Wiederverwendung ist nicht möglich, so dass ich fühle, wie es sicher ist (geschützt gegen Replay-Attacken), aber ich bin kein Experte.

Andere APIs verwenden alle GET-Parameter alphabetisch sortiert bei der Berechnung der sig, aber ich sehe nicht, warum dies erforderlich ist, wenn apiCallId.

Bitte versuchen Sie dies zu hacken, bevor es implementiert und freigegeben wird.

Ich freue mich über Feedback, Anregungen und Sicherheit Bildung.

Answer 1

Was Sie tun, scheint ziemlich vernünftig zu sein, außer die Parameter nicht zu überprüfen (was ein ziemlich großes Problem sein wird).

Etwas, das zu Ihrem Design sehr ähnlich ist, die es klug sein könnte, ist die für die Parameter Amazon Web Services Request Authentication Scheme

Insbesondere stellen Sie sicher, Ihr Codierungsschema ist eindeutig und umkehrbar zu kopieren; Amazon screwed this up an einem Punkt. Lerne aus ihren Fehlern. :)

Kryptographisch gesprochen, was Sie tun, heißt nicht eine Signatur, sondern eine Nachricht Authentifizierung (MAC). Ein MAC kann von jedem, der den geheimen Schlüssel teilt, erstellt und verifiziert werden (der Begriff "Signatur" ist normalerweise für Public-Key-Systeme wie DSA oder RSA reserviert). MD5 (msg || K) ist ein bekannter und einigermaßen gesunder MAC; Ich bin mir nicht sicher, ob Sie es zufällig oder absichtlich verpasst haben, aber eine Methode, die an der Oberfläche als äquivalent erscheint, MD5 (K || msg), ist ziemlich unsicher, weil sie eine Art von MD5 (und den meisten anderen Hashs) ist Funktionen) sind so ausgelegt, dass, wenn Sie H (m) kennen, H (m || m2) für jedes m2 einfach berechnet werden kann - wenn Sie also MD5 (K || param1 = 5) verwenden, kann jemand das Kabel abziehen und dann MD5 erstellen (K || param1 = 5, param2 = 666). (Es ist vielleicht ein bisschen technischer als Sie interessiert sind, aber das nennt man die length extension property).

Obwohl MD5 (K || msg) wahrscheinlich "gut" ist, ist es besser, etwas wie HMAC zu verwenden, weil es eigentlich als MAC entworfen wurde. MD5 hat viele Probleme, aber nichts beeinflusst seine Verwendung als MAC (noch ist MD4 auf diese Weise kaputt gegangen). Verwenden Sie daher für die Zukunftssicherung (und für das Revisions-Audit) HMAC mit SHA-1 oder SHA-256. Auch wenn Sie keine Crypto-Bibliothek verwenden möchten, ist HMAC ziemlich einfach und es sind bekannte Werte für SHA-1 und SHA-2 verfügbar, so dass Sie Ihren Code überprüfen können.

Answer 2

Nun nehme ich an, ich kannte das Geheimnis, dann könnte ich das Sig generieren und weitergeben. Was für eines meiner Startups getan hat, ist die Sig Param noch weiter zu nehmen, indem die Sig auf die anderen Parameter und auch eine RequestID (UUID) und Zeitstempel setzen und diese UUID speichern (Sicherheitsgründe für ein paar Stunden, um den Hacker zu verleugnen) die gleiche Funktion immer wieder aufrufen). Auf diese Weise können Sie den gleichen Aufruf nicht erneut aufrufen, Sie müssten eine neue UUID generieren und wenn der Hacker die UUID im Param ersetzt, macht das Sig ungültig, und er weiß nicht, wie man das Sig generiert, weil wir anders als geheim sind Erzeugen einer Signatur basierend auf einem internen Schlüssel, der 30 Zeichen lang ist. So essenity

MD5 (alphabetische Liste von Param + apikey + CallID + secert + someLonginternalKey)

nicht sicher, ob ich Ihre Frage beantwortet, aber das ist eine andere Möglichkeit, die Sicherheit zu tun für api

Answer 3

Nein. Die Integrität der anderen Parameter (param1 und param2 in Ihrem Beispiel) ist nicht geschützt. Ein Angreifer kann den Anruf abfangen und nach Belieben ändern, bevor er weitergeleitet wird. Die apiCallId verhindert nur Wiederholungen, keine Änderung des ersten Anrufs.

Ich bin kein Experte. Wenn ich das sofort sehe, lauern wahrscheinlich andere Probleme.

Answer 4

Ich würde vorschlagen, digitale Signaturen in diesem Fall zu verwenden, da sie besser geeignet sind. Eine digitale Signatur zum Beispiel über den Apikey ist mehr als genug. Du brauchst nicht einmal das Apisekret und das Hash davon. Sie müssen nur sicherstellen, dass die digitale Signatur privat bleibt (genau wie der MD5-Hash).

Wenn Sie Replay-Attacken verhindern möchten, benötigen Sie bei jeder Anfrage irgendeine Art von Zufälligkeit. So würde ich vorschlagen, die folgende:

Server -> API: Nonce (= einige Zufallszahl)

API -> Server: Enc (nonce + digitale Signatur)

dies ist verschlüsselt mit dem öffentlichen Schlüssel des Servers und die digitale Signatur wird mit dem privaten Schlüssel des Servers platziert.

Jetzt können Sie keine Replay-Attacke mehr haben. Allerdings gibt es immer noch das Problem eines Mannes in der Mitte Angriff, aber das zu beheben ist nicht so trivial (aber durchaus machbar). Je nach Sicherheitsstufe können Sie Ihre technischen Maßnahmen anpassen.