Te estás perdiendo un modelo de amenaza
Veo dos amenazas obvias, ambas involucran poder consultar tu base de datos. Seguramente hay otros (sugerencias bienvenidas):
-
A - un atacante robó tu base de datos (y el servidor salt) y quiere inferir las ID de Facebook de todos tus usuarios
-
B - Un atacante conoce la información de Facebook de un usuario específico y desea averiguar si existe en su base de datos (sin romper todas sus entradas)
-
C - Un atacante con exactamente las mismas capacidades también puede cambiar el código que se ejecuta en su servidor, agregando ladrones de información que informarán las ID / contraseñas de los usuarios a medida que inicien sesión con el tiempo
Veamos ahora tus propuestas
- Use la misma sal de servidor para todos los hashes.
Esto todavía es necesario para evitar las tablas arco iris prefabricadas, pero de hecho solo ralentizará cualquier ataque llevado a cabo para A o B. Asegúrese de combinar con una función de hashing lento para aumentar aún más la costo de encontrar sus ID de hash para A.
- Cifre el ID de usuario de Facebook en lugar de hash.
¿Cómo descifra sus ID cuando un usuario inicia sesión? Seguramente la clave de descifrado se almacena en algún lugar. Puede almacenar la clave de cifrado / descifrado en un dispositivo físico separado, por lo que los intentos de descifrado deben tener lugar en el servidor en lugar de estar realmente fuera de línea, ya que no se puede tomar la clave. También puede haber sistemas que pueden avisarle cuando se alcanza un umbral de solicitudes de descifrado, pero esta no es mi área, no sé si existe (solo tenga en cuenta que no puede confiar en su servidor para hacerlo debido a la amenaza) modelo; su servidor está caído).
También puede almacenar la sal en ese dispositivo, y luego, en ambos casos, la seguridad es un factor que determina el tiempo que tarda un atacante en cifrar / codificar un ID de usuario conocido con todas las claves / sales posibles. No soy un experto en criptografía , por lo que no puedo dar órdenes de magnitud sobre lo que es mejor hacer, pero intuitivamente un esquema de criptografía con una tecla grande es mejor (probablemente también más costoso computacionalmente). / p>
- Cree sal dinámica en función del user_id, algo como:
Hash (Hash (user_id) + user_id)
Bueno, esto es bastante inútil. Si desea complicar un ataque por la amenaza A, debe asegurarse de que la información adicional sea independiente de la ID que tiene. Por ejemplo, una dirección de correo electrónico o fecha de nacimiento variará de un usuario a otro, lo que aumentará efectivamente el espacio de búsqueda de entrada de su atacante. La amenaza B no se ve afectada en absoluto, ya que todos los datos de Facebook ya están disponibles para su atacante.
Aquí es difícil hacer algo contra B ... Si conocen su algoritmo de hash y pueden verificar si hay un hash específico en su base de datos, no puede hacer mucho. Pero, de nuevo, es más probable que sea la misma capacidad que la amenaza C, que es aún más grave. Por supuesto, una buena práctica de hash es importante para ralentizar un ataque de fuerza bruta fuera de línea, pero también debe considerar los otros problemas que enfrentará en tal escenario. Debería averiguar cómo detectar ataques y alertar a sus clientes de que podrían ser objeto de fraude o spam debido a una violación de su servicio (ya que un ataque motivado finalmente habrá recuperado todas las ID de usuario).