Generieren Sie sicher einen UNIQUEIDENTIFIER in SQL Server

Ich beabsichtige, einen UNIQUEIDENTIFIERals Zugriffsschlüssel zu verwenden, mit dem Benutzer auf bestimmte Daten zugreifen können. Der Schlüssel fungiert in diesem Sinne als Passwort.

Ich muss mehrere solcher Bezeichner als Teil einer INSERT...SELECTAnweisung generieren . Aus architektonischen Gründen möchte ich in diesem Fall die Bezeichner serverseitig generieren.

Wie kann ich einen sicheren Zufall generieren UNIQUEIDENTIFIER? Beachten Sie, dass NEWIDdies nicht zufällig ist, da es keinerlei Sicherheitseigenschaften verspricht. Ich suche nach dem SQL Server-Äquivalent von System.Security.Cryptography.RandomNumberGenerator, da ich nicht ermittelbare IDs benötige. Alles CHECKSUM, was darauf basiert RANDoder GETUTCDATEsich auch nicht qualifizieren würde.

— usr
quelle

@ AaronBertrand zumindest eine, wenn die Ziffern immer 4. Aber die Tatsache, dass ich keine eindeutigen Beweise dafür habe, dass sie erraten werden können, bedeutet nicht, dass sie es nicht sind. Ich kann diese Sicherheitsentscheidung nicht auf diese Beobachtung stützen.

— USR

Vielleicht ist NEWID genauso zufällig wie die "Debian-schwachen SSH-Schlüssel": de.wikinews.org/wiki/… Sie sahen für den Entwickler, der sie getestet hat, auf jeden Fall zufällig aus ...

— usr

Diese 4 gibt an, welcher Algorithmus zum Generieren der GUID verwendet wird. en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm

— Mr.Mindor

Verstehen Sie, dass der einzige entscheidende Faktor für die Höhe Ihrer Sicherheit die Bitentropie ist? Die Vorstellung, dass NEWID nicht zufällig genug für Ihre Bedürfnisse ist, würde bedeuten, dass Sie eine Vorstellung davon haben, wie viel Bitentropie für Ihren Anwendungsfall "sicher" sein muss. Was ist diese Nummer?

— Cade Roux

@usr - "bei voller Kenntnis des inneren Zustands" kann man jeden Ansatz knacken .

Antworten:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Sollte den Trick machen, hätte ich gedacht.

CRYPT_GEN_RANDOM

Gibt eine kryptografische Zufallszahl zurück, die von der Crypto API (CAPI) generiert wurde.

— Martin Smith
quelle

Nur meine zwei Cent, aber das ist vielleicht keine gute Idee. Um die exzellente Reihe von Eric Lippert über GUIDs ( Teil 1 , Teil 2 , Teil 3 ) zu paraphrasieren , lautet das Akronym GUID, nicht GSUID - Global Unique Identifier, nicht Global Secure Unique Identifier.

Das Problem liegt darin, dass bei der Generierung von GUIDs in einem nicht feindlichen Bereich, wie z. B. jedem, der NEWID () verwendet, garantiert wird, dass alle Werte eindeutig sind (siehe Eric's Artikel, Teil 3). Wenn eine feindliche Entität in diesen Bereich eintritt, kann sie sowohl die nächste generierte GUID vorhersagen als auch selbst Kollisionen verursachen.

Indem Sie Ihre eigene Methode zum Generieren eines Werts erstellen, den Sie in einer Struktur speichern, die wie eine GUID aussieht, sind Sie im Wesentlichen zu einer feindlichen Entität geworden. Sie haben den Vertrag einer GUID von eindeutig in zufällig geändert . Während jemand, der besser in Mathe ist als ich, wahrscheinlich beweisen kann, dass Sie immer noch einzigartig sind, liegt dies nur innerhalb der Grenzen Ihrer Erzeugungsmethode. Wenn Sie diese Pseudo-GUIDs mit NEWID () GUIDs mischen, sind alle Wetten deaktiviert.

Ich sage, dies ist möglicherweise keine gute Idee, nur weil ich nicht den gesamten Umfang Ihrer Verwendung der Werte kenne. Wenn Sie die einzige Entität sind, die die Werte generiert (kein Mix and Match), und / oder wenn Sie die Werte nicht beibehalten und / oder sich nicht für Kollisionen interessieren, ist dies möglicherweise kein Problem. Wenn eines dieser Elemente nicht zutrifft, sollten Sie es möglicherweise neu bewerten.

— Dave Simione
quelle

Interessante Punkte. Meine Wahl des Datentyps UNIQUEIDENTIFIERist meistens ein Zufall. Es ist einfach bequem, eine 16-Byte-Menge mit diesem Typ zu verarbeiten. Ich betrachte es als ein Passwort. Es muss jedoch einzigartig sein. Ich bin zuversichtlich, dass es nie zu einer Kollision kommen wird (und selbst wenn es eine gibt, stürzt die App einfach ab - das ist also auch sicher).

— USR

Ich bin anderer Meinung, es hängt davon ab, wie Sie es verschlüsseln, wenn es eher zufällig als eindeutig wird. Es kann leicht dasselbe sein.

— Dawesi

Laut https://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newsequentialid-histrorybenefits-and-implementation/ umschließt die NEWID () -Funktion nur die Windows-Funktion CoCreateGuid, die eine GUID im v4-Stil zurückgibt . Und laut https://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 seit Windows 2000 im Jahr 1999

"Die Zufallsbits für alle in Windows erstellten GUIDs der Version 4 werden über die Windows CryptGenRandom-Kryptografie-API oder die entsprechende Quelle abgerufen, die auch für die Generierung von Kryptografieschlüsseln verwendet wird."

Ich würde also sagen, Sie könnten NEWID () als kryptografisch sicher betrachten - zumindest im Ausmaß der 122 Entropiebits, die es bereitstellt.

— Jordan Rieger
quelle

Das ist interessant. Ich persönlich würde dies aus Sicherheitsgründen nicht vertrauen. Weder Windows noch SQL Server geben hierfür eine Garantie.

— usr

@usr Ich bin mir nicht sicher, wie eine Garantie aussehen würde. Das Wort "Garantie" wird nicht verwendet, es handelt sich jedoch anscheinend um eine standardmäßige MSDN Windows SDK-Dokumentation. Es ist äußerst unwahrscheinlich, dass MS die kryptografische Zufälligkeit von GUIDs in einer zukünftigen Version von Windows herabstufen wird. Es wäre nichts zu gewinnen.

— Jordan Rieger

Diese MSDN-Seite dokumentiert lediglich historische Entscheidungen, sagt jedoch nicht aus, dass diese in Zukunft beibehalten werden. Gleiches gilt für SQL Server. Ich kann mir keine Umstände vorstellen, unter denen dies zusammenbrechen würde. Aber es hat viele katastrophale RNG-Debakel gegeben. Annahmen wie diese haben sich oft als falsch herausgestellt. Es ist ein heuristisches Argument.

— USR

@usr Aber wie kann eine MSDN-Dokumentation das zukünftige Verhalten von Windows gewährleisten ? Das Beste, worauf wir in diesen Fällen hoffen können, ist die Dokumentation des aktuellen Verhaltens. Wenn sich das Verhalten ändert, aktualisieren sie die Dokumentation. Aus diesem Grund haben diese Fragen und Antworten zum Stapelüberlauf Versions-Tags und werden von Zeit zu Zeit aktualisiert.

— Jordan Rieger

Sie geben Garantien für Dinge, die sie nicht ändern werden. Sie könnten das Produkt ändern, werden es aber nicht, wenn sie sagen "Hier ist eine sicherheitskritische Funktion mit diesen Eigenschaften". Ich interpretiere diese fragliche Dokumentation eher als historische Ansicht als als Aussage über die Zukunft.

— USR