Générez en toute sécurité un UNIQUEIDENTIFIER dans SQL Server

J'ai l'intention d'utiliser un UNIQUEIDENTIFIERcomme clé d'accès que les utilisateurs peuvent utiliser pour accéder à certaines données. La clé servira de mot de passe dans ce sens.

J'ai besoin de générer plusieurs identifiants de ce type dans le cadre d'une INSERT...SELECTdéclaration. Pour des raisons architecturales, je veux générer les identifiants côté serveur dans ce cas.

Comment puis-je générer un aléatoire en toute sécurité UNIQUEIDENTIFIER? Notez que NEWIDce ne serait pas assez aléatoire car cela ne promet aucune propriété de sécurité. Je recherche l'équivalent SQL Server de System.Security.Cryptography.RandomNumberGenerator car j'ai besoin d'identifiants invisibles. Tout ce que basé sur CHECKSUM, RANDou GETUTCDATEne serait pas admissible aussi.

— usr
source

@AaronBertrand à tout le moins, un si les chiffres sont toujours 4. Mais le fait que je n'ai pas de preuves solides qu'ils pourraient être devinables ne signifie pas qu'ils ne le sont pas. Je ne peux pas fonder cette décision de sécurité sur cette observation.

— usr

Peut-être que NEWID est tout aussi aléatoire que les "clés SSH faibles Debian": en.wikinews.org/wiki/… Ils ont certainement semblé aléatoires au développeur qui les a testés ...

— usr

Cela 4 vous indique quel algorithme est utilisé pour générer le GUID. en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm

— Mr.Mindor

Vous comprenez que le seul facteur déterminant dans le niveau de votre sécurité est l'entropie des bits? L'idée que NEWID n'est pas assez aléatoire pour vos besoins impliquerait que vous ayez une idée de la quantité d'entropie de bits qui doit être «sécurisée» pour votre cas d'utilisation. Quel est ce chiffre?

— Cade Roux

@usr - "étant donné la pleine connaissance de l'état interne", on peut casser n'importe quelle approche.

Réponses:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Devrait faire le tour que j'aurais pensé.

CRYPT_GEN_RANDOM

Renvoie un nombre aléatoire cryptographique généré par l'API Crypto (CAPI).

— Martin Smith
source

Juste mes deux cents, mais ce n'est peut-être pas une bonne idée. Pour paraphraser l'excellente série d'Eric Lippert sur les GUID ( partie 1 , partie 2 , partie 3 ), l'acronyme est GUID, pas GSUID - Globally Unique Identifier, pas Globally Secure Unique Identifier.

Le problème réside dans le fait que lorsque les GUID sont générés dans une portée non hostile, comme tout le monde utilisant NEWID (), toutes les valeurs sont garanties comme étant uniques (enfin, en quelque sorte, voir l'article d'Eric, partie 3). Mais si une entité hostile entre dans cette portée, elle peut à la fois prédire le prochain GUID généré et provoquer elle-même des collisions.

En créant votre propre méthode de génération d'une valeur que vous stockez à l'intérieur d'une structure qui ressemble à un GUID, vous êtes essentiellement devenu une entité hostile. Vous avez changé le contrat d'un GUID de l' unique à aléatoire . Alors que quelqu'un de meilleur en mathématiques que moi pourrait probablement prouver que vous êtes toujours unique, ce n'est que dans les limites de votre méthode de génération. Si vous mélangez ces pseudo-GUID avec des GUID NEWID (), tous les paris sont désactivés.

Je dis que ce n'est peut-être pas une bonne idée uniquement parce que je ne connais pas toute la portée de la façon dont vous utilisez les valeurs. Si vous êtes la seule entité générant les valeurs (pas de mix and match), et / ou si vous ne persistez pas les valeurs, et / ou que vous ne vous souciez pas des collisions, cela peut ne pas être un problème. Si l'un de ces éléments n'est pas vrai, vous voudrez peut-être réévaluer.

— Dave Simione
source

Points intéressants. Mon choix de type de données UNIQUEIDENTIFIERest surtout une coïncidence. Il est juste pratique de gérer une quantité de 16 octets en utilisant ce type. Je pense que c'est un mot de passe. Cela doit cependant être unique. Je suis convaincu que je ne verrai jamais de collision (et même s'il y a l'application, elle se bloquera - c'est donc aussi sûr).

— usr

Je ne suis pas d'accord, cela dépend de la façon dont vous le chiffrez s'il devient aléatoire plutôt que unique. Cela peut facilement être le même.

— Dawesi

Selon https://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newsequentialid-histrorybenefits-and-implementation/ , la fonction NEWID () enveloppe simplement la fonction Windows CoCreateGuid, qui renvoie un GUID de style v4 . Et selon https://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 , depuis Windows 2000 en 1999,

"les bits aléatoires pour tous les GUID de la version 4 construits dans Windows sont obtenus via l'API cryptographique Windows CryptGenRandom ou l'équivalent, la même source qui est utilisée pour la génération de clés cryptographiques"

Donc, je dirais que vous pourriez considérer NEWID () cryptographiquement sécurisé - au moins dans la mesure des 122 bits d'entropie qu'il fournit.

— Jordan Rieger
source

C'est intéressant. Personnellement, je ne ferais pas confiance à cela pour des raisons de sécurité. Ni Windows ni SQL Server ne garantissent cela.

— usr

@usr Je ne sais pas à quoi ressemblerait une garantie. Il n'utilise pas le mot «garantie», mais il semble s'agir de la documentation standard du SDK MSDN Windows. Il serait extrêmement improbable que MS rétrograde le caractère aléatoire cryptographique des GUID dans une future version de Windows. Il n'y aurait rien à gagner.

— Jordan Rieger

Cette page MSDN ne fait que documenter les choix historiques, mais elle ne dit pas qu'elle sera conservée à l'avenir. Idem pour SQL Server. Je ne peux pas imaginer des circonstances dans lesquelles cela s'effondrerait. Mais il y a eu de nombreuses débâcles RNG catastrophiques. Des hypothèses comme celle-ci se sont souvent révélées fausses. C'est un argument heuristique.

— usr

@usr Mais comment une documentation MSDN pourrait-elle garantir le comportement futur de Windows? Le plus que nous puissions espérer dans ces cas est la documentation du comportement actuel. Si le comportement change un jour, eh bien, ils mettent à jour la documentation. C'est pourquoi ces questions et réponses Stack Overflow ont des balises de version et sont mises à jour de temps en temps.

— Jordan Rieger

Ils garantissent des choses qu'ils ne changeront pas. Ils pourraient changer le produit mais ils ne le feront pas s'ils disent "voici une fonction critique de sécurité avec ces propriétés". J'interprète cette documentation en question plus comme une vue historique que comme une déclaration sur l'avenir.

— usr