software - encryption unsuccessful

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

Question

Me gustaría dar a los clientes un número de pedido 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é sucede si cifro los identificadores de los empleados de Apple, Inc. para evitar que Steve Jobs solicite al 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

GUID es el camino a seguir para eso

* editar *

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

Answer 2

La mayoría de los sistemas de cifrado de bloques van a usar bloques de tamaño superior a 32 bits, por razones de seguridad.

Sin embargo, encontré uno que está hecho específicamente para lo que estás haciendo: Skip32

Puede considerar el uso de un GUID, pero quizás tenga motivos para evitarlo. (Por ejemplo, su aplicación ya está hecha).

Editar: en realidad, si se permite un GUID, 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 sea una identificación de la orden en sí misma debería ser una ficha de seguridad de todos modos ...)

Answer 3

No creo que este esquema sea genial de una 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.

También recomendaría encarecidamente insistir en el uso de una sal, de lo contrario, los valores hash podrían romperse fácilmente.

Answer 5

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

Answer 6

Si su idea es que solo saber el número de pedido (o URL) es suficiente para obtener información sobre el pedido, entonces:

• El espacio del número de pedido debe ser extremadamente grande, de lo contrario los atacantes y / o los clientes buscarán el espacio del pedido, para ver qué se puede ver.
• Debería considerar que un atacante puede lanzar sondeos graduales desde numerosas máquinas y puede ser paciente.
• Probar el espacio de números de pedido puede mitigarse limitando la velocidad, pero eso 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, aún 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 ver cualquier cosa, y luego solo mostrarles las órdenes que están autorizados 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 7

Si tiene que hacer 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 lo que respecta a las cifras cifradas de 32 bits, pero es un poco pesado cuando lo hacen tres líneas (largas). :-)

Answer 8

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

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

Las bibliotecas se implementan en populares lenguajes de programación 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.

Pitón:

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 un cifrado a prueba del gobierno, pero es totalmente suficiente para algunos sitios de intercambio de enlaces permanentes no predecibles.