Estoy desarrollando una aplicación en línea que necesita el número de seguridad social del usuario.
La aplicación no se procesará en el servidor web, así que usaré una clave asimétrica. Por lo tanto, un servidor web comprometido no debería comprometer los datos.
¿Debo agregar datos aleatorios ya que si un atacante ingresa al servidor web, probablemente también pueda obtener la clave pública y forzar una coincidencia entre el usuario y el SSN al intentar cifrar todos los SSN?
¿Eso tiene sentido y es suficiente?
Queremos que el usuario pueda continuar una aplicación usando el SSN para continuar y también nos gustaría asegurarnos de que no se usen SSN duplicados.
Por lo tanto, el servidor web debe al menos poder determinar que el SSN coincide sin saber realmente el SSN. Así que podemos almacenar un hash en otra columna similar a la forma en que se usan las contraseñas. ¿Hay una mejor manera?
¿Cómo puedo protegerme contra la fuerza bruta? SSN solo tiene unos 10B valores posibles. Eso no tomará mucho tiempo. ¿Hay una manera de frenar un ataque de fuerza bruta? Puede tomar hasta unos pocos segundos mientras una fuerza bruta se vuelva impráctica.
La búsqueda en línea muestra PBKDF2 y Bcrypt como una posible solución. ¿Tiene sentido? ¿Disminuirá eso un ataque de fuerza bruta? ¿Hay alguna otra sugerencia?
Quiero asegurarme de que no me esté perdiendo algo que nos deje vulnerables. Me doy cuenta de que no existe el 100% de seguridad, solo quiero implementar lo mejor que esté disponible y conocer el nivel de riesgo.
- Editar Para aclarar lo solicitado por Neil Smithline
-
Es necesario descifrar los datos. Sin embargo, el descifrado no ocurrirá en el servidor web. El descifrado se realizará en un servidor diferente, por lo tanto, planeo usar claves asimétricas para una medida de seguridad adicional. Por lo tanto, los datos no deben ser descifrados del servidor web solo encriptados.
-
Necesitamos poder buscar los datos en el servidor web para saber si ya existen sin descartar los datos.
A. No puedes usar la clave pública para hacer coincidir la entrada social. Dado que hay una cantidad muy limitada de SSN, aproximadamente 10B. Así que agregaremos datos aleatorios para asegurarnos contra un ataque de fuerza bruta. Me gustaría protegerme contra el atacante que comprometa el servidor web y acceda a la clave pública.
B. No puedes usar un hash simple por la misma razón que A, fuerza bruta.
En cambio, estaba pensando en utilizar potencialmente PBKDF2 o Bcrypt para ralentizar una fuerza bruta.
¿Eso tiene sentido? Cualquier otra sugerencia.
--Editar
Como explica Neil a continuación, el uso de un hash y salt para buscar duplicados no es práctico, ya que requeriría revisar toda la columna.
Por lo tanto, eliminaremos el requisito de no tener duplicados.
Lo que aún queda es, ¿qué podemos hacer para permitir que el usuario continúe una aplicación usando su SSN sin la capacidad de descifrar el SSN y sin ser vulnerable a la fuerza bruta?
¿Suficiente BCrypt? ¿Alguna otra sugerencia?
Siempre puedo solucionar este problema haciendo que los usuarios se registren y creen un nombre de usuario y contraseña primero. Sin embargo, prefiero evitar eso si puedo. A medida que crea, agrega pasos para el usuario.
¿Se puede lograr esto sin comprometer su SSN?