¿Existe un mejor algoritmo .NET para el cifrado de tarjetas de crédito?

Question

El .NET System.Security.Cryptography espacio de nombres tiene una colección bastante desconcertante de algoritmos que podría utilizar para el cifrado de detalles de la tarjeta de crédito. ¿Cual es el mejor?

Claramente debe ser seguro para una cadena relativamente corta.

EDIT: Estoy en el Reino Unido, donde entiendo que estamos bien almacenando los detalles de la tarjeta de crédito cifrada siempre que el número de CVV de tres dígitos nunca se almacene. Y gracias a todos por las excelentes respuestas.

Answer 1

Sin ofender, pero la pregunta es un poco "equivocada". No hay una solución de "bala de plata". Yo recomendaría leer sobre criptografía en general y luego hacer algunos modelos de amenazas. Algunas de las preguntas (de ninguna manera una lista exhaustiva) usted debe preguntarse:

• es el módulo haciendo el cifrado la que necesita para descifrarlo (en este caso el uso de criptografía simétrica) o va a enviar datos a otro módulo (en otra máquina) que lo usará (en cuyo caso debe considerar la clave pública de cifrado)
• ¿De qué desea protegerse? ¿Alguien accede a la base de datos pero no tiene el código fuente (en cuyo caso puede codificar la clave de cifrado directamente en la fuente)? Alguien olfateando su red local (¿debería considerar soluciones transparentes como IPSec)? Alguien robando su servidor (puede suceder incluso en centros de datos, en cuyo caso se debe considerar el cifrado completo del disco).
• ¿Realmente necesita guardar los datos? ¿No puede pasárselo directamente al procesador de la tarjeta de crédito y borrarlo después de recibir la confirmación? ¿No puedes almacenarlo localmente en el cliente en una cookie o Flash LSO? Si lo almacena en el cliente, asegúrese de encriptarlo en el servidor antes de ponerlo en una cookie. Además, si usa cookies, asegúrese de hacerlas solo http.
• ¿Es suficiente comparar la igualdad de los datos (es decir, los datos que el cliente me ha dado son los mismos que tengo)? Si es así, considere almacenar un hash de él. Debido a que los números de las tarjetas de crédito son relativamente cortos y usan un conjunto reducido de símbolos, se debe generar una sal única para cada uno de los hash.

Más tarde editar: en cuenta que los algoritmos de cifrado estándar de la misma categoría (por ejemplo 3DES y AES - siendo ambos Cyphers de bloques simétricos) son de resistencia comparable. La mayoría de los sistemas (comerciales) no se rompen porque alguien reforzó su encriptación, pero debido a que su modelado de amenazas no fue lo suficientemente detallado (o simplemente no tenían ninguno). Por ejemplo, puede encriptar todos los datos, pero si tiene una interfaz web pública que es vulnerable a la inyección de SQL, no lo ayudará mucho.

Answer 2

3des es bastante bueno, guarde la sal al costado y mantenga una clave estándar en algún lugar que no esté en la base de datos o en un archivo de configuración. De esta forma, si te patean, no pueden descifrarlo.

Answer 3

Según las reglas de cumplimiento PCI DSS, cualquier estándar de cifrado líder en la industria es suficiente. Por lo tanto, un 3DES con una clave de 256 bits es lo suficientemente bueno (aunque se pueden usar otros estándares). Mira esto http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

Answer 4

No importa.

Los números de tarjeta completos nunca deben tocar el disco.

Todo lo que importa es el código de autenticación.

Para rastreos, etc., solo utilizará los últimos 4 dígitos xxxx xxxx xxxx 1234 y caducará la fecha.

Si va a almacenar números de tarjeta, la opción de criptografía será obligatoria para el banco adquirente.

A menos que usted sea el adquirente, en ese caso debería haber un viejo programador de UNIX/db2 que debería preguntar.

"¿No pueden almacenar localmente en el cliente en una cookie" < - NUNCA

Answer 5

También está el aspecto legal a tener en cuenta. No conozco la situación en otro lugar, pero en Alemania simplemente no está permitido almacenar números de tarjeta de crédito ¹⁾. Período. No importa si los encripta o no y en qué formato los almacena.

Todo lo que puede hago (y aquí me refiero desde la memoria, sin ningún conocimiento judicial) es almacenar un hash fuerte (SHA-256?) Del número de tarjeta de crédito, junto con los últimos cuatro dígitos y la número de cuenta. Y sí, es trivial reconstruir el número completo solo con esta información. Las leyes no son siempre lógicas.

---

¹⁾ Excepto si eres un instituto de tarjeta de crédito de certificación federal.

Answer 6

Sugerencia: Debe investigar si es legal almacenar números de tarjetas de crédito. En Suecia, por ejemplo, deberá estar certificado por el PCI (Payment Card Industry), donde se probará su seguridad interna y externa (una larga con muchas otras cosas).

Debería pensar una o dos veces antes de almacenar la información de la tarjeta de crédito, ya que los costos legales de hacerlo mal podrían ser costosos.

Answer 7

que me gustaría añadir a la vista que simplemente no debe almacenar a menos que tenga una muy buena razón para, y almacenarlos en una cookie es una muy mala idea- son sólo a too easy apoderarse de (lo que sucede si alguien roba una cookie, entonces no importa cuán encriptada sea).

Si necesita hacer pagos repetidos, la mayoría de los proveedores de CC ofrecerán una forma de hacerlo almacenando algún tipo de token del pago inicial, sin guardar el número de tarjeta (podría mantener los últimos 4 dígitos en mostrar al cliente para que sepan qué tarjeta se almacena).

Realmente, ¡simplemente no lo hagas!

También nunca debe mantener el código CCV.

Answer 8

No te olvides de la integridad aquí. Hay ataques de falsificación contra la criptografía lista para usar cuando el atacante no conoce la clave, pero puede manipular el texto cifrado. Estos pueden ser particularmente desagradable cuando:

• encriptación de cadenas cortas,
• con subseries conocidos

Eso es exactamente el caso de las tarjetas de crédito. Por lo tanto, el uso de System.Security.Cryptography AES o 3DES en modo CBC sin hacer rodar su propia suma de comprobación puede ser peligroso. Leer: existe la posibilidad de que un atacante sin la clave secreta pueda reemplazar un número de tarjeta de crédito por otro.

Answer 9

Si está utilizando una puerta de enlace de pago de un tercero, no necesita almacenar los números.

No tiene sentido.

Answer 10

Encripte la tarjeta de crédito con una clave pública. Entregue la clave privada solo a la máquina del procesador de pagos. La máquina del procesador de pagos puede consultar la base de datos y hacer el trabajo, y nadie más, ni siquiera la máquina que agregó la entrada, podrá descifrarla.

Algo así como el openssl_seal de PHP, aunque si lo desea, quizás con un algoritmo diferente.