¿Es seguridad si se almacena en la base de datos una alternativa del número completo de la tarjeta de crédito?

Navega tus respuestas
0

Descripción breve

Me pregunto si hay una forma de almacenar de forma segura una alternativa del número completo de la tarjeta de crédito, cuyo número de tarjeta no debe ser recuperado de la alternativa.

Descripción larga

Mi objetivo aquí es almacenar de alguna manera una alternativa del número completo de la tarjeta de crédito de los clientes en la base de datos para que podamos identificar al mismo cliente en su próxima compra. Sin embargo, debería ser un gran problema de seguridad si hash / ciframos el número completo en la base de datos. Por lo tanto, me refiero a la idea de una criptografía de relleno único en la que se usó el CC como clave privada (Clave) y la clave se usará para cifrar una cadena aleatoria que seguirá un patrón (Texto sin formato). Por lo tanto, Key no se almacenará en la base de datos, y hay millones de posibilidades de Plain Text .

Flujo exacto de la idea inicial

Número de tarjeta de prueba: 4539112781735373 (fuente: enlace )

A) Cifre el número completo de la tarjeta de crédito con bcrypt con un costo de 14 ( $2y$14$g161t43Dcu7beXbIn2a55.LvH.Cpn7pwu05MPCz1PbAzbFEr0SqZS )

B) Convierta la salida de bcrypt a bytes ( 00100100 00110010 01111001 00100100 00110001 00110100 00100100 01100111 00110001 00110110 00110001 01110100 00110100 00110011 01000100 01100011 01110101 00110111 01100010 01100101 01011000 01100010 01001001 01101110 00110010 01100001 00110101 00110101 00101110 01001100 01110110 01001000 00101110 01000011 01110000 01101110 00110111 01110000 01110111 01110101 00110000 00110101 01001101 01010000 01000011 01111010 00110001 01010000 01100010 01000001 01111010 01100010 01000110 01000101 01110010 00110000 01010011 01110001 01011010 01010011 )

C) Genere 6 números aleatorios de 10 dígitos siguiendo un patrón como texto simple (el patrón debe ser lo suficientemente simple para dejar más posibilidades abiertas y complicar lo suficiente como para ser identificable, digamos que todos se pueden dividir entre 2 y 7 ) ( 1410065398 1410065384 1410065370 1410065356 1410065328 1410065342 ) y convierte los números a bytes ( 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00111001 00111000 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00111000 00110100 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110111 00110000 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110101 00110110 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110010 00111000 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110100 00110010 )

D) Realice XOR con bytes del paso B) y C), salida 101010000011001001000000101000000000100000010000100010101010000001000000011100000000001000000000001010000001101110100010101010100000000000100010110100101000101101001010101100111100001011110000000100101011100000000000001100001100101111100010001110111110000011111011100110100000001011000000000100100001101000010010000110000000100000001011111000110000001110011010011000000010001100011010100000111100101001011010101100111011101110101010000100000011001100110010000100110111001100001

E) Cuando se realice otra compra con la misma tarjeta de crédito, el paso B) se realizará nuevamente y los bytes de salida se usarán para comparar todos los registros del paso D) (independientemente del rendimiento)

F) Todos los bytes recuperados se convertirán de nuevo a números y verifique que se puedan dividir entre 2 y 7, los registros coincidentes se tratarán como un "cliente devuelto"

Lo que realmente me pregunto es ...

  1. ¿Es el flujo anterior lo suficientemente seguro como para proteger la tarjeta de los clientes? número?
  2. ¿Hay algún otro paso que pueda tomar para hacerlo más seguro?
  3. ¿Se podría aplicar algún algoritmo o patrón mejor para el paso C)?
  4. ¿Cuesta 14 lo suficientemente bueno para el paso A)? O es el costo / seguridad importa cuando se obtienen los bytes de la tarjeta de crédito?
  5. ¿Es posible descifrar el número completo de la tarjeta con el método anterior? Si es así, ¿cuánto tiempo lleva?
  6. ¿Cuál es la posibilidad de que 2 tarjetas de crédito diferentes choquen el método anterior? (mismo resultado)

Lo siento, no soy bueno en matemáticas, cifrado o seguridad, cualquier idea es bienvenida.

Comentario

Los primeros 6 y los últimos 4 dígitos del número de tarjeta se almacenan en la base de datos en otro lugar.

    
pregunta Zay Lau 15.01.2018 - 07:33
fuente

2 respuestas

10
  

Exención de responsabilidad: Dependiendo de su ubicación, puede haber leyes y regulaciones locales sobre cómo almacenar los números de las tarjetas de crédito (como PCI-DSS , por ejemplo). Míralos y cuando estén en desacuerdo con lo que estoy proponiendo aquí, haz lo que dicen, no lo que estoy diciendo.

Estás inventando un algoritmo criptográfico propio. Esto es algo que nunca debes hacer , a menos que seas parte de la muy pequeña élite de los expertos en criptografía líderes en el mundo que tienen los conocimientos necesarios en matemáticas y ciencias de la computación para hacerlo. Y teniendo en cuenta que se describe a sí mismo como "no es bueno en matemáticas, encriptación o seguridad", no parece serlo. Cuando intentes inventar tu propio cripto sin tener suficiente experiencia, harás cosas que son inútiles en el mejor de los casos y perjudicarán activamente la seguridad en el peor.

En este caso, solo use una función de hash unidireccional de valores y llámelo un día. bcrypt no es una opción adecuada aquí, porque desea poder detectar colisiones con datos que ya tiene. Pero bcrypt agrega una sal aleatoria a cada hash generado, lo que significa que múltiples hashes bcrypt de los mismos datos no se parecen en nada. Esto es bueno para el propósito que bcrypt fue diseñado para (contraseñas de hashing para la autenticación de usuario) pero malo para su propósito (huellas dactilares para detectar duplicados). Lo que quieres es un algoritmo de hash criptográfico que te dé la misma salida para la misma entrada. Los algoritmos actuales de última tecnología con esta propiedad son SHA-3 (que tiene pocas similitudes técnicas con el los algoritmos obsoletos SHA-1 y SHA-2 ) y BLAKE2 , por ejemplo.

Si desea minimizar el daño en caso de que le roben toda su base de datos:

  • Agregue un pimiento (agregue una cadena a cada número de tarjeta de crédito que sea el mismo para todos los números) a su generación de hash. De esa manera, no es posible realizar una referencia cruzada de su base de datos con otra base de datos que utilice el mismo algoritmo de cifrado.
  • Use múltiples rondas de su algoritmo hash alimentando repetidamente la salida como entrada para la siguiente ronda. Esto multiplica el tiempo que necesitará un cracker para forzar sus números CC, pero también el tiempo que le lleva procesar nuevos números.
respondido por el Philipp 15.01.2018 - 13:47
fuente
10

Francamente, esta idea no es muy inteligente. Está excesivamente complicada, y no está claro lo que estás tratando de lograr.

Su ofuscación XOR es realmente inútil porque usted es el prefijo de bcrypt de XOR-ing con su serie de números. Como el prefijo ($ 2y $ 14 $) será casi siempre constante y conocido para el atacante, puedes usarlo para decodificar los primeros 7 caracteres de tu serie de números aleatorios: "$ 2y $ 14 $" xor output_of_step_D [: 7]="1410065". Esto reduce la serie de números efectivos a solo los últimos tres dígitos. Además, sabiendo que la serie de números debe ser divisible entre 2 y 7 y reduce el inicio de los números de tres dígitos a casi 71 posibilidades (1000/14 = 71), y dado que la serie de números va a estar en orden decreciente, puede eliminar la mayor parte del resto comprobando cuál de las 71 posibilidades se pueden producir a partir del conjunto de caracteres base64 de borsypt y los dígitos ASCII de xor-ing.

Ya que la parte XOR y la parte generadora de números no realmente aleatorios aquí son efectivamente inútiles, efectivamente no es mejor que simplemente almacenar la tarjeta de crédito en bcrypt aquí.

Lo peor de este esquema es esto:

  

los bytes de salida se utilizarán contra todos los registros del paso

Debido a esta parte, será extremadamente costoso para su propia aplicación verificar si hay clientes que regresan, su rendimiento se verá afectado a medida que crezca la cantidad de clientes, y tendrá que rehacer esto en cada solicitud para almacenar en caché estos cheques. derrota el propósito No me sorprendería si esta comprobación se convierte fácilmente en su principal cuello de botella de la CPU.

    
respondido por el Lie Ryan 15.01.2018 - 13:05
fuente

Lea otras preguntas en las etiquetas

¿Por qué son aún posibles los ataques DDos? ¿Esta función hash es segura?