2012-05-15 12 views
5

Ich arbeite an einer Open-Source-Javascript-Anwendung Ich versuche, mit einer API von Drittanbietern (Github speziell) zu interagieren. Ich versuche, meine gesamte Anwendung nur auf der Client-Seite zu halten, so dass ich wirklich keinen Server habe, auf den ich zurückgreifen könnte, um versteckte Dateien zu speichern. Als Teil des OAuth-Prozesses muss ich den geheimen Schlüssel bereitstellen, der für meinen API-Schlüssel bereitgestellt wird. Ich soll diesen Schlüssel nicht veröffentlichen oder teilen.Ausblenden geheimer Schlüssel im öffentlichen Repository

Ich habe mit folgenden Lösung gekommen:

  1. Verschlüsseln des geheime Schlüssel Triple-DEN und mit einem Passwort.
  2. Legen Sie die verschlüsselte Version irgendwo in mein Repository.
  3. Wenn ich über Oauth authentifizieren muss, zur Eingabe der Passphrase auffordern und den geheimen Schlüssel wiederherstellen.
  4. Sobald bekannt, speichern Sie das Geheimnis im lokalen Speicher, um zukünftige Eingabeaufforderungen zu vermeiden.

Ich speichere im Wesentlichen eine transformierte Version des geheimen Schlüssels. Ich denke, das alles kauft mich ist, dass ich die Passphrase vom Benutzer anstelle des vollen Schlüssels erhalten muss. Es sollte ein wenig leichter zu merken sein als zufällige Bytes.

Ist das sicher genug? Es ist keine überkritische App, aber ich möchte mein Bestes tun, um Dinge zu schützen, die ich nicht teilen soll. Gibt es einen besseren Weg als 3DES, den Schlüssel reversibel zu verschlüsseln?

+0

Es stellt sich heraus, dass clientseitiges OAuth aus diesem Grund sowieso nicht von github unterstützt wird. Sie wollen nicht, dass geheime Schlüssel angezeigt werden. Könnte immer noch nützlich sein, wenn man mit weniger wählerischen Apis zu tun hat. – captncraig

+0

Ich verstehe das Szenario nicht wirklich. Versuchen Sie, den Schlüssel von Benutzer github zu verbergen, obwohl sie den Client ausführen, der den Schlüssel verwendet? Wenn ja, kannst du es nicht sicher machen; Ein bestimmter Benutzer wird immer in der Lage sein, diesen Schlüssel wiederherzustellen, und aus ethischer Sicht sollten Sie nicht versuchen, auf einer Maschine gespeicherte Informationen vor seinem Besitzer zu verbergen. Wenn jeder Benutzer seinen eigenen GitHub-Schlüssel erhält und Sie nur nach einer bequemeren Möglichkeit suchen, sich daran zu erinnern, ist Ihre Lösung gut. – erickson

Antwort

2

Das klingt mehr als ausreichend, um etwas geheim zu halten; obwohl Triple DES ein wenig veraltet ist.

Ich würde X Runden von SHA-256 verwenden, um die Passphrase zu hashen, dann verwenden Sie diesen Hash als AES-256-Schlüssel.

+0

Oder verwenden Sie einfach eine Bibliothek wie [SJCL] (https://crypto.stanford.edu/sjcl/), die einen Algorithmus bereitstellt, der so funktioniert, wie Sie ihn vorgestellt haben. Wenn es um Kryptographie geht, führt die Implementierung von etwas selbst oft zu Sicherheitsproblemen. – Robert

+1

Verwenden Sie nicht einfach SHA-256, verwenden Sie einen echten Schlüsselableitungsalgorithmus (wie PBKDF2), der gut entworfen und überprüft wurde. Zum Beispiel sollte die Schlüsselableitung Salz verwenden. – erickson

5

Das Problem mit dieser Lösung ist, dass die Anwendung den Code (und möglicherweise den Schlüssel) enthalten muss, um sie zu entschlüsseln. Die beste Lösung ist es, das Repository überhaupt nicht anzulegen.

Die meisten Anwendungen speichern diesen Datentyp in einer Konfigurationsdatei, die von der Versionskontrollsoftware ignoriert wird. Fügen Sie dann eine Beispielkonfigurationsdatei mit einem falschen Schlüssel und Anweisungen zum Umbenennen der Datei und zum Erwerb eines eigenen API-Schlüssels ein.

Ein gutes Beispiel dafür ist in wordpress's config file in den "Authentication Unique Keys and Salts." Sektion.

+0

Beim Hosting auf GitHub-Seiten ist das Repository die Bereitstellung. Es gibt keine Möglichkeit, die beiden zu trennen. – captncraig

+0

Das ist ein interessantes Problem, ich denke, es gibt keinen guten Weg, um den Schlüssel zu sichern. Das bedeutet, dass Sie mit Minderung bleiben. Behalten Sie einen separaten Schlüssel für diese Anwendung bei.Wenn es kompromittiert wird, können Sie es verwerfen, ohne andere Anwendungen zu beeinträchtigen. – AaronAsAChimp

Verwandte Themen