Frage: Ist diese API-Authentifizierungstechnik leicht zu hacken?
%Vor%wo
apiKey : Eine eindeutige ID für den Benutzer apiCallId : Eine eindeutige Ganzzahl, deren Wert ansteigen muss (z. B. UNIX-Zeitstempel) apiSecret : Zeichenfolge, die nur dem Benutzer bekannt ist, und uns - nicht in URL übergeben sig : "unhackable" -Signatur dieses API-Aufrufs - MD5-Hash Beispiel API-Aufruf:
%Vor%Diese API erfordert keine Sitzung und ist nicht für die Verwendung durch Dritte im Namen eines Benutzers vorgesehen. Stattdessen sollte es vom Benutzer selbst verwendet werden.
Ich mag die Einfachheit sehr. Die Anforderung von apiCallId ist einzigartig, und immer zu erhöhen bedeutet, dass die Wiederverwendung von sig nicht möglich ist, also fühle ich mich wie sicher (geschützt vor Replay-Angriffen), aber ich bin kein Experte.
Andere APIs verwenden alle GET-Parameter, die beim Berechnen von sig alphabetisch sortiert sind, aber ich sehe nicht, warum dies erforderlich ist, wenn apiCallId eingeschlossen ist.
Bitte versuchen Sie dies jetzt zu hacken, bevor es implementiert und freigegeben wird.
Ich begrüße jedes Feedback, Vorschläge und Sicherheitserziehung.
Was Sie tun, scheint einigermaßen gesund zu sein, außer dass Sie die Parameter nicht überprüft haben (was ein ziemlich großes Problem sein wird).
Etwas, das Ihrem Design sehr ähnlich ist und das Sie vielleicht kopieren sollten, ist das Amazon Web Services Request Authentication Scheme
Stellen Sie insbesondere sicher, dass Ihr Codierungsschema für die Parameter eindeutig und invertierbar ist; Amazon hat dies an einem Punkt vermasselt . Lerne aus ihren Fehlern. :)
Kryptografisch ausgedrückt heißt das, was Sie tun, nicht eine Signatur, sondern ein Message Authentication Code (MAC). Ein MAC kann von jedem, der den geheimen Schlüssel teilt, erstellt und verifiziert werden (der Ausdruck "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 Länge Erweiterungseigenschaft ).
Aber während 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. Selbst wenn Sie keine Cryptobibliothek aufrufen möchten, ist HMAC ziemlich einfach und es gibt bekannte Werte für SHA-1 und SHA-2 , damit Sie Ihren Code überprüfen können.
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. Der apiCallId verhindert nur Wiederholungen, keine Änderung des ersten Anrufs.
Ich bin kein Experte. Wenn ich das sofort sehe, lauern wahrscheinlich andere Probleme.
Nun, angenommen, ich kannte das Geheimnis, dann könnte ich das Sig erzeugen 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 essence
MD5 (Alphabetische Liste der Params + APiKEY + AnrufID + Secert + someLonginternalKey)
nicht sicher, ob ich deine Frage beantwortet habe, aber das ist eine andere Art, Sicherheit für api zu machen
Ich würde vorschlagen, in diesem Fall digitale Signaturen zu verwenden, da sie geeigneter 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 wollen, benötigen Sie bei jeder Anfrage irgendeine Art von Zufälligkeit. Also würde ich Folgendes vorschlagen:
Server - & gt; API: Nonce (= irgendeine Zufallszahl)
API - & gt; Server: Enc (nonce + digitale Signatur)
Dies ist mit dem öffentlichen Schlüssel des Servers verschlüsselt und die digitale Signatur wird mit dem privaten Schlüssel des Servers platziert.
Jetzt können Sie keine Wiederholungsangriffe 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.
Tags und Links security api authentication cryptography