Frage Ist UUID.randomUUID () für die Verwendung als Einmalpasswort geeignet?


Wie zuvor besprochenBestätigungsmails sollten einen eindeutigen, (praktisch) nicht erratenen Code haben - im Wesentlichen ein einmaliges Passwort- im Bestätigungslink.

Die UUID.randomUUID () -Dokumente sagen:

Die UUID wird unter Verwendung eines kryptographisch starken Pseudozufalls erzeugt   Zahlengenerator.

Bedeutet dies, dass der UUID-Zufallsgenerator in einer ordnungsgemäß implementierten JVM für die Verwendung als das einzigartige, (praktisch) nicht erratene OTP geeignet ist?


21
2018-06-14 02:57


Ursprung


Antworten:


Nein. Entsprechend der UUID-Spezifikation:

Gehen Sie nicht davon aus, dass UUIDs schwer zu erraten sind. Sie sollten nicht als verwendet werden   Sicherheitsfähigkeiten (Identifikatoren, deren bloßer Besitz gewährt   Zugang), zum Beispiel. Eine vorhersehbare Zufallszahlenquelle wird sich verschärfen   die Situation.

Außerdem haben UUIDs nur 16 mögliche Zeichen (0 bis F). Sie können ein viel kompakteres und explizit sicheres zufälliges Passwort mit Hilfe von erzeugen SecureRandom (Danke an @erickson).

import java.security.SecureRandom;
import java.math.BigInteger;

public final class PasswordGenerator {
    private SecureRandom random = new SecureRandom();

    public String nextPassword() {
        return new BigInteger(130, random).toString(32);
    }
}

4
2017-10-16 03:50



wenn du das liest RFC das definiert UUIDs, und die mit den API-Dokumenten verknüpft ist, werden Sie sehen, dass nicht alle Bits der UUID tatsächlich zufällig (die "Variante" und die "Version" sind nicht zufällig). also sollte eine UUID vom Typ 4 (die Art, die Sie verwenden wollen), wenn sie korrekt implementiert wird, 122 Bits von (sicherer, für diese Implementierung) zufälliger Information von einer Gesamtgröße von 128 Bits haben.

also ja, es wird genauso gut funktionieren wie eine 122 Bit Zufallszahl von einem "sicheren" Generator. aber Ein kürzerer Wert kann eine ausreichende Menge an Zufälligkeit enthalten und für einen Benutzer möglicherweise einfacher sein (vielleicht bin ich die einzige altmodische Person, die immer noch E-Mails in einem Terminal liest, aber Bestätigungs-URLs, die sich über die Zeilen erstrecken, sind ärgerlich ....).


14
2018-06-14 03:17



Ja, mit a java.util.UUID ist gut. Es gibt nicht viel mehr, was gesagt werden muss.

Hier ist mein Vorschlag:

  1. Senden Sie dem Benutzer einen Link mit einem riesigen Passwort als URL-Argument.
  2. Wenn der Benutzer auf den Link klickt, schreiben Sie Ihr Back-End, damit festgestellt wird, ob das Argument korrekt ist und ob der Benutzer angemeldet ist.
  3. Deaktivieren Sie die UUID 24 Stunden nach ihrer Ausstellung.

Dies wird einige Arbeit erfordern, aber es ist notwendig, wenn Sie wirklich ein robustes, sicheres System schreiben möchten.


4
2018-06-14 04:19



Wenn es von einem CSRNG generiert wird, ist es unvorhersehbar und kann daher verwendet werden.

Aber das Problem, das Sie erleiden, ist verschwendet, wenn Sie Bestätigungs-E-Mails unverschlüsselt versenden - wenn ein Angreifer die Möglichkeit hat, RNG-Ergebnisse von Ihrem System vorherzusagen, dann sind die Chancen, dass er auch E-Mails abfangen kann.

UUIDs sind auch lange Zeichenketten (128-Bit, dann typischerweise Base64 (22 Zeichen) oder Base16-codiert (32 Zeichen)) - denken Sie darüber nach, wie benutzerfreundlich Ihr System sein wird. Persönlich würde ich eine CSRNG verwenden, um zufällig acht alphanumerische Zeichen auszuwählen und diese zurückzugeben.


0
2018-06-14 03:07



Der Punkt des Zufallscodes für einen Bestätigungslink ist, dass der Angreifer den Wert weder schätzen noch vorhersagen kann. Wie Sie sehen können, um den richtigen Code zu Ihrem Bestätigungslink zu finden, ergibt eine UUID mit 128 Bit Länge 2 ^ 128 verschiedene mögliche Codes, nämlich 340, 282, 366, 920, 938, 463, 463, 374, 607, 431, 768, 211, 456 mögliche Codes zum Ausprobieren. Ich denke, Ihr Bestätigungslink ist nicht für den Start einer Atomwaffe, oder? Dies ist schwierig genug für Angreifer zu erraten. Es ist sicher.

- Aktualisierung -

Wenn du dem nicht vertraust kryptographisch stark Zufallszahlengenerator zur Verfügung gestellt, können Sie einige unvorhersehbare Parameter mit dem UUID-Code und Hash-sie. Beispielsweise,

Code = SHA1 (UUID, Prozess-PID, Thread-ID, lokale Verbindungsportnummer, CPU-Temperatur)

Dies macht es noch schwieriger vorherzusagen.


0
2018-06-14 03:15



Es ist perfekt als einmaliges Passwort, da ich selbst dasselbe für die Anwendung implementiert habe, auf der ich arbeite. Darüber hinaus sagt der Link, den Sie geteilt haben, alles.


-1
2018-06-14 03:05



Ich denke, dies sollte geeignet sein, da es zufällig generiert wird und nicht von irgendeiner spezifischen Eingabe (dh Sie geben es nicht mit einem Benutzernamen oder etwas Ähnlichem) - so führen mehrere Aufrufe dieses Codes zu unterschiedlichen Ergebnissen. Es gibt an, dass es ein 128-Bit-Schlüssel ist, also ist es lang genug, um unpraktisch zu sein.

Verwenden Sie diesen Schlüssel dann, um einen Wert zu verschlüsseln, oder möchten Sie dies als tatsächliches Passwort verwenden? Unabhängig davon müssen Sie den Schlüssel in ein Format uminterpretieren, das über eine Tastatur eingegeben werden kann. Führen Sie beispielsweise eine Base64- oder Hexadezimalkonvertierung durch oder ordnen Sie die Werte irgendwie alphanumerisch zu, andernfalls versucht der Benutzer, Bytewerte einzugeben, die auf der Tastatur nicht vorhanden sind.


-1
2018-06-14 03:03



Ich denke java.util.UUID sollte in Ordnung sein. Hier finden Sie weitere Informationen Artikel:


-1
2018-05-28 01:19