security - significado - wiegand 26 bits
Alguien está almacenando datos de tarjetas de crédito. ¿Cómo lo están haciendo? (11)
Almacenar la información de la tarjeta de crédito de forma segura y legal es muy difícil y no debe intentarse . No tengo intención de almacenar datos de tarjetas de crédito, pero me muero por descubrir lo siguiente:
La información de mi tarjeta de crédito se está almacenando en un servidor en algún lugar del mundo. Esta información (afortunadamente) no se almacena en el servidor de un comerciante, pero en algún momento debe almacenarse para verificar y cargar la cuenta identificada por los datos enviados por el comerciante.
Mi pregunta es esta: si se le encomendó el almacenamiento de los datos de la tarjeta de crédito, ¿qué estrategia de cifrado utilizaría para proteger los datos en el disco? Por lo que puedo decir, la información de la tarjeta de crédito enviada se verifica más o menos en tiempo real. Dudo que cualquier clave de cifrado utilizada para proteger los datos se ingrese manualmente, por lo que el descifrado se realiza sobre la marcha, lo que implica que las claves mismas se almacenan en el disco. ¿Cómo protegería sus datos y sus claves en un sistema automatizado como este?
Como comerciante puede elegir almacenar los datos CC en su propia base de datos o subcontratarlos a proveedores externos.
Los proveedores externos como IPPayments o los principales bancos como Westpac en Australia cumplen con el nivel 1 de PCI. Para las aplicaciones web, puede optar por utilizar una página web de aceptación de pagos (presentada en algún lugar en el flujo de trabajo de sus clientes) de la marca de su empresa. Para las aplicaciones de Windows (p. Ej., La aplicación CRM de la empresa) y los pagos recurrentes, generalmente tienen una puerta de enlace que utiliza su API que proporciona un servicio de tokenización, es decir, aceptan un número CC, lo registran y devuelven un token único que parece un número CC . El token se puede almacenar de forma segura en su base de datos y se puede usar para cualquier transacción adicional, pagos por lotes, conciliación, etc. con el banco. Por supuesto, el gran problema es el costo operacional por transacción. Para una utilidad que toma el pago mensual con tarjeta de crédito de un millón de clientes, el costo de la transacción puede ser sustancial.
Si elige almacenar el número CC en su propia base de datos, el triple cifrado DES es suficiente. Una mejor opción es el cifrado transparente en DB ofrecido por Oracle advanced security o SQLServer, donde incluso el DBA no puede descifrar el número CC. Luego, existe la onerosa responsabilidad de la gestión de claves, copias de seguridad, seguridad física, seguridad de red, transmisión SSL, cambio de configuración predeterminada de todos los equipos de servidor y cortafuegos, antivirus, auditoría, cámaras de seguridad y así sucesivamente ...
En primer lugar, si trabaja con números de tarjetas de crédito, deberá cumplir con PCI-DSS y, una vez que almacene, las 12 secciones de la especificación PCI-DSS se aplicarán a usted. Eso es un costo importante para la mayoría de las organizaciones, y si no tiene el tiempo, los recursos y los medios financieros, no debe ir por el camino de almacenar los números de las tarjetas de crédito.
Hemos obtenido el cumplimiento de PCI-DSS en un sistema de comercio electrónico basado en Windows que almacena tarjetas de crédito. Utiliza un cifrado AES de 256 bits. La clave misma está encriptada usando Windows DPAPI, lo que significa que solo puede ser descifrada por un proceso que se ejecute bajo la misma cuenta de usuario que la que lo encriptó. La clave encriptada se almacena en el registro.
La tecla se gira cada 12 meses, y una copia de la copia de seguridad se almacena dividida en 3 partes A, B, C y se distribuye en 3 unidades USB, cada una de ellas en manos de otra persona. La unidad 1 tiene A + B, la unidad 2 tiene B + C, la unidad 3 tiene A + C. Entonces, se requieren 2 unidades para construir una clave completa (A + B + C). Este esquema es tolerante a la pérdida de 1 de las unidades. Las partes clave en sí están encriptadas con una contraseña conocida solo por el propietario de la unidad.
Es bastante fácil almacenar un hash salado de un número de tarjeta de crédito en lugar del número mismo para búsquedas seguras. Para el 99% de los escenarios que existen, esto sería suficiente tarjeta de crédito para almacenamiento, rápido y muy seguro.
Si realmente necesita cifrado reversible de una tarjeta de crédito para algún escenario (facturación continua, por ejemplo), iría con una clave simétrica almacenada en una ubicación segura que no sea la base de datos. Ha pasado un tiempo desde que miré las especificaciones de PCI, pero estoy bastante seguro de que cumple con PCI.
Si necesita búsquedas rápidas junto con encriptación reversible, use ambas opciones: un hash y un cifrado.
Editar: Parece haber cierta controversia sobre mi respuesta. Me gustaría señalar el siguiente ensayo muy interesante de Integrity.com (PDF):
Números de tarjeta de crédito Hashing: prácticas de aplicación inseguras
Detalla muchos de los problemas relacionados con el almacenamiento de un hash de datos de tarjetas de crédito, pero su conclusión confirma mi sugerencia.
Sí, un hash sin formato de la tarjeta no es seguro; es por eso que saldamos nuestros hashes! Pero una sal estática tampoco es segura, permiten la creación de tablas de arcoiris para sales estáticas conocidas. Entonces, es mejor hacer que nuestras sales varíen de alguna manera que sea impredecible. En el caso de las contraseñas, es suficiente usar un hash aleatorio separado para cada contraseña que se comprueba; incluso puede residir en la misma tabla / fila que la contraseña hash. Para el caso de las tarjetas de crédito, esto debería ser el mismo: una sal aleatoria para cada instancia de la tarjeta de crédito que se está procesando. Si el número de la tarjeta de crédito se almacena por transacción, una sal por separado para cada transacción.
Existen ventajas y desventajas para este enfoque, pero es lo suficientemente seguro. Los pros son la falta de gestión de claves; la sal y el hash están ahí, y no necesitan cambiar mientras permiten verificaciones de auditoría del hash; por ejemplo, ¿ese hash de tarjeta de crédito coincide con este número de tarjeta de crédito conocido?
Los contras están en búsqueda; no es posible buscar efectivamente un número de tarjeta de crédito en particular en muchas transacciones.
Por supuesto, de todos modos tendrás este problema con el cifrado externo; a menos que la base de datos esté cifrada (algo que solo admiten algunas bases de datos), no podrá realizar búsquedas muy bien. Incluso entonces, el cifrado en la base de datos o incluso en el nivel de la tabla reduce la efectividad de la búsqueda de manera significativa.
Las últimas veces que trabajé con pagos con tarjeta de crédito, nunca almacenaste realmente la información CC real en tus propios servidores. Dejó que la puerta de enlace de Pagos maneje eso. Con lo que terminó fue un ID de transacción que podría usar para verificar que la tarjeta de crédito aún fuera válida y tuviera la cantidad solicitada de efectivo disponible. Luego, una vez que empacó las cosas que compraron, emitiría un comando de captura en la Pasarela de pago.
Este enfoque simplificó en gran medida el proceso de integración de pagos CC en un sitio, ya que todo lo que alguna vez necesitó saber fue el ID de transacción para un cliente en particular. Por supuesto, esto no le permitió hacer el amazon - "truco" de mantener su información CC para hacer compras con un clic. Si el ID de transacción se ha visto comprometido, todo lo que se podría utilizar es cobrar el pago anticipadamente o cancelar la transacción por completo (en cuyo caso lo averiguará cuando verifique que la autorización todavía era válida antes del envío). La transacción no se pudo usar para cobrar una suma mayor a la que el cliente ya había aprobado, ni permitiría que alguien la recolecte en una cuenta diferente a la que se configuró para la "tienda".
Tal vez no sea la respuesta exacta que estabas buscando, pero quizás podría resolver tu problema general sin tener que gastar una fortuna en proveedores de seguridad.
Para que los proveedores procesen y almacenen su información de tarjeta de crédito, generalmente deben obtener la certificación PCI. Los requisitos deben describirse here . Algunos de los requisitos son muy sencillos, y otros son vagos y abiertos a la interpretación. Pasar por el proceso no es divertido, y una compañía que tiene la certificación no significa que sus datos estén seguros.
Pero es mejor que nada, supongo.
Para responder a su pregunta específica, es posible almacenar la clave de cifrado de la tarjeta de crédito cifrada en el disco. La clave de cifrado clave puede derivarse de una frase de contraseña que debe ingresarse cuando se inicia el servidor. El esquema de división secreta de Shamir se puede usar para que se necesiten k de N recursos compartidos para construir el secreto que se utilizará como clave clave de encriptación. La clave / secreto de cifrado descifrado se almacena en la memoria. Si el servidor debe reiniciarse, entonces necesita k acciones. Esto es, por supuesto, una gran sobrecarga y la mayoría de los comerciantes que conozco no implementan esto. Sin embargo, generalmente almacenan la clave por separado de los datos cifrados para cierta seguridad intermedia, por lo que el acceso a uno no significa automáticamente el acceso al otro en su totalidad (aunque sigue siendo muy malo).
Eliminé el contenido de mi publicación original porque no respondía directamente la pregunta. Baste decir que la gestión de claves y el cifrado correcto son una pieza importante, pero aún son una pequeña parte de la historia.
Los auditores de PCI no pueden asegurarse de que todo se haga correctamente.
Si desea eliminar los dolores de cabeza por robo de tarjetas de crédito, pídales que utilicen valores de sal no almacenados en la base de datos (además de los valores de sal almacenados en la base de datos). Acostumbrándolos con cualquier algoritmo de hash moderno prácticamente evitará la mayoría de los problemas con el robo de la tarjeta de crédito, pero significa que los consumidores deben volver a ingresar su tarjeta de crédito en cada compra. Después de haber trabajado en un proyecto que se ocupaba del almacenamiento de números de tarjetas de crédito, descubrí que los reducían los costos de revisión de seguridad en un orden de magnitud (se concede que el proyecto era anterior a las preocupaciones de PII).
Si va a usar cifrado simétrico, ingresa a un nuevo ámbito de complicación que todo se reduce a la administración y control sobre las claves de descifrado. Diré que incluso si tiene los números de las tarjetas de crédito, tendrá que encargarse de la encriptación reversible, ya que toda la PII (información de identificación personal) debe estar encriptada. SQL Server 2008 tiene una nueva arquitectura de complementos de gestión de claves extensible que permite utilizar programas de terceros proveedores para gestionar el control de las claves de descifrado, incluidas las claves divididas.
Para obtener más información: implementación de SQL Server 2008 en función de las normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS) versión 1.2.
Si estuviera almacenando el número, sería un proveedor de servicios gigante con una base de datos masiva. Esa base de datos se extiende a través de una matriz de almacenamiento altamente redundante que consta de múltiples gabinetes, en salas separadas o, idealmente, en ubicaciones geográficas separadas, conectadas por una SAN. Mi mayor amenaza interna es la planta física distribuida, el flujo constante de unidades gastadas y varios cambios diarios de técnicos, administradores e ingenieros. Es una gran amenaza.
Por lo tanto, cifraría los datos en una computadora físicamente aislada que se conecta al almacenamiento masivo a través de una red. El software sería lo más simple posible: cifrado y verificación de números. Las interfaces públicas y la lógica de negocios van a otro lado. Los accesos se registrarán en una SAN separada.
Cifre con algo como AES. La clave AES en bruto solo se almacena en RAM. La clave está envuelta en un archivo PGP para cada administrador, que tiene su propia frase de contraseña para habilitar el servidor. Al personal menos confiable se le pueden dar frases de contraseña parciales para usar en la recuperación de desastres, o las frases de contraseña se pueden almacenar en una bóveda en alguna parte. Para el cifrado, elija un vector de inicialización único (IV) para cada número de tarjeta, cifre AES con ese IV y almacene el IV y el número cifrado en la SAN. El descifrado solo ocurre usando una interfaz de cliente privilegiado; las conexiones de clientes normales que se usan para las compras nunca pueden obtener un descifrado.
Su suposición de que el comerciante debe almacenar la tarjeta de alguna manera es incorrecta. Lo más probable es que el comerciante esté almacenando un token que recibió de la pasarela de procesamiento de pagos la primera vez que usó la tarjeta. El token identifica de manera única la combinación de comerciante y tarjeta. Posteriormente, puede realizar compras a ese comerciante sin tener que volver a suministrar su número de tarjeta. Si la base de datos del comerciante está en peligro, los tokens tienen poco valor para el atacante. Solo son válidos para ese comerciante, y todos pueden cancelarse de una vez cuando se detecta la infracción.
cualquier sistema automatizado para descifrar información cifrada será completamente inseguro. Al automatizar el proceso, está derrotando el cifrado. Cualquier información encriptada solo debe ser descifrada por una clave secreta ingresada por el usuario.
En algunas situaciones, las claves de cifrado no se almacenan en el disco sino en algún dispositivo de hardware. O bien se utiliza un servidor de cifrado especial para encriptar / descifrar o el descifrado se hace usando una clave almacenada en, digamos, un dongle de hardware. De esta forma, un pirata informático no puede robar las claves de descifrado sin robar el dispositivo físico que las contiene (ya que la clave nunca abandona el dispositivo).
Otro método que he visto es almacenar datos cifrados en una base de datos / centro de datos que no tiene conexión directa con el mundo exterior (no puede hackear lo que no puede acceder). Un servidor de interfaz se encuentra entre la parte "segura" de la red y la parte "insegura" de la red como un proxy. Obligar al tráfico seguro a canalizarse a través de este punto de bloqueo de seguridad puede dificultar el acceso de un intruso a los datos protegidos.
Ninguno de estos significa que sus datos son perfectamente seguros, por supuesto.