Cómo Facebook hashse las contraseñas

Esta construcción "Onion" puede ser peligrosa y solo debe hacerse si tienes suficientes revisores, sin embargo, agrega múltiples propiedades favorables en comparación con el hashing simple:

El primer MD5 sin sal puede ser realizado por clientes o servidores frontend. Normaliza el conjunto de caracteres y la longitud, y confunde las contraseñas desde el principio sin tener que utilizar demasiada CPU.

La sal se lee de la base de datos del usuario, por lo que no está presente en el cliente, esto fue lo que se agregaron los primeros HMAC.

El servicio de cifrado (o mejor HSM) se defiende contra la fuerza bruta (ya que la clave secreta no se conoce). De hecho, esto precede a las recomendaciones del NIST para hacer exactamente esto. Esto no se hace a menudo, ya que requiere una configuración complicada del sistema (HSM o aislamiento del proceso), algo que Facebook puede permitirse.

Dado que el paso de la pimienta puede verse comprometido por personas con información privilegiada, los datos se pasan a scrypt, una función diseñada para hacer que la prueba de contraseñas de fuerza bruta sea más costosa.

El paso final podría no ser necesario, o tal vez se usa para agregar algo de diversificación (SHA2 en lugar de SHA1).

Se parece un poco a la exageración del aceite de serpiente, pero los pasos pueden explicarse de manera razonable. Si lo comparas con el (mucho más débil) glibc-SHA2 Voodoo, está realmente limpio.

BTW1: los autenticadores memorables son generalmente algo malo, tales esquemas solo pueden reducir el riesgo de manejarlos.

BTW2: la debilidad de colisión de SHA1 no se aplica a las construcciones HMAC y el tamaño de hash MD5 corto no duele mucho aquí (ya que las contraseñas casi siempre tienen menos entropía). Sería más riesgoso para una derivación clave, pero esa no es la tarea en cuestión.

En uno de los comentarios que escribiste:

  

Estoy preguntando si algo como esto tiene sentido ahora en 2018. Vamos a usar PBKDF2 HMAC-SHA-256 con 8 bytes de sal, estamos discutiendo qué uso del esquema hash.

La respuesta a eso es no. La única parte que debe replicarse desde la solución FaceBook es usar una función de memoria y el servicio de criptoservicio. Las partes MD5 y HMAC no se agregan a la seguridad. (Aunque son bastante inofensivos.)

No debes usar PBKDF2. Para que prefieras:

1. Usar un enlace a la implementación optimizada nativa oficial de Argon2
   • Consulte la sección "Parámetros recomendados" de la especificación de Argon2 para saber cómo elegir los parámetros.
   • La elección entre Argon2d, Argon2i y Argon2id puede estar sujeta a debate. La recomendación oficial actual es Argon2i para las personas que no saben cuál elegir.
2. Actualice su software para que pueda elegir 1
3. ¿Protegiendo los datos encriptados usando una contraseña y no puedo usar Argon2? Utilice un enlace a una implementación de scrypt optimizada nativa. Establezca el parámetro de costo único lo suficientemente alto como para usar una gran cantidad de RAM y tiempo. Si parece seguro reducir el tiempo en que se ejecuta scrypt, reconsidere. Eso también reduce el costo basado en RAM.
4. ¿Protegiendo algunas contraseñas, no puedo usar Argon2 y puedo tolerar respuestas lentas? Use scrypt con los mismos parámetros de costo que 4. Si está tratando de proteger las cuentas de administrador, entonces priorice el uso de contraseñas muy seguras y cifrado primero.
5. ¿Protegiendo las contraseñas de las cuentas de muchos usuarios y no puedo usar Argon2? Utilice una biblioteca que utilice un enlace para bcrypt optimizado nativo. Asegúrese de que la biblioteca funcione correctamente alrededor de todas las peculiaridades del algoritmo bcrypt original. (La contraseña se truncará si es demasiado larga o contiene un carácter nulo).
6. Use un enlace para PBKDF2 optimizado nativo. No utilice una longitud de clave derivada mayor que la longitud de salida de la función hash subyacente.
7. No implemente su propia función de hashing de contraseña. Y sobre todo, no ejecute esa implementación en un intérprete donde será mucho más lento. Actualizar!

En cuanto a si el método FaceBook es seguridad por oscuridad. No. Pero las partes HMAC y probablemente la parte MD5 son redundantes. La parte cryptoservice probablemente usa un HSM. Esto debería permitir que los hash de contraseña se cifren / descifren sin que necesariamente se exponga la clave de cifrado al tipo de piratas informáticos que pueden robar una base de datos de hash de contraseña. El uso de algoritmos de cifrado convencionales con una clave secreta no cuenta como oscuridad. La contraseña todavía tiene que estar marcada en caso de que alguna vez se haya filtrado la clave. Para eso es scrypt, pero ahora debería preferirse Argon2 .

Editar: ver comentarios. Como se presenta en la diapositiva, la contraseña no se encripta. HMAC es una forma, al igual que hash. La alternativa de cifrar después de hash es útil porque permite que la clave sea reemplazada. Los usuarios deben ingresar su contraseña si cambias la clave con esta configuración de FaceBook, además de los parámetros de salt o scrypt. Si cifra el hash, puede descifrarlo y volver a cifrarlo sin necesidad de que el usuario ingrese su contraseña. (Si alguna vez se filtra su clave ... Pero no puede volver a borrar una contraseña sin el original).

También use 20 bytes de sal. O al menos 16.