¿Cuántas rondas deben usarse para codificar números de tarjeta?

Question

¿Cuántas rondas deben usarse para codificar números de tarjeta?

#1 de ThoriumBR (38 votos)
#2 de Conor Mancone (13 votos)

3

Queremos que la capacidad de los pagos realizados sin iniciar sesión utilizando uno de sus métodos de pago guardados se asocie con el método de pago guardado. P.ej. si compran una suscripción recurrente a la revista 1 usando la tarjeta de crédito 1, luego compran otra suscripción a la revista 2 con la tarjeta de crédito 1 (una vez más), cuando inicien sesión en su cuenta, esto debe mostrar que ambas revistas se compraron utilizando el mismo método de pago . (No es que ambos hayan sido comprados usando dos tarjetas separadas que terminan con los mismos 4 últimos dígitos).

Como no han iniciado sesión durante estos dos pagos, no hay forma de que puedan elegir el método de pago existente. Internamente, debemos darnos cuenta de que este método de pago se ha utilizado antes y "eliminarlos".

Mi solución a este problema es usar Blowfish para copiar los detalles de la tarjeta:

private static String hashSalt(Long userId) {
    final Long rounds = 10
    String userHash = sha1("$userId" + GLOBAL_SALT).substring(0, 16)
    return "\a\$$rounds\$$userHash"
}
private static String mergeCardDetails(String number, String cvv, String expirationMonth, String expirationYear) {
    return "card:$number:$cvv:$expirationMonth:$expirationYear"
}

hash = BCrypt.hashpw(mergeCardDetails("4111111111111111", "123", "05", "22"), hashSalt(userId))

Actualmente, el conteo de la ronda se establece en 10. Sin embargo, me doy cuenta de que este es un número muy bajo, ya que el espacio para buscar números de tarjeta es muy bajo .

Mi pregunta, ¿cuántas rondas son adecuadas para los números de tarjeta hash, hoy?

Sé que en el futuro será necesario aumentar el recuento de la ronda, lo que dará como resultado métodos de pago duplicados ...

pci-dss blowfish

pregunta Chris Smith 03.07.2018 - 17:37

fuente

2 respuestas

Lea otras preguntas en las etiquetas pci-dss blowfish

¿Las implementaciones de fTPM protegen contra ataques físicos? ¿Cómo se pueden detectar los implantes y las puertas traseras de la NSA? [cerrado]

score 38 · Answer 1

Parece que tienes los datos de la tarjeta hash junto con el CVV. Eso es malo, muy malo. No hagas eso Siempre. Y no hay manera de hacer lo incorrecto de la manera correcta.

"Un hombre puede hacer algo correcto de una manera incorrecta, pero no puede hacer algo incorrecto de una manera correcta. Porque no hay una manera correcta de hacer el mal". _src

Hay plataformas de craqueo de hash muy baratas en todo el mundo que pueden probar millones de hashes por segundo. La ruptura de sus hashes se puede hacer muy rápido, si tiene en cuenta que tiene un puñado de bancos o emisores válidos, por lo que los primeros 6 dígitos se toman de una tabla, no el espacio de búsqueda completo. Una fuga de la base de datos y todos los datos financieros están disponibles en los foros clandestinos.

No comprometa su seguridad por un pequeño aumento en la comodidad. No es difícil para el cliente escribir la tarjeta nuevamente, o iniciar sesión en Paypal para pagarle, pero será terrible si recibe un correo de usted informando que todos los datos de su tarjeta se filtraron y que tienen que cancelar y volver a emitir sus tarjetas. un ojo en su cuenta para encontrar cualquier compra fraudulenta.

No almacenar información de pago. Deja que la pasarela de pago lo procese. Si maltratan los datos de la tarjeta, está en ellos, no en ti.

No almacenar datos de la tarjeta. Nunca almacene el CVV, hash o no, encriptado o en texto plano, en clear o base64 o cualquier otra forma.

Solo un poco de matemáticas para el tiempo de craqueo.

Los primeros 6 dígitos son el identificador del emisor. Hay menos de un millón, por lo que puede mirar en una mesa y obtener todas las posibles, y elegir las más comunes. Bank of America, Citibank, HSBC, Chase. Tendrá alrededor de cien para los primeros 6 dígitos.

Para una MasterCard, los siguientes 9 números son el número de cuenta y el último dígito es el dígito de verificación. Puede calcular la última manera más rápida que lanzarla a la función hash, por lo que tendrá 1,000,000,000 números de cuenta posibles y alrededor de 100 posibles emisores, totalizando 10 ¹¹ números de tarjeta posibles.

Con un sistema de hashing con 8x Nvidia GTX 1080s, rompieron 105 cien OpenBSD bcrypt hashes por segundo, con un factor de trabajo de 5. No conozco los parámetros que usó en su cálculo de bcrypt, pero consideremos Lo hiciste tan bien como los desarrolladores de OpenBSD (y son bastante buenos en eso).

Al usar estos números, un solo equipo puede descifrar este espacio de búsqueda relevante en:

100,000,000,000 numbers at 105,000 per second = 950k seconds
950k seconds = 264 hours = around 11 days

Un atacante no descifrará todas las tarjetas de su base de datos en 11 días, pero descifrará todas las tarjetas de los principales emisores en menos de 2 semanas. Alquile algunas plataformas de minería Ethereum de su compañero minero de moneda criptográfica, y un atacante puede resolver todo esto en un día.

score 13 · Answer 2

Estoy de acuerdo con la respuesta de ThoriumBR. Tengo algunos detalles más y una sugerencia:

Estás intentando golpear un objetivo en movimiento. "¿Cuántas rondas es suficiente?" Es una pregunta con una respuesta cambiante a medida que cambia la disponibilidad del hardware. Cuando se trata de configuraciones de hash de contraseñas, muchos sistemas tienen métodos para aumentar automáticamente las rondas de hash con el tiempo. ¿Qué es un número mínimo de rondas? Algunas matemáticas ciertamente podrían responderlo (comparando la entropía promedio de una contraseña segura con la entropía promedio de un número de tarjeta de crédito y aumentando el costo en consecuencia). Sin embargo, sospecho que la respuesta es "un montón de rondas". Además, me preocupa que lo que estás tratando de hacer sea fundamentalmente defectuoso.

Marcó esta pregunta como "PCI-DSS", por lo que obviamente esta es una preocupación relevante. En general, la mejor manera de lograr el cumplimiento de PCI es simplemente nunca tener números de tarjeta de crédito en su servidor. El hecho de que usted está copiando todos los detalles de la tarjeta de crédito significa que tiene esos números. No recuerdo exactamente cuáles son las reglas para el cumplimiento de PCI cuando los números de las tarjetas de crédito realmente viajan a través de su servidor, pero sí sé que es mucho más complicado e incluso puede ser prohibitivamente caro. Es mucho mejor simplemente no hacerlo.

Por otra parte, la forma en la que hasble las contraseñas no es la norma y aumenta el riesgo de seguridad para tus clientes. Las sales deben ser una cadena aleatoria, no es necesario vincularlas a la identificación del usuario (también parece extraño, ya que el objetivo de esto es hacer coincidir las tarjetas de crédito entre usuarios anónimos). Además, incluir no solo el número de la tarjeta de crédito, sino también la caducidad y el CVC en el hash es una idea terrible. Para lograr lo que quiere lograr, solo necesita los detalles de la tarjeta de crédito; cualquier información adicional le permite al atacante obtener los detalles completos de la tarjeta de crédito en caso de que obtengan una fuerza bruta exitosa.

Aquí es donde entra en juego toda la idea de "No renunciar a tu propia seguridad". Si me perdonas, parece que podrías estar un poco fuera de tu nivel de experiencia cuando se trata de asegurar un cliente importante datos, por lo que crear su propio sistema para hacer coincidir las tarjetas de crédito de los clientes parece ser una buena manera de filtrar inadvertidamente muchos números de tarjetas de crédito y causar muchos problemas para su empresa.

Para resumir, es mejor que escuches la respuesta de ThoriumBR: simplemente no hagas esto. La leve mejora en la interfaz de usuario para sus clientes no vale la pena por el mayor riesgo de filtrar sus números de tarjetas de crédito. Si desea hacer esto, busque un procesador de tarjetas de crédito compatible con PCI que pueda traducir el número de tarjeta de crédito en una cadena única y segura para usted. A continuación, puede guardar y comparar de forma segura en su base de datos. El ejemplo inmediato de la parte superior de mi cabeza es raya.

Y algunos números

También estuve viendo algunos números esta mañana. He encontrado este artículo relevante:

enlace

La persona describe el uso de lo que es (probablemente) una configuración de hashing de nivel medio bajo para descifrar las contraseñas del volcado de datos de Ashley Madison. Usaron bcrypt con un factor de costo de 12 (creo que el número de rondas de cifrado es igual a 2^cost_factor , es decir, factor de costo de 12 = 2^12 = 4096 rondas de bcrypt (pero verifique absolutamente este hecho si En realidad, con esta plataforma de cracking de los chicos, tenía un índice de hash de 156 hashes por segundo. ThoriumBR describe bastante bien la entropía de un número de tarjeta de crédito (con aproximadamente 1e11 de números posibles de tarjetas de crédito), lo que significa que al romper una tarjeta de crédito el número con la misma configuración de la plataforma de hash que el tipo en el enlace anterior con un factor de costo de 12 tomará unos 20 años. La salazón se asegurará de que cada hash tenga que ser forzado de manera individual.

Por supuesto, estos números pueden cambiar de repente. La configuración de hash que cité en mi ejemplo definitivamente no es una de las mejores. Además, las cosas pueden cambiar dramáticamente si alguien crea un ASIC eficiente para bcrypt (no creo que haya uno todavía, pero podría estar mal).