it-swarm-eu.dev

So implementieren Sie einen API-Schlüsselmechanismus

zunächst einmal: Ich bin mir über den Titel der Frage nicht sicher. Wenn Sie also eine bessere Idee haben, können Sie dies gerne mitteilen (:

Ich würde gerne Best-Practice-Beispiele kennenlernen, bei denen Dienste (wie Twitter oder Co), die APIs anbieten, und möchten, dass Sie als Entwickler einen API-Schlüssel verwenden, verhindern, dass Dritte diesen Schlüssel erhalten.

Ich werde meine Grüße mit schlechten Beispielen erklären:

Soweit ich weiß, müssen Sie für Twitter und FB API-Keys für API-Anfragen verwenden. Das ist in Ordnung für serverseitige Anwendungen, aber sobald Sie Ihren Schlüssel von einer Web-App oder Desktop-Anwendung senden, ist der Schlüssel für andere sichtbar.

Da Sie diesen Schlüssel einreichen müssen, ist es wenig sinnvoll, ihn supersicher in Ihrer App zu speichern. Für die Anfrage muss es klar sein.

Eine Möglichkeit besteht darin, Ihren eigenen Webdienst oder Wrapper zu hosten, der die Seite des Schlüsselservers anfügt und diese Anforderung dann an den Zielserver weiterleitet.

Dies ist jedoch nicht möglich, wenn Twitter/oder ein von Ihnen verwendeter Dienst die API-Anforderungen pro IP einschränkt oder IP-basierte Statistiken erstellen möchte.

m es zusammenzufassen: Wenn ich in der Lage wäre, eine API für andere zu erstellen und nicht möchte, dass sie SSL verwenden, welche Möglichkeiten hätte ich, um sicherzustellen, dass ihr Schlüssel sicher ist und nicht einfach gestohlen werden kann ?

34
user510083

Die beste Vorgehensweise ist:

Die Grundidee. Erstellen Sie für jedes separate Benutzerkonto einen API-Schlüssel (einen symmetrischen 128-Bit-Schlüssel). Dieser Schlüssel muss sicher auf dem Server und auch sicher auf dem Client des Benutzers gespeichert sein.

Fügen Sie für jede vom Client gestellte Anforderung einen zusätzlichen Anforderungsparameter hinzu, der für die gesamte Anforderung eine "Signatur" aufweist. Die "Signatur" sollte berechnet werden als S = MAC ( [~ # ~] k [~ # ~], [~ # ~] r [~ # ~]), wobei [~ # ~] k [~ # ~] der API-Schlüssel ist und [~ # ~] r [~ # ~] = ist die gesamte Anforderung einschließlich aller Anforderungsparameter. Hier sollte MAC ein sicherer Nachrichtenauthentifizierungscode-Algorithmus sein, wie z. B. AES-CMAC oder SHA1-HMAC.

Es liegt in der Verantwortung des Kunden, die Signatur zu berechnen und an die Anfrage anzuhängen. Es liegt in der Verantwortung des Servers, die Signatur zu überprüfen und Anfragen mit einer ungültigen Signatur zu ignorieren. Möglicherweise müssen Sie der Anforderung auch einen zusätzlichen Parameter hinzufügen, der das Benutzerkonto identifiziert, das die Anforderung stellt.

Dies bietet eine Authentifizierung der Anforderung, jedoch keine Vertraulichkeit oder Verhinderung der Wiedergabe, und der Client erhält eine authentifizierte Antwort vom Server.

Ich empfehle, alle Anfragen über https (nicht http) zu senden. Dies bietet ein zusätzliches Maß an Sicherheit gegen eine Reihe kniffliger Fälle. Die Auswirkungen auf die Leistung sind geringer als Sie vielleicht denken - SSL hat weniger Leistungsaufwand als die meisten Leute denken - also verwerfen Sie diese Idee nicht aus Leistungsgründen es sei denn Sie haben tatsächlich gemessen den Leistungsaufwand und fanden ihn inakzeptabel.

Zusätzliche Dinge, auf die Sie achten müssen. Möglicherweise möchten Sie eine einmalige Nonce verwenden, um die Wiedergabe authentifizierter Anforderungen zu verhindern. Ich schlage vor, einen Zufallswert mit kryptografischer Stärke (mindestens 64 Bit lang) zu verwenden. Dies ist nicht erforderlich, wenn Sie https verwenden.

Stellen Sie sicher, dass Ihr Server so geschrieben ist, dass er sich gegen HPP-Angriffe (Host-Parameter Pollution) verteidigt. Beispielsweise sollte jede Anforderung mit mehreren Anforderungsparametern desselben Typs (z. B. http://example.com/foo.html?name=x&name=y) Abgelehnt werden. Seien Sie beim Schreiben von Servercode auch vorsichtig, wenn Sie neue Anforderungen basierend auf einer empfangenen Anforderung erstellen. Beispielsweise kann Ihr Servercode vor der Verarbeitung jeder Anforderung überprüfen, ob die Anforderung nur die erwartete Liste von Parametern und nichts weiter enthält. Verwerfen Sie doppelte oder unerwartete Parameter, bevor Sie die Anforderung verarbeiten.

Achten Sie auf Verkettungsfehler , wenn Sie mehrere Werte mit dem Nachrichtenauthentifizierungscode schützen möchten.

37
D.W.