.net - ejemplos - algoritmos de cifrado asimetrico
¿Existe un mejor algoritmo.NET para el cifrado de tarjetas de crédito? (10)
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.
El espacio de nombres .NET System.Security.Cryptography 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 necesita ser seguro para una cadena relativamente corta.
EDITAR: Estoy en el Reino Unido, donde entiendo que estamos bien almacenando los detalles de la tarjeta de crédito encriptada siempre que el número de CVV de tres dígitos nunca se almacene. Y gracias a todos por las excelentes respuestas.
Añadiría a la vista que simplemente no debería almacenarlos a menos que tenga una muy buena razón para hacerlo, y almacenarlos en una cookie es una muy mala idea: son demasiado fáciles de conseguir (qué sucede si alguien roba una cookie, entonces no importará qué tan encriptada sea).
Si necesita repetir pagos, 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 la tarjeta (podría mantener los últimos 4 dígitos para mostrar al cliente). para que sepan qué tarjeta está almacenada).
Realmente, ¡simplemente no lo hagas!
Además, nunca jamás deberías conservar el código CCV.
Encripta 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.
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 usará los últimos 4 dígitos xxxx xxxx xxxx 1234 y caducará la fecha.
Si va a almacenar números de tarjeta, la elección de la criptografía será obligatoria por parte del banco adquirente.
A menos que sea el adquirente, en ese caso debería haber un antiguo programador unix / db2 que debería preguntar.
"No se puede almacenar localmente en el cliente en una cookie" <- NUNCA
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 desagradables cuando:
- cifrar cadenas cortas,
- con subcadenas conocidas
Ese 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.
Según las reglas de cumplimiento de 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/
Si está utilizando una puerta de enlace de pago de un tercero, no necesita almacenar los números.
No tiene sentido.
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 preguntas (de ninguna manera una lista completa) debes preguntarte:
- ¿Es el módulo que realiza el cifrado el que necesita descifrarlo (en este caso, usar criptografía simétrica) o enviará datos a otro módulo (en otra máquina) que lo utilizará (en cuyo caso debe considerar la clave pública crypto)
- ¿Sobre qué quieres proteger? ¿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).
- ¿De verdad necesitas 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.
Edición posterior : tenga en cuenta que los algoritmos de cifrado estándar de la misma categoría (por ejemplo, 3DES y AES, que son códigos de bloque simétricos) tienen una fuerza 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.
También está el aspecto legal a considerar. No conozco la situación en otro lugar, pero en Alemania, simplemente no está permitido almacenar números de tarjetas de crédito 1) . Período. No importa si los encripta o no y en qué formato los almacena.
Todo lo que puede hacer (y aquí me refiero de 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 el 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.
1) Excepto si usted es un instituto de tarjeta de crédito certificado federalmente.
Sugerencia: debe investigar si es legal almacenar números de tarjetas de crédito. En Suecia, por ejemplo, deberá estar certificado por 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.