Genere de forma segura un IDENTIFICADOR ÚNICO en SQL Server

Tengo la intención de usar a UNIQUEIDENTIFIERcomo una clave de acceso que los usuarios pueden usar para acceder a ciertos datos. La clave actuará como contraseña en ese sentido.

Necesito generar múltiples identificadores como parte de una INSERT...SELECTdeclaración. Por razones arquitectónicas, quiero generar los identificadores del lado del servidor en este caso.

¿Cómo puedo generar un aleatorio seguro UNIQUEIDENTIFIER? Tenga en cuenta que eso NEWIDno sería lo suficientemente aleatorio, ya que no promete ninguna propiedad de seguridad. Estoy buscando el equivalente de SQL Server de System.Security.Cryptography.RandomNumberGenerator porque necesito identificaciones indiscutibles. Cualquier cosa basada en CHECKSUM, RANDo GETUTCDATEtampoco calificaría.

— usr
fuente

@AaronBertrand por lo menos, uno si los dígitos son siempre 4. Pero el hecho de que no tenga pruebas sólidas de que puedan ser adivinables no significa que no lo sean. No puedo basar esta decisión de seguridad en esta observación.

— usr

Tal vez NEWID es tan aleatorio como los "Debian claves SSH débil": en.wikinews.org/wiki/...~~V~~aux~~singular~~3rd Ciertamente parecía al azar para el desarrollador que los puso a prueba ...

— usr

Ese 4 le dice qué algoritmo se utiliza para generar el GUID. en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm

— Mr.Mindor

¿Entiende que el único factor determinante en el nivel de su seguridad es la entropía de bits? La idea de que NEWID no es lo suficientemente aleatorio para sus necesidades implicaría que tiene alguna idea de la cantidad de entropía de bits que se requiere para ser "segura" para su caso de uso. ¿Cuál es ese número?

— Cade Roux

@usr: "dado el pleno conocimiento del estado interno", se puede descifrar cualquier enfoque.

Respuestas:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Debería hacer el truco que hubiera pensado.

CRYPT_GEN_RANDOM

Devuelve un número criptográfico aleatorio generado por Crypto API (CAPI).

— Martin Smith
fuente

Solo mis dos centavos, pero esto puede no ser una buena idea. Parafraseando la excelente serie de Eric Lippert sobre GUID ( parte 1 , parte 2 , parte 3 ), el acrónimo es GUID, no GSUID: identificador único global, no identificador único globalmente seguro.

El problema radica en que cuando los GUID se generan dentro de un ámbito no hostil, como todos los que usan NEWID (), se garantiza que todos los valores sean únicos (bueno, más o menos, consulte el artículo de Eric, parte 3). Pero si una entidad hostil entra en ese ámbito, pueden predecir el siguiente GUID generado, así como causar colisiones por su cuenta.

Al crear su propio método para generar un valor que almacena dentro de una estructura que parece un GUID, se ha convertido esencialmente en una entidad hostil. Ha cambiado el contrato de un GUID de ser único a ser aleatorio . Si bien alguien mejor en matemáticas de lo que probablemente podría demostrar que todavía eres único, eso solo está dentro de los límites de tu método de generación. Si combina estos pseudo-GUID con NEWID () GUID, todas las apuestas están desactivadas.

Digo que esto puede no ser una buena idea solo porque no conozco todo el alcance de cómo está utilizando los valores. Si usted es la única entidad que genera los valores (sin mezclar ni combinar), y / o no persiste en los valores, y / o no le importan las colisiones, esto puede no ser un problema. Si alguno de esos elementos no es cierto, es posible que desee volver a evaluar.

— Dave Simione
fuente

Puntos interesantes Mi elección del tipo de datos UNIQUEIDENTIFIERes principalmente una coincidencia. Es conveniente manejar una cantidad de 16 bytes usando ese tipo. Pienso en ello como una contraseña. Sin embargo, tiene que ser único. Estoy seguro de que nunca veré una colisión (e incluso si existe, la aplicación se bloqueará, así que eso también es seguro).

— usr

No estoy de acuerdo, depende de "cómo" lo cifre si se vuelve aleatorio en lugar de único. Puede ser fácilmente lo mismo.

— Dawesi

De acuerdo con https://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newsequentialid-histrorybenefits-and-implementation/ , la función NEWID () simplemente envuelve la función de Windows CoCreateGuid, que devuelve un GUID de estilo v4 . Y de acuerdo con https://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 , desde Windows 2000 en 1999,

"los bits aleatorios para todos los GUID de la versión 4 creados en Windows se obtienen a través de la API criptográfica CryptGenRandom de Windows o su equivalente, la misma fuente que se utiliza para generar claves criptográficas"

Entonces, diría que podría considerar NEWID () criptográficamente seguro, al menos en la medida de los 122 bits de entropía que proporciona.

— Jordan Rieger
fuente

Eso es interesante. Yo personalmente no confiaría en esto por razones de seguridad. Ni Windows ni SQL Server garantizan esto.

— Usr

@usr No estoy seguro de cómo sería una garantía. No utiliza la palabra "garantía", pero parece ser la documentación estándar del SDK de Windows de MSDN. Sería extremadamente improbable que MS rebaje la aleatoriedad criptográfica de los GUID en alguna versión futura de Windows. No habría nada que ganar.

— Jordan Rieger

Esa página de MSDN simplemente documenta elecciones históricas, pero no dice que esto se mantendrá en el futuro. Lo mismo para SQL Server. No puedo imaginar las circunstancias bajo las cuales esto se rompería. Pero ha habido muchas debacle catastróficas de RNG. Suposiciones como esta a menudo han resultado ser falsas. Es un argumento heurístico.

— Usr

@usr Pero, ¿cómo podría cualquier documentación de MSDN garantizar el comportamiento futuro de Windows? Lo máximo que podemos esperar en estos casos es la documentación del comportamiento actual. Si el comportamiento cambia, bueno, actualizan la documentación. Es por eso que estas preguntas y respuestas sobre Stack Overflow tienen etiquetas de versión y se actualizan de vez en cuando.

— Jordan Rieger

Hacen garantías sobre cosas que no cambiarán. Podrían cambiar el producto, pero no lo harán si dicen "aquí hay una función crítica de seguridad con estas propiedades". Interpreto esa documentación en cuestión más como una visión histórica que como una declaración sobre el futuro.

— usr