Imaginemos por un momento que, por alguna necesidad justificada de negocio, un comercio requiere almacenar el dato del número de cuenta primario o PAN (Primary Account Number) en su entorno. Para ello, decide emplear una función de hash o “función resumen”:

Una función de hash es una función matemática que puede recibir como entrada un conjunto infinito de datos y da como resultado un “resumen” (“message digest”) o conjunto finito de caracteres que identifican inequívocamente su entrada, de forma similar a una secuencia de ADN o una huella digital. Una característica de este tipo de funciones matemáticas es que es imposible derivar u obtener la entrada original partiendo de su hash, razón por la cual también se denominan “funciones de una sola vía” o “one-way functions”.

Función de hash

Esta función de hash es una de las técnicas permitidas por PCI DSS para almacenar de forma segura el PAN, siempre y cuando se aplique al PAN completo:

No obstante, imaginemos también que este mismo comercio necesita tener visibilidad de los primeros 6 y los últimos 4 dígitos de la misma tarjeta (para temas de reconciliación o atención a reclamaciones, por ejemplo), de tal forma que opta por almacenar el hash del PAN y los primeros 6 y los últimos 4 dígitos de la tarjeta (truncamiento) en una base de datos, de la siguiente manera:

Base de datos con una tabla almacenando el hash y el dato truncado del PAN

En principio, se podría pensar que no hay ningún problema, ya que ambas técnicas (el uso de hash y el uso de truncamiento en un PAN) son permitidas por PCI DSS. Pero, de forma inadvertida, al usar de forma combinada estas dos técnicas, este comercio se está exponiendo a un gran riesgo debido a que le está facilitando a un potencial atacante que pueda obtener el dato completo del PAN mediante técnicas de fuerza bruta.

Lo que puede hacer un atacante con el hash de un PAN y sus partes truncadas

El objetivo de aplicar una función de hash sobre todo el dato del PAN es garantizar que todos los dígitos que lo componen queden protegidos. El solo hecho de conocer uno o varios dígitos del PAN y su posición le permitirían a un atacante que también cuente con el hash del PAN completo, ejecutar un ataque de fuerza bruta denominado «Known Digits Attack».

Partiendo de la premisa de que el dato del hash en sí mismo no permite la obtención del PAN que lo generó, un atacante podría empezar a hacer pruebas de fuerza bruta con los dígitos que faltan del PAN truncado, obteniendo el hash de este resultado y comparándolo con el hash que previamente ha obtenido, de la siguiente manera:

Ataque de fuerza bruta cuando el atacante conoce el hash y los datos truncados de un PAN

Cuando el resultado del hash del PAN generado por fuerza bruta coincide con el dato del hash obtenido previamente por el atacante, el PAN original puede ser recuperado.

Igualmente, teniendo en cuenta que los números del PAN siguen un formato establecido (MII, IIN/BIN y dígito de verificación), entonces el universo de las posibles opciones de permutación de dígitos en un ataque de fuerza bruta de este estilo se limita de forma drástica, permitiendo que el proceso se pueda automatizar y obtener resultados en unas pocas horas.

Siendo así, lo que en un principio se consideraba seguro, con un ataque sencillo se puede vulnerar.

Lo que puede hacer una entidad para proteger el hash de un PAN y sus partes truncadas

Sin embargo, no todo son malas noticias. A continuación, se enumeran algunas estrategias para aquellas organizaciones que requieren almacenar el hash del dato del PAN y sus partes truncadas, para hacer que este esquema sea seguro:

  • A veces, la mejor estrategia es analizar la justificación real para almacenar ambos tipos de datos (hash y truncados). Si uno de los dos (o ambos) se puede(n) excluir de este almacenamiento, el problema se soluciona por sí mismo.
  • En el proceso de obtención del hash se puede hacer uso de un valor discrecional adicional denominado “salt”. Un “salt” es valor pseudoaleatorio que se concatena al dato a proteger antes de obtener su hash. Esta acción se realiza para complicar un ataque automatizado basado en fuerza bruta, ya que el atacante debe obtener el salt (uno por cada hash), el listado de hashes y los datos truncados y, adicionalmente, por cada intento que ejecute para validar si los dígitos faltantes del PAN que intenta adivinar son correctos, debe agregar el salt vinculado con el PAN original (dato que tampoco conoce de antemano), lo cual es una tarea bastante complicada. Actualmente, el uso de un «salt» no es obligatorio por PCI DSS, pero si es recomendado.
  • Otra opción es almacenar de forma separada estos datos (en bases de datos o ficheros independientes) aplicando controles de aislamiento, segmentación, controles de acceso adicionales, evitar referencias cruzadas entre estos datos, encriptación, etc. El gran problema de este escenario es que tanto el listado de hashes como el listado de datos de PAN truncado (por separado) se pueden considerar fuera del alcance de cumplimiento de PCI DSS, con lo cual los controles de aislamiento que se apliquen entre ambos deberán estar obligatoriamente dentro del ámbito de aplicabilidad de PCI DSS.
  • En el caso que la entidad permita la obtención de los datos del PAN truncado y del hash del PAN mediante accesos específicos (uso de API, por ejemplo), se deberían implementar controles adicionales de monitorización e identificación de accesos fraudulentos que busquen la correlación de estos datos.
  • Si se cuenta con valores adicionales comunes que permitan la correlación directa entre el PAN truncado y el hash del mismo PAN (como el identificador de la transacción, el nombre del titular, etc.), entonces se deben analizar alternativas que permitan desligar estos elementos entre sí.

Recomendaciones adicionales

A continuación se enumeran una serie de recomendaciones adicionales cuando se usan los valores de hash y/o los datos truncados del PAN:

  • Los valores del hash no se pueden usar para reemplazar el segmento truncado del PAN. La función de hash debe ser aplicada a la totalidad del PAN:

hash y truncamiento

  • Siempre se deben usar algoritmos robustos de hash, conforme con lo indicado por el PCI SSC.
  • Si se emplea truncamiento, se deben tener en cuenta los formatos aceptables y la cantidad de dígitos que se pueden retener:

truncation_formats

  • No se deben emplear diferentes formatos de truncamiento sobre el mismo PAN, ya que su correlación puede llevar a la obtención de más dígitos de los establecidos.

¿Tienes alguna pregunta? No olvides dejarnos tus comentarios, visitar el foro o visitarnos en nuestras redes sociales.

Avatar

Autor: David Acosta

Asesor de Seguridad Calificado (QSA) para PCI DSS, P2PE, PIN, 3DS y TSP.
CISSP Instructor, CISA, CISM, CRISC, CHFI Trainer, CEH, OPST, BS25999 LA.