Implementación de URL de activación seguras y únicas de "uso único" en ASP.NET (C#)

Question

Tengo un escenario en el que los usuarios de un sitio que estoy creando necesitan poder ingresar información básica en un formulario web sin tener que iniciar sesión. El sitio se está desarrollando con ASP.NET/C# y está utilizando MSSQL 2005 para sus datos relacionales.

A los usuarios se les enviará un correo electrónico desde el sitio, proporcionándoles un enlace exclusivo para ingresar la información específica que se requiere. El correo electrónico será muy similar al estilo de correo electrónico que todos recibimos al registrar sitios como foros, que contienen un parámetro de URL único generado de forma aleatoria, específicamente relacionado con un único propósito (como verificar una dirección de correo electrónico para un foro).

Mis consultas se refieren a la implementación segura de este problema. Estaba considerando usar un GUID como el identificador único, pero no estoy seguro de sus implicaciones en el mundo de la seguridad.

1. ¿Es un GUID lo suficientemente largo como para que los valores no puedan adivinarse fácilmente (o forzados en el tiempo)?

2. ¿La implementación de GUID de .NET es suficientemente aleatoria en el sentido de que existe la misma posibilidad de generación de todos los valores posibles en el "espacio clave"?

3. Si usar un GUID es un enfoque aceptable, ¿debe el sitio redirigir a la información mediante la reescritura de URL o asociar la información en una tabla de datos con el GUID como referencia?

4. ¿Utilizará una reescritura de URL para ocultar la verdadera fuente de los datos?

5. ¿Debo considerar usar el SELECT NEWID() de TSQL como generador de GUID sobre la implementación de .NET?

6. ¿Estoy completamente equivocado con mi enfoque a este problema?

Muchas gracias,

Carl

Answer 1

1. Sí, 2 es lo suficientemente largo.
2. No, las implementaciones de GUID están diseñadas para generar GUID únicos en lugar de los aleatorios. Debe usar un generador de números aleatorios cryptographically secure (por ejemplo, RNGCryptoServiceProvider) para generar 16 bytes aleatorios e inicializar una estructura Guid con eso.
3. Sí, es un enfoque aceptable en general. Ambos funcionarán.
4. Sí, si no dar otras pistas
5. No, goto 2
6. No, es bastante bien. Solo necesita usar un generador de números aleatorios criptográficamente seguro para generar el GUID.

Answer 2

Recomendaría simplemente usar un número aleatorio simple, p. bytes desde RNGCryptoServiceProvider.GetBytes. Los GUID no están destinados a ser completamente aleatorios. Han corregido bits, y algunas versiones usan su dirección MAC. GetBytes también le da la opción de usar más de 128 bits (aunque eso debería ser suficiente).

Creo que es mejor no poner los datos del usuario en una url. Aunque HTTPS puede protegerlo en tránsito, aún puede estar en el historial del navegador del usuario o tal. Es mejor utilizar POST y asociar el número aleatorio con una fila de su base de datos.

Answer 3

Primero, si es posible, debe limitar la fuerza bruta, limitando el rendimiento de la consulta (por ejemplo, intentos limitados por IP por segundo y intentos totales limitados por segundo).

Dependiendo del algoritmo de generación GUID, esto podría no ser una buena idea. Si bien las implementaciones recientes deben ser "lo suficientemente buenas por lo general", puede haber mucha predictibilidad de los valores. Las implementaciones recientes como la que se usa en .NET aplican un hash, de lo contrario, tiene campos claramente identificables para la dirección MAC y el tiempo transcurrido desde el arranque. Sin embargo, los valores posibles son limitados, por lo que no tiene 128 bits aleatorios verdaderos.

Si la seguridad es la máxima prioridad, escogería un cryptographically strong random number generator y construiría una cadena de caracteres aleatorios. Esto también hace que oyu sea independiente de un algoritmo fácilmente adivinable (como un guid.ToString() se identifica fácilmente como tal) para el cual un ataque podría ser descubierto en el futuro cercano.

Si se cumplen estos criterios, no veo ningún problema para tener la clave en la cadena de consulta.

Answer 4

Podría ser exagerado, pero podría hash su dirección de correo electrónico con SHA1 usando su guid (NewGuid está bien) como hash salt y colocar eso en la URL. Luego, cuando lleguen a su página, podrían preguntarles su dirección de correo electrónico, recuperar el guid y volver a calcular el hash para validarlo. Incluso si alguien supiera qué direcciones de correo electrónico probar, nunca sería capaz de generar una colisión hash sin conocer la guía con la que se sala (o les tomaría muchísimo tiempo :). Por supuesto, tendría que guardar su correo electrónico y el hash salt guid en la base de datos.

Answer 5

1. No, los GUID no son completamente aleatorios, y la mayoría de los bits son estáticos o fácilmente adivinables.
2. No, no son aleatorios, ver 1. En realidad, hay un número muy pequeño de bits que son aleatorios, y no criptográficamente fuertes al azar.
3. No es, consulte 1 y 2.
4. puede, pero no necesita ... ver mi solución al final.
5. No, vea 1 y 2
6. Sí.

Lo que se debe utilizar en lugar de un GUID, es un generador de números aleatorios criptográficamente fuerte - System.Security.Cryptography.RNGCryptoServiceProvider utilizar, para generar larga (por ejemplo, 32 bytes) de la cadena de datos, entonces base64 encode eso.
Además, suponiendo que se trata de algún tipo de registro con datos confidenciales, le recomendamos limitar la validez del enlace, digamos 60 minutos o 24 horas, dependiendo de su sitio.
Deberá mantener un mapeo de estos valores para los usuarios específicos. Luego puede presentarlo automáticamente con la forma adecuada según sea necesario. No es necesario que reescriba la URL, solo utilícela como el identificador del usuario (en esta página).
Por supuesto, no se olvide este URL debe ser HTTPS ...

Por cierto, sólo una nota - sus buenas prácticas para poner algún tipo de texto en el correo electrónico, explicando que los usuarios shouldnt clic en enlaces en correos electrónicos anónimos, y normalmente su sitio no enviará, y nunca deberían ingresar su contraseña después de hacer clic en blablabla ....

Ah, casi lo olvidaste, otro problema que debes tener en cuenta es lo que sucede si el usuario quiere que se le envíen varios correos electrónicos, p. los hits se registran varias veces ¿Puede hacer esto una y otra vez y obtener muchas URL válidas? ¿Es solo el último válido? ¿O tal vez el mismo valor se resiente una y otra vez? Por supuesto, si un usuario anónimo puede enviar una solicitud para este correo electrónico, DoS puede convertirse en un problema ... sin mencionar que si ingresa su propio correo electrónico, también puede ingresar cualquier dirección aleatoria, inundando algunos pobres shmuck's bandeja de entrada y posiblemente hacer que su servidor de correo sea incluido en la lista negra ...
No hay una respuesta correcta, pero debe considerarse en el contexto de su aplicación.

Answer 6

cree una tabla en la base de datos con un linkID y una columna Datesent, en la generación de la inserción de envío de enlace DateTime.Now en la tabla y devuelva linkId, configure el linkID como un parámetro querystring en activationLink. Al cargar la página de activación recupera el ID de enlace y lo usa para evocar un procedimiento almacenado que devolverá la fecha cuando pasó el ID de enlace correspondiente como parámetro, cuando recuperes la fecha puedes agregar cuánto tiempo quieres que el enlace permanezca activo por utilizando .AddDays() /. AddMonths, estos son métodos de C# para datetime. luego compara la fecha en que regresaste con la fecha de hoy. si ha pasado su duración de días o meses, dé un mensaje de error o continúe y muestre el contenido de la página. Supongo que conserva el contenido de la página en un panel y lo configura vissible = "false" y luego solo hace que el panel sea visible = "verdadero" si la fecha todavía está dentro del rango.