Wie würden Sie ein sicheres statisches Login-Daten-System in Java implementieren?

Question

Wir hatten kürzlich eine Sicherheitsüberprüfung und es mehrere Schwachstellen in den Systemen ausgesetzt, die hier vorhanden sind. Eine der Aufgaben, die daraus resultierten, dass wir unsere Partner Anmeldeinformationen System aktualisieren müssen, um es sicherer zu machen.

Die „alte“ Art und Weise, Dinge zu tun war, ein (sehr schlecht) Passwort zu generieren, geben Sie es an den Partner mit einer ID und dann würden sie diese ID und eine Base 64 codierte Kopie dieses Passwortes in mit all ihren XML senden Anfragen über https. Wir werden sie dann entschlüsseln und validieren.

Diese Passwörter nicht ändern wird (denn dann wäre unsere Partner müssen Codierung / config Änderungen vornehmen, sie zu ändern und zu koordinieren Passwort Exspirationen mit Hunderten von Partnern für mehrere Umgebungen wäre ein Albtraum) und sie haben nicht eingegeben werden durch einen Menschen oder Menschen lesbar. Ich bin offen, dies zu ändern, wenn es eine bessere, aber immer noch relativ einfache Implementierung für unsere Partner.

Im Grunde kommt es auf zwei Dinge: Ich habe ein sichereres Java Passwort-Generierung System benötigen und um sicherzustellen, dass sie in einer sicheren Art und Weise übertragen werden

.

Ich habe ein paar handgerollte Passwort-Generatoren, aber nichts gefunden, das wirklich als Standard Art und Weise, dies zu tun stand (vielleicht aus gutem Grund). Es kann auch ein sicherer Weg sein, um sie als 64-Codierung einfach Basis über https zu übertragen.

Was würden Sie für den Passwort-Generator tun und denken Sie, dass das Übertragungsverfahren an Ort und Stelle für sie sicher genug ist?

Edit: Die XML wird in einer SOAP-Nachricht und die Anmeldeinformationen sind in dem Header nicht in dem XML selbst. Da auch die Passwörter ein einmaliger Vorgang für jeden Partner sind, wenn wir sie einrichten wir über Effizienz des Generators nicht allzu besorgt sind.

Answer 1

Passwort-Generation

Was codiert, ein Passwort für die Übertragung, die nur Codierung, die wirklich Sicherheitsverschlüsselung ist hinzufügen. Mit Base-64 oder hexadezimal ist nicht für die Sicherheit, sondern nur in der Lage sein es in einem Textformat wie XML enthält.

Entropy wird verwendet, Kennwortqualität zu messen. Also, jedes Bit mit einem zufälligen „Coin-Flip“ Wahl gibt Ihnen das beste Qualität Passwort. Sie würden wollen Passwörter so stark wie andere kryptographische Schlüssel sein, also würde ich ein Minimum von 128 Bits der Entropie empfehlen.

Es gibt zwei einfache Methoden an, je nachdem, wie Sie das Kennwort als Text verschlüsseln wollen (die nicht wirklich von einem Standpunkt der Sicherheit aus Materie).

Base-64 , verwenden Sie so etwas wie folgt aus:

  SecureRandom rnd = new SecureRandom();
  /* Byte array length is multiple of LCM(log2(64), 8) / 8 = 3. */
  byte[] password = new byte[18];
  rnd.nextBytes(password);
  String encoded = Base64.encode(password);

Die folgenden erfordert Sie nicht mit einem Base-64-Encoder zu kommen. Die sich ergebende Codierung ist nicht so kompakt (26 Zeichen statt 24) und das Passwort nicht so viel Entropie. (Aber 130 Bits ist schon eine ganze Menge, vergleichbar mit einem Passwort von mindestens 30 von einem Menschen ausgewählt Zeichen.)

SecureRandom rnd = new SecureRandom();
/* Bit length is multiple of log2(32) = 5. */
String encoded = new BigInteger(130, rnd).toString(32); 

neue Secure Objekte zu schaffen, ist rechenintensiv, so dass, wenn Sie gehen Passwörter häufig zu generieren, können Sie eine Instanz erstellen möchten, und halten Sie es um.

Ein besserer Ansatz

das Kennwort in dem XML-Einbettung selbst scheint wie ein Fehler.

Zunächst einmal scheint es, wie Sie einen Absender authentifizieren möchte, bevor Sie Dokumente verarbeiten sie Ihnen schicken. Angenommen, ich hasse deine Eingeweide, und starten Sie Riesen-XML-Dateien Senden einer Denial-of-Service-Angriff auszuführen. Wollen Sie nur die XML zu analysieren haben, um herauszufinden, dass ich nicht ein legitimer Partner? Wäre es nicht besser, wenn das Servlet nur Anfragen abgelehnt vorne von nicht authentifizierten Benutzern?

Zweitens sind die Passwörter Ihrer berechtigten Partner wurden während der Übertragung durch HTTPS geschützt, aber jetzt sind sie wahrscheinlich gespeichert „im klaren“ auf Ihrem System irgendwo. Das sind schlechte Sicherheit.

Ein besserer Ansatz wäre Partner zu authentifizieren, wenn sie ein Dokument mit Anmeldeinformationen in den HTTP-Request-Header senden. Wenn Sie nur HTTPS zulassen, können Sie das Passwort aus dem Dokument vollständig übernehmen und es in eine HTTP "Basic" Authentifizierung Header statt. Es ist gesichert durch SSL während der Übertragung, und nicht auf Ihrem System in dem klaren gespeichert (nur speichern Sie einen Einweg-Hash für Authentifizierungszwecke).

HTTP-Basic-Authentifizierung ist einfach, breit unterstützt, und wird viel einfacher für Sie und Ihre Partner als Zertifikate SSL-Client zu implementieren.

Schutz Document Content

Wenn der Inhalt der Dokumente selbst empfindlich ist, sollte sie wirklich vom Absender verschlüsselt werden, und von Ihnen in ihrer verschlüsselten Form gespeichert. Der beste Weg, dies zu tun ist mit öffentlichen Schlüsseln, aber das wäre ein Thema für eine andere Frage sein.

Answer 2

Könnten Sie nicht SSL-Keys für die Authentifizierung verwenden?

Answer 3

Ich bin unklar, warum die Passwörter über SSL übertragen - via HTTPS - in Betracht gezogen wird „unsicher“ von Ihrem Prüfungsteam. Also, wenn Sie für zwei Dinge fragen, so scheint es, die zweiten - sicherzustellen, dass die Passwörter in einer sicheren Art und Weise übertragen werden -. Schon ganz gut gehandhabt werden

Wie bei dem ersten, würden wir müssen wissen, was über die Prüfung Ihre Passwörter als unsicher ausgesetzt ...

Answer 4

würde ich das ganze Passwort Ansatz aufgeben und beginnen Client-Zertifikate mit einem 2 Seite authentifizierten SSL-Verbindung zu ermöglichen.

Sie haben zu generieren und für jeden Kunden individuelle Zertifikate signieren. In dem SSL-Handshake, fordern Sie das Zertifikat des Clients und überprüfen Sie es. Wenn es fehlschlägt, endet die Verbindung mit einem Statuscode 401.

Zertifikate können jederzeit Ihre Seite widerrufen werden, so dass leicht ehemalige Kunden zu trennen.

Da all dies in der Handshake vor der Kommunikation geschieht, ist nicht möglich, Ihren Server mit Daten zu überfluten.