c# - jugar - letras aleatorias para stop

Guid.NewGuid() VS un generador de cadenas aleatorias de Random.Next()

Question

Mi colega y yo estamos debatiendo cuál de estos métodos usar para auto generar ID de usuario y publicar ID para identificación en la base de datos:

Una opción utiliza una única instancia de Aleatorio, y toma algunos parámetros útiles para que pueda ser reutilizada para todo tipo de casos de cadena-gen (es decir, desde los pines numéricos de 4 dígitos hasta los identificadores alfanuméricos de 20 dígitos). Aquí está el código:

// This is created once for the lifetime of the server instance
class RandomStringGenerator
{
public const string ALPHANUMERIC_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
public const string ALPHA_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
public const string NUMERIC = "1234567890";
Random rand = new Random();
public string GetRandomString(int length, params char[] chars)
{
string s = "";
for (int i = 0; i < length; i++)
s += chars[rand.Next() % chars.Length];
return s;
}
}

y la otra opción es simplemente usar:

Guid.NewGuid();

vea Guid.NewGuid en MSDN

Los dos somos conscientes de que Guid.NewGuid() funcionaría para nuestras necesidades, pero prefiero usar el método personalizado. Hace lo mismo pero con más control.

Mi colega piensa que debido a que el método personalizado se ha preparado nosotros mismos, es más probable que genere colisiones. Admitiré que no estoy al tanto de la implementación de Random, pero supongo que es tan aleatorio como Guid.NewGuid (). Un uso típico del método personalizado podría ser:

RandomStringGenerator stringGen = new RandomStringGenerator();
string id = stringGen.GetRandomString(20, RandomStringGenerator.ALPHANUMERIC_CAPS.ToCharArray());

Editar 1:

• Estamos utilizando Azure Tables que no tiene una función de incremento automático (o similar) para generar claves.
• Algunas respuestas aquí solo me dicen que use NewGuid () "porque para eso está hecho". Estoy buscando una razón más profunda de por qué el método de cocción puede generar colisiones con los mismos grados de libertad que un Guid.

Editar 2:

También utilizamos el método "cocinado" para generar identificaciones de publicación que, a diferencia de las fichas de sesión, deben verse bonitas para mostrarse en la URL de nuestro sitio web (como http://mywebsite.com/14983336 ), por lo que las guids no son una opción aquí. Sin embargo, las colisiones aún deben evitarse.

Answer 1

Estoy buscando una razón más profunda sobre por qué el método de cocción puede generar colisiones con los mismos grados de libertad que un Guid.

Primero, como otros han notado, Random no es seguro para subprocesos; usarlo desde múltiples hilos puede hacer que corrompa sus estructuras internas de datos para que siempre produzca la misma secuencia.

En segundo lugar, Random está basado en la hora actual. Dos instancias de Random creadas dentro del mismo milisegundo (recuerden que un milisegundo es varios millones de ciclos de procesador en hardware moderno) tendrán la misma semilla y, por lo tanto, producirán la misma secuencia.

Tercero, mentí. Random no está basado en la hora actual; está basado en la cantidad de tiempo que la máquina ha estado activa . La semilla es un número de 32 bits, y dado que la granularidad es en milisegundos, son solo unas pocas semanas hasta que se completa. Pero ese no es el problema; El problema es que es muy probable que el período de tiempo en el que cree esa instancia de Random esté dentro de unos pocos minutos desde el inicio de la máquina. Cada vez que apaga y enciende una máquina, o trae una máquina nueva en línea en un clúster, hay una pequeña ventana en la que se crean instancias de Random, y cuanto más sucede, mayores son las probabilidades de que obtenga una semilla que tenías antes

Como otros han dicho: si quieres una clave principal para tu base de datos, haz que la base de datos te genere una clave primaria ; deja que la base de datos haga su trabajo. Si desea un identificador global único, utilice un guid ; para eso están para.

Y, por último, si está interesado en aprender más sobre los usos y abusos de las guías, le recomendamos que lea mi serie "guía guía"; la primera parte está aquí:

http://blogs.msdn.com/b/ericlippert/archive/2012/04/24/guid-guide-part-one.aspx

Answer 2

"Generación automática de ID de usuario e ID de publicación para su identificación en la base de datos" ... ¿por qué no utilizar una secuencia de base de datos o una identidad para generar claves?

Para mí, su pregunta es realmente: "¿Cuál es la mejor manera de generar una clave principal en mi base de datos?" Si ese es el caso, debe usar la herramienta convencional de la base de datos que será una secuencia o identidad. Estos tienen beneficios sobre cadenas generadas.

1. Secuencias / índice de identidad mejor. Existen numerosos artículos y publicaciones en blogs que explican por qué los GUID y demás generan índices pobres.
2. Se garantiza que son únicos dentro de la mesa
3. Se pueden generar de forma segura mediante inserciones simultáneas sin colisión
4. Son simples de implementar

Supongo que mi próxima pregunta es, ¿qué razones estás considerando las cadenas GUID o generadas? ¿Te estarás integrando en bases de datos distribuidas? Si no, debes preguntarte si estás resolviendo un problema que no existe.

Answer 3

Como está escrito en otras respuestas, mi implementación tuvo algunos problemas graves:

• Seguridad del subproceso: Aleatorio no es seguro para subprocesos.
• Previsibilidad: el método no se pudo usar para identificadores críticos de seguridad como tokens de sesión debido a la naturaleza de la clase Random.
• Colisiones: aunque el método creó 20 números "aleatorios", la probabilidad de una colisión no es (number of possible chars)^20 debido a que el valor inicial solo es de 31 bits y proviene de una fuente incorrecta. Dada la misma semilla, cualquier longitud de secuencia será la misma.

Guid.NewGuid() estaría bien, excepto que no queremos usar GUID feos en urls y .NETs. El algoritmo NewGuid () no es criptográficamente seguro para usar en tokens de sesión; podría dar resultados predecibles si un poco de información es conocida.

Aquí está el código que estamos usando ahora, es seguro, flexible y, por lo que sé, es muy poco probable que cree colisiones si se le da la suficiente longitud y la elección del personaje:

class RandomStringGenerator
{
RNGCryptoServiceProvider rand = new RNGCryptoServiceProvider();
public string GetRandomString(int length, params char[] chars)
{
string s = "";
for (int i = 0; i < length; i++)
{
byte[] intBytes = new byte[4];
rand.GetBytes(intBytes);
uint randomInt = BitConverter.ToUInt32(intBytes, 0);
s += chars[randomInt % chars.Length];
}
return s;
}
}

Answer 4

Con respecto a su edición, aquí hay una razón para preferir un GUID sobre una cadena generada:

El almacenamiento nativo para un GUID (uniqueidentifier) ​​en SQL Server es de 16 bytes. Para almacenar una varchar de longitud equivalente (cadena), donde cada "dígito" en la identificación se almacena como un carácter, requeriría en algún lugar entre 32 y 38 bytes, dependiendo del formato.

Debido a su almacenamiento, SQL Server también puede indexar una columna uniqueidentifier de manera más eficiente que una columna varchar también.

Answer 5

Contrariamente a lo que algunas personas han dicho en el comentario, un GUID generado por Guid.NewGuid () NO depende de ningún identificador específico de la máquina (solo los GUID de tipo 1 son, Guid.NewGuid () devuelve un GUID de tipo 4, que es principalmente aleatorio).

Siempre que no necesite seguridad criptográfica, la clase Random debería ser lo suficientemente buena, pero si desea estar más seguro, use System.Security.Cryptography.RandomNumberGenerator . Para el enfoque Guid, tenga en cuenta que no todos los dígitos en un GUID son aleatorios. Cita de la wikipedia :

En la representación canónica, xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx , los bits más significativos de N indican la variante (dependiendo de la variante; se usan uno, dos o tres bits). La variante cubierta por la especificación UUID está indicada por los dos bits más significativos de N que son 1 0 (es decir, el N hexadecimal siempre será 8, 9, A o B). En la variante cubierta por la especificación UUID, hay cinco versiones. Para esta variante, los cuatro bits de M indican la versión de UUID (es decir, la M hexadecimal será 1, 2, 3, 4 o 5).

Answer 6

Su método personalizado tiene dos problemas:

1. Utiliza una instancia global de Random , pero no usa bloqueo. => El acceso multihilo puede dañar su estado. Después de lo cual la salida chupará aún más de lo que ya hace.
2. Utiliza una semilla predecible de 31 bits. Esto tiene dos consecuencias:
   • No puede usarlo para nada relacionado con la seguridad donde la impracticabilidad es importante
   • La semilla pequeña (31 bits) puede reducir la calidad de sus números. Por ejemplo, si crea varias instancias de Random al mismo tiempo (desde el inicio del sistema), probablemente crearán la misma secuencia de números aleatorios.

Esto significa que no puede confiar en que la salida de Random sea ​​única, sin importar cuánto tiempo sea.

Recomiendo usar un CSPRNG ( RNGCryptoServiceProvider ) incluso si no necesita seguridad. Su rendimiento aún es aceptable para la mayoría de los usos, y confío en la calidad de sus números aleatorios sobre Random . Si quieres exclusividad, te recomiendo obtener números con alrededor de 128 bits.

Para generar cadenas aleatorias usando RNGCryptoServiceProvider puede ver mi respuesta a ¿Cómo puedo generar cadenas alfanuméricas aleatorias de 8 caracteres en C #? .

Actualmente, los GUID devueltos por Guid.NewGuid() son GUID de la versión 4. Se generan a partir de un PRNG, por lo que tienen propiedades bastante similares a generar un número aleatorio de 122 bits (los 6 bits restantes son fijos). Su fuente de entropía tiene una calidad mucho más alta que la que utiliza Random , pero no está garantizada su seguridad criptográfica.

Pero el algoritmo de generación puede cambiar en cualquier momento, por lo que no puede confiar en eso. Por ejemplo, en el pasado, el algoritmo de generación GUID de Windows cambió de v1 (basado en la marca de tiempo MAC +) a v4 (aleatorio).

Answer 7

Use System.Guid como este:

... se puede usar en todas las computadoras y redes donde sea que se requiera un identificador único.

Tenga en cuenta que Random es un generador de números pseudoaleatorios . No es verdaderamente aleatorio, ni único. Solo tiene 32 bits de valor para trabajar, en comparación con el GUID de 128 bits.

Sin embargo, incluso los GUID pueden tener colisiones (aunque las posibilidades son realmente escasas), por lo que debe usar las características propias de la base de datos para proporcionarle un identificador único (por ejemplo, la columna de ID de autoincrement). Además, no puede convertir fácilmente un GUID en un número numérico 4 o 20 (alfa).