2012-06-15 55 views
6

Ya he leído Saving credit card information in MySQL database? y Storing Credit Card Information.Cómo cifrar de forma segura la información de la tarjeta de crédito en una base de datos

Soy consciente de que el almacenamiento de la información de la tarjeta de crédito requiere el cumplimiento de PCI, lo cual no es una tarea fácil.

De eso no se trata esta pregunta. Mi pregunta es la siguiente:

¿Qué es una forma segura de cifrar las tarjetas de crédito de los usuarios? Lo más simple y fácil que se me ocurre es usar una clave privada y cifrar los CC con eso. Esto no parece muy seguro porque la clave debe almacenarse en el servidor, y si un atacante puede obtener mi base de datos, probablemente también puedan obtener la clave.

Lo que me gustaría poder hacer es encriptar cada CC usando esa contraseña de usuarios como parte del proceso de encriptación. Si alguien obtiene la base de datos, no puede descifrar nada porque las contraseñas se almacenan como hashes salados. Esto funcionaría muy bien para compras transaccionales: el usuario hace clic en "Comprar", escribe su contraseña como confirmación, descifro su CC y realiza el cargo. Su contraseña solo está en la memoria durante la duración de la solicitud y nunca se escribe en el disco.

Lamentablemente, esto no funcionará para lo que estoy tratando de construir: un servicio que cobra una tarifa recurrente (por ejemplo, una vez al mes), independientemente de si el usuario está conectado o no cuando necesito cargar.

Dado este escenario, ¿existe una forma segura de almacenar CC de usuario?

+0

¿El servidor que * almacena * la información CC también debe poder * leer * la información? P.ej. Si la carga mensual puede ser realizada por una máquina fuera de línea que lee una copia de los datos cifrados, es posible que desee considerar los métodos de clave pública ... –

+0

Es de suponer que el sistema siempre está conectado y se pueden enviar datos cada vez que un usuario se registra . Sí, más fácil de asegurar con una interfaz especializada, pero implica una aplicación externa; y probablemente no sea un software web estándar, de lo contrario, probablemente muestre muchas de las mismas vulnerabilidades que el host original. Existen soluciones de terceros externas especializadas para hacer exactamente esto ya existente. – shannon

Respuesta

0

Necesita que la información de la tarjeta se encripte de forma reversible. La información de descifrado debe venir de algún lado. Usted ha dicho que los datos no pueden provenir del usuario, y no quiere que estén almacenados en el servidor, por lo que debe estar en un equipo separado que, presumiblemente, es más seguro. Y si tiene la capacidad de recordar esa información, también lo hace un atacante que ha comprometido su sistema. Entonces, presumiblemente, la información de descifrado no se recupera en el host vulnerable durante el descifrado.

Quizás considere un servicio externo en el que pueda encriptar y enviar información, tal vez uno que se especialice en el cumplimiento de PCI. Podría descifrar la información de la tarjeta de crédito cuando la envíe por segunda vez y aplicar un cargo, o podría almacenar la información de la tarjeta para usarla posteriormente. Incluso podría realizar transacciones recurrentes por usted.

http://www.authorize.net/solutions/merchantsolutions/merchantservices/automatedrecurringbilling/

acabo en Google que, yo no los recomiendo. Pero es un ejemplo.

+0

@OP: los sistemas de prevención de fraude requieren el código de verificación para garantizar que la tarjeta se guarde cuando se organiza la transacción, pero ofrecen a los comerciantes la capacidad de identificar una transacción como "recurrente" y el estado verificado persiste a través de las transacciones recurrentes. La agencia de procesamiento de tarjetas aún conserva el número de tarjeta, pero no el CVV2, para la transacción recurrente. Las mejores prácticas de transacciones recurrentes de crédito de Google si quiere saber más, pero en general, creo que tendrá a alguien más que lo haga por usted. – shannon

3

Como necesita poder descifrar, siempre existe la posibilidad de que las claves de cifrado se filtren y perderá todo. Por lo tanto, nunca llegará a la seguridad absolute, pero puede dificultar que los atacantes obtengan los datos.

Nadie más que usted realmente puede juzgar qué nivel de seguridad (u oscuridad) debe tener. Esto es muy probable una función del tamaño de la base de datos, visibilidad, etc.

Para fugas, lamentablemente tendrá que asumir que todo se filtra y tarde o temprano (por ejemplo, con ataques de fuerza bruta contra contraseñas débiles) que no ha ganado demasiado cuando salgan. Dado los últimos escándalos de fugas en tarjetas de crédito, los peores tenían el número de 3 dígitos guardado con el número de tarjeta de crédito regular, que las compañías de tarjetas de crédito prohíben explícitamente (es por eso que siempre tendrá que volver a darlo) incluso si alguien tiene la información de su tarjeta de crédito en el archivo)

Si no desea asumir la responsabilidad de almacenar y procesar este tipo de datos, una buena forma de hacerlo es con un servicio de pago externo; permítales hacer el procesamiento y simplemente afirmar que el pago ha sido procesado. Tendría que pagarles por sus servicios, pero también tendría que pagar por implementar su propia solución y por asumir el riesgo.

+0

Usted y Shannon mencionaron servicios externos, como authorize.net. Si es ilegal almacenar el número de 3 dígitos, ¿cómo implementan esos servicios la facturación recurrente? ¿Tienen algún tipo de acuerdo con las compañías de tarjetas de crédito? –

+0

Lo siento, no puedo ayudarte allí. Solo sé * que * las compañías de tarjetas de crédito prohíben conservar los 3 dígitos. Podrían ofrecer "pagos recurrentes" como un tipo de pago en su API, pero esto es solo una suposición descabellada. –

+1

Exactamente. "pagos recurrentes" es una opción que se puede configurar en el momento en que se crea una transacción. – starlocke

3

Si utiliza la contraseña como la sal para el cifrado CC, sería una forma muy efectiva de proteger la información, sin embargo, nunca podrían cambiar su contraseña ... Si se cambia, entonces la datos encriptados se pierden La línea de fondo para asegurar la clave de cifrado es hacer que sea tan difícil como sea posible encontrar ... esencialmente, cuantos más pasos use para ocultar la clave, más difícil será para ellos encontrarla ... lo que significa que es más difícil a usar y programar para ello. No hay una bala mágica en este momento para proteger todo. (Inventa una forma segura de conservar la clave y serás rico)

En cuanto al número CVV, no se puede almacenar como se mencionó anteriormente. Con cada transacción, la empresa de procesamiento de cc dará al comerciante un número de referencia que luego se utilizará en cada pago recurrente. Esto significa que si la transacción original requirió el número CVV, la lógica dictará que el pago recurrente también será autorizado por el mismo usuario que lo colocó en la primera transacción. Por lo tanto, los pagos recurrentes no necesitarán CVV para mantener el mismo nivel de seguridad.

0

Puede utilizar esencialmente varios servidores. Encripte el cc con una clave, pero mantenga esa clave en un servidor de cifrado separado, solo se puede acceder mediante un nombre de usuario maestro y una contraseña para Windows o cualquier sistema operativo que esté utilizando. De esta manera, está asegurando su clave, configurando un servicio en el servicio Encyrption para ejecutar la tarjeta a través del cifrado y luego enviarlo a la base de datos.

0

Utilice las funciones opensp de private/public de php cuando un usuario realiza una compra. Utiliza los datos en la memoria para realizar la compra y luego almacena la información usando una clave pública para encriptarla.

Para procesar la facturación mensualmente, descifra los datos usando la clave privada que podría ser ingresada manualmente o almacenada en el código. Si desea almacenar la clave ssl en el código y no tener que recordarla o obtenerla cada vez. Encriptaría la clave usando una sal almacenada en las variables de configuración + comprar una clave yubi y generar una contraseña de 32 caracteres + mi propia contraseña encima. Guarde el yubikey en un lugar seguro (Una jaula segura). Cuando necesite procesar tarjetas de crédito, hágalo con un script que se ejecute en segundo plano y ejecute toda la facturación a la vez. Para cambiar la contraseña, deberá descifrar todas las tarjetas y volver a cifrarlas con la nueva clave privada/pública, o simplemente puede descifrar y volver a cifrar la clave privada ssl.

Magic :)

0

Encripte la información de CC dos veces. Primero, encripte los datos de la tarjeta de crédito basados ​​en la contraseña del usuario (+ salt). Luego encripta el resultado de eso con la clave del servidor.

Para acceder a la información, necesita la contraseña del usuario (es decir, descifrar usando la clave del servidor, luego descifrarla a partir de la contraseña). Si la base de datos y la clave del servidor están en peligro, la información aún no se expone sin atacar primero la contraseña del usuario.

Es importante que la contraseña del usuario sea para el cifrado interno; esto le permite volver a cifrar cuando cambie las claves de cifrado del servidor.

Cuando el usuario cambia su contraseña, también vuelve a encriptar los datos. Si el usuario restablece su contraseña, entonces la información CC se debe borrar (y se pierde de todos modos, ya que no se puede desencriptar).

Cuestiones relacionadas