¿Qué algoritmo de cifrado de bloque "bueno" tiene la salida más corta?

Question

Me gustaría darles a los clientes un número de orden de aspecto aleatorio pero use 0, 1, 2, ... en el back-end. De esta forma, el cliente obtiene una URL de estado de pedido sin contraseña con el número de orden cifrado y no puede mirar los números de pedido de otros clientes agregando o restando 1. Esto podría reemplazar un esquema donde se generan claves de orden aleatorio, se verifica su exclusividad entre todos los pedidos anteriores, y vuelto a generar hasta que sea único. Cuando el servidor web recibe una solicitud para ver un pedido, descifra el número de pedido y recupera el pedido.

Para mantener la URL corta, ¿qué "buen" algoritmo de cifrado tiene el tamaño de bloque más corto? ¿Es este esquema una buena idea? (¿Qué pasa si encripta los identificadores de los empleados de Apple, Inc. para evitar que Steve Jobs solicite el Empleado # 0?)

Observe que todos los sitios web de seguimiento de paquetes le permiten rastrear paquetes sin autenticación. Estaría bien limitar la cantidad de información que se muestra en la página de estado de pedido sin contraseña.

Answer 1

La mayoría de las cifras de bloques van a utilizar bloques de tamaño superior a 32 bits, por razones de seguridad.

Sin embargo, he encontrado uno que se hace específicamente para lo que está haciendo: Skip32

Es posible considerar el uso de un GUID, pero tal vez usted tiene razones que desea evitar eso. (Say, su aplicación se ha hecho ya.)

Editar: En realidad, si un GUID es permisible, entonces eso le da un rango de 128 bits. Puede usar fácilmente cualquier otro cifrado de bloque. El beneficio de tener un espacio más grande (a costa de largas cadenas de identificación) es que tendrás mucha más protección de las personas que adivinan las identificaciones. (No es que una ID de orden en sí misma sea un token de seguridad de todos modos ...)

Answer 2

GUID es el camino a seguir para que

* Editar *

es posible que desee ver en este http://csharpfeeds.com/post/4382/A_shorter_and_URL_friendly_GUID.aspx

Answer 3

No creo que este esquema es que de un gran idea. ¿Por qué no verifica que un usuario está conectado y tiene acceso para ver un pedido específico?

Si REALMENTE quiere tener todos los pedidos sin autenticación, un GUID sería lo mejor.

O bien, podría tratar de obtener números de pedido con el prefijo de algo sobre el cliente. Me gusta (PhoneNumber) (1 ... 100)

Answer 4

Para cumplir con el requisito, simplemente podría usar un hash como SHA-1 o MD5 en sus índices. Estos proporcionarán la seguridad adecuada que necesita.

Para reducir el tamaño, puede cambiar a una codificación diferente; como 64 bit.

yo también recomiendo muy fuertemente insisten sobre el uso de una sal, de lo contrario los valores hash fácilmente se podían romper.

Answer 5

Si su idea es que el hecho de saber el número de orden (o URL) es suficiente para obtener información sobre el orden a continuación:

• El espacio número de pedido tiene que ser extremadamente grande, de lo contrario los atacantes y/o los clientes posiblemente buscarán en el espacio de pedido, para ver qué se puede ver.
• Debería considerar que un atacante puede iniciar sondeos graduales desde numerosas máquinas y puede ser paciente.
• El análisis del espacio de números de pedido puede mitigarse limitando la velocidad, pero es muy difícil de aplicar en un entorno web: es difícil distinguir el acceso de sus clientes del acceso de los atacantes.
• Considere también que el número de orden no es muy secreto, las personas podrían enviar correos electrónicos; una vez que sale, es imposible retraerse.

Por lo tanto, para la comodidad de verificar con un solo clic mi pedido sin iniciar sesión, ha creado un riesgo de seguridad permanente.

Incluso si aumenta enormemente el espacio del número de orden, todavía tiene el problema de que esas URL están flotando por ahí, tal vez en posesión de personas que no deberían haberlas obtenido.

Sería mucho mejor requerir una sesión de inicio de sesión para poder ver cualquier cosa, luego solo mostrarles las órdenes que están autorizadas a ver. Entonces no tiene que preocuparse por ocultar los números de orden o los atacantes adivinando los números de pedido, porque solo el número de orden no es suficiente para acceder a nada.

Answer 6

Prototipo de esta idea usando Blowfish, un cifrado de bloques con bloques de 64 bits.

Answer 7

Problemas de si debería estar haciendo esto a un lado, aquí hay un cifrado de bloque muy simple con una clave fija (ya que solo parece necesitar una permutación de todos modos).

static uint permute(uint id) 
{ 
    uint R = id & 0xFFFF, L = (id>>16)^(((((R>>5)^(R<<2)) + ((R>>3)^(R<<4)))^((R^0x79b9) + R)) & 0xFFFF); 
    R ^= ((((L>>5)^(L<<2)) + ((L>>3)^(L<<4)))^((L^0xf372) + L)) & 0xFFFF; 
    return ((L^((((R>>5)^(R<<2)) + ((R>>3)^(R<<4)))^((R^0x6d2b) + R))) << 16) | R; 
} 

Skip32 es mucho mejor en cuanto a cifras de bloque de 32 bits van, pero es un peso pesado poco cuando tres líneas (larga) harían. :-)

Answer 8

Recientemente comencé a usar Hashids conjunto de pequeñas bibliotecas. La idea es encriptar un número o una lista de números en cadena de hash como:

12345 => "NkK9" 
[683, 94108, 123, 5] => "aBMswoO2UB3Sj" 

Las bibliotecas son implementados en lenguajes de programación conocidos por varios autores. También son compatibles cruzados, lo que significa que puede codificar el número en Python y luego decodificarlo en JavaScript. Es compatible con las sales, la definición del alfabeto e incluso la exclusión de las malas palabras.

Python:

hashids = Hashids(salt="this is my salt") 
id = hashids.encode(683, 94108, 123, 5) 

JS:

var hashids = new Hashids("this is my salt"), 
numbers = hashids.decode("aBMswoO2UB3Sj"); 

Esto no es Gbno cifrado a prueba, pero totalmente suficiente para algunos sitios de intercambio de enlace permanente no predecibles.