¿Necesito un valor aleatorio "criptográficamente seguro" para una URL no descargable?

Navega tus respuestas
3

tl; dr: ¿Una cadena generada de forma pseudoaleatoria es lo suficientemente indiscutible como para ser utilizada como token en una URL?

Estoy creando una aplicación web, supongamos que es otro PasteBin. Permito que los usuarios peguen texto y genero una URL aleatoria para que puedan pasar a sus amigos, pero de lo contrario seguirán siendo desconocidos para el público.

¿Cómo debo generar esta URL? Será algo así como https://pastebin.example.com/%s donde %s es una cadena aleatoria.

¿Qué tan seguro es usar un valor pseudoaleatorio, como el resultado de uniqid ? ¿De qué manera el uso de algo como openssl_random_pseudo_bytes mejorará el hecho de que no se pueda adivinar? ID es?

Supongamos que los usuarios no podrán enviar muchas pastas por minuto de forma arbitraria, hay algún sistema que limita la velocidad (como un captcha y una verificación de IP). También asuma que he tomado medidas para evitar que los motores de búsqueda indexen la página. El riesgo de compartir información protegida solo por un imperdible La URL está fuera del alcance de esta pregunta.

Para mayor claridad: la cadena aleatoria SOLO se usa como identificador, NO se usa para operaciones criptográficas posteriormente.

    
pregunta jornane 17.03.2017 - 10:18
fuente

2 respuestas

0

¿Necesita algo "criptográficamente seguro"?

Sí, si desea que la URL: s sea indiscutible (por otros medios que no sean la fuerza bruta), deberá usar un cryptographically generador seguro de números pseudoaleatorios (CSPRNG).

Los números seguirán siendo pseudoaleatorios: las computadoras no pueden generar números aleatorios "verdaderos". La única diferencia es que los números futuros no son adivinables de números pasados. Y eso es lo que marca la diferencia aquí.

Entiendo que las palabras "criptográficamente seguras" están causando confusión aquí. Como dices, no estás haciendo criptografía, entonces ¿por qué necesitarías eso? Simplemente tradúzcalos a "indiscutibles" y las cosas se volverán más claras.

La limitación de velocidad ayuda a algunos aquí. Definitivamente, será más difícil para un atacante obtener una larga lista de ID secuenciales. Pero, ¿hace que sea imposible para un atacante predecir futuras identificaciones? No, probablemente no.

¿Qué pasa con esas funciones de PHP?

uniqid se basa en la hora actual en microsegundos. Según el el manual , no es criptográficamente seguro:

  

Precaución: Esta función no genera valores criptográficamente seguros y no debe utilizarse con fines criptográficos. Si necesita un valor criptográficamente seguro, considere usar random_int() , random_bytes() o openssl_random_pseudo_bytes() en su lugar.

En su lugar, use una de las funciones sugeridas y asegúrese de que su ID sea lo suficientemente larga como para evitar el uso de fuerza bruta.

    
respondido por el Anders 17.03.2017 - 10:48
fuente
1

uniqid podría no ser la mejor opción, en parte porque los documentos mencionan (en rojo):

  

Advertencia   Esta función no garantiza la unicidad del valor de retorno. Como la mayoría de los sistemas ajustan el reloj del sistema mediante NTP o similar, la hora del sistema cambia constantemente. Por lo tanto, es posible que esta función no devuelva una ID única para el proceso / subproceso. Use more_entropy para aumentar la probabilidad de singularidad.

Y tiendo a sospechar que las colisiones de identificación serían bastante desastrosas en tu caso.

Creo que la respuesta básica es que si realmente tiene un requerimiento de lo que no se puede adivinar, en lugar de simplemente único, es probable que desee utilizar un RNG criptográficamente seguro.

O use un UUID ( enlace ): hay opciones, específicamente UUIDv5, que parecen más adecuadas para su caso. que uniqid .

    
respondido por el iwaseatenbyagrue 17.03.2017 - 10:33
fuente

Lea otras preguntas en las etiquetas

Falsa XSS en la barra de búsqueda [cerrado] Intentando encontrar un XSS, ¿por qué no se ejecuta esta pieza? [duplicar]