Hashing SSNs y otra información de dominio limitado

Actualmente estoy trabajando en una aplicación donde recibimos información de salud privada. Una de las mayores preocupaciones es con el SSN. Actualmente, no usamos el SSN para nada, pero en el futuro nos gustaría poder utilizarlo para identificar de manera única a un paciente en múltiples instalaciones. La única forma en que puedo ver hacer eso de manera confiable es a través del SSN. Sin embargo, nosotros (además de nuestros clientes) REALMENTE no queremos almacenar el SSN.Hashing SSNs y otra información de dominio limitado

Así que, naturalmente, pensé en solo SHA hashing it ya que solo lo usamos para identificación. El problema con eso es que si un atacante conoce el dominio del problema (un SSN), entonces puede enfocarse en ese dominio. Por lo tanto, es mucho más fácil calcular los mil millones de SSN en lugar de una cantidad virtualmente ilimitada de contraseñas. Sé que debería usar una sal de sitio y una sal por paciente, pero ¿hay algo más que pueda hacer para evitar que un atacante revele el SSN? En lugar de SHA, estaba planeando usar BCrypt, ya que Ruby tiene una buena biblioteca y maneja la complejidad escalable y el salazón automágicamente.

No se utilizará como contraseña. Básicamente, recibimos mensajes de muchas instalaciones y cada uno describe a un paciente. Lo único cerca de un identificador global único para un paciente es el número de SSN. Vamos a usar el hash para identificar al mismo paciente en múltiples instalaciones.

Fuente

2010-07-23 Preston Marshall

Puede que no desee utilizar el SSN de esta manera: las personas pueden escribirlo incorrectamente en los formularios, o puede [cambiar con el tiempo] (http://www.ssa.gov/pubs/10064.html) . – sarnold

I segundo sarnold. He visto que este uso de la información del SSN simplemente falla horriblemente; otro escenario es cuando no hay SSN (inmediatamente) disponible. –

Ese es un buen punto, pero esta es una solución más confusa, no tiene que ser correcta el 100% del tiempo. Además, cuando no hay ningún SSN disponible, entonces la función simplemente no funcionará para ese paciente. La única otra opción propuesta es usar su información de seguro, que tiene sus propios problemas con la precisión y la disponibilidad. –

El algoritmo para generar Números de Seguridad Social se creó antes del concepto de pirata informático y como consecuencia son extremely predictable. Usar un SSN para la autenticación es una muy mala idea, realmente no importa qué primitiva criptográfica uses o qué tan grande sea tu valor de sal. Al final del día, el "secreto" que intenta proteger no tiene mucha entropía.

Si nunca necesita conocer el texto sin formato, entonces debe usar SHA-256. SHA-256 es una muy buena función para usar para contraseñas.

Fuente

2010-07-23 07:17:14 rook

SHA-256 es una buena función de hash, pero es demasiado rápido para este caso. Necesito algo donde pueda controlar la complejidad, como bcrypt o PBKDF2. Mi preocupación es incluso con todas las características de salazón, aún no será suficiente para evitar la reversión. –

@Preston Marshall Si desea una función de resumen de mensaje lento, entonces se confunde sobre por qué son tan útiles. NIST nunca aprobará una función de resumen de mensaje lento. El punto es que la función es muy rápida en una dirección, pero muy computacionalmente compleja para revertir. La cuestión de la fuerza bruta debe abordarse con una sal. – rook

@Preston Marshall No importa si utiliza una función de encriptación cuando el valor real es inferior a 9999 conjeturas. – rook

Primero, muchos aplausos y elogios por almacenar un hash del SSN.

Parece que está reservando los SSN como una especie de 'nombre de usuario de copia de seguridad'. En este caso, necesita otra forma de autenticación además del nombre de usuario: una contraseña, un número de licencia de conducir, un número de pasaporte, comprobante de residencia, etcétera.

Además, si le preocupa que un atacante va a predecir los 10 000 SSN principales para un paciente nacido en 1984 en Arizona, e intente con cada uno de ellos, puede agregar un limitador de velocidad cada vez mayor en su aplicación . * Para defensa adicional, construya un sistema de notificación que advierta a sys-admin cuando parezca que hay un número inusualmente alto de intentos de inicio de sesión fallidos. **

* Ejemplo de limitador de velocidad cada vez mayor: Después de cada solicitud fallida , demore la siguiente solicitud en (1.1^N) segundos, donde N es el número de solicitudes fallidas de esa IP. Rastree IP e intentos de inicio de sesión fallidos en una tabla DB; no debe agregar demasiada carga, dependiendo de la audiencia de su aplicación (¿trabaja para Google?).

** En el caso de que un atacante tenga acceso a múltiples direcciones IP, la notificación alertará a un administrador que puede usar su juicio para ver si tiene una afluencia de usuarios estúpidos o si es un intento malicioso.

Fuente

2010-07-23 17:27:20

No se usará como contraseña. Básicamente, recibimos mensajes de muchas instalaciones y cada uno describe a un paciente. Lo único cerca de un identificador global único para un paciente es el número de SSN. Vamos a usar el hash para identificar al mismo paciente en múltiples instalaciones. –

No hay puntos/aplausos/elogios por almacenar un hash largo de un SSN. Es funcionalmente equivalente a almacenar el SSN. – Slartibartfast

@slartibarfast: Funcionalmente equivalente sí. En el caso de que su base de datos se vea comprometida o robada, simplemente impidió que su compañía filtrara información de identificación. –

Si usted desea seriamente para discutir un número de seguridad social de una manera segura, hacer esto:

averiguar la cantidad de entropía está en un SSN (pista: hay muy poco Mucho menos. un número de dígito 9 elegido al azar).
Utilice cualquier algoritmo hash.
Conservar menos (la mitad?) Bits que hay entropía en un SSN.

Resultado:

Pro: Secure Hash de un SSN debido un gran número de colisiones hash.
Pro: Sus valores hash son cortos y fáciles de almacenar.
Con: colisiones hash.
Con: No se puede usar para un identificador único debido a Con # 1.
Pro: Eso es bueno porque realmente realmente no necesita usar SSN como identificadores a menos que sea el Social Administración de seguridad.

Fuente

2010-07-30 04:01:36 Slartibartfast

Hashing SSNs y otra información de dominio limitado

Respuesta

Cuestiones relacionadas