He estado siguiendo esta muy útil publicación de Thomas . Mi caso de uso es ligeramente diferente. Estoy desarrollando una aplicación móvil que requiere que se almacenen datos confidenciales en el dispositivo en un archivo SQLite. Estoy usando SQLCipher para cifrar el archivo. La clave de cifrado se basa en una contraseña de 10 caracteres (al menos una mayúscula, una minúscula, un símbolo y un número) introducida por el usuario en la primera autenticación en ese dispositivo. SQLCipher utiliza internamente PBKDF2 para generar la clave de cifrado. Según la Publicación NIST , la entropía de esta frase de contraseña es de alrededor de 28 bits.
Así que de acuerdo con la fórmula en el post mencionado anteriormente:
v * 2n-1 > > f * p
v: Tiempo requerido para calcular la clave derivada (DK) usando una frase de paso candidata usando la función PBKDF2.
n: Entropía de la frase de contraseña en número de bits.
2n: Total de combinaciones posibles usando n bits.
2n-1: Promedio de 1 y 2n. El número promedio de frases de paso candidatas que se intentarán antes de que se rompa la frase de paso real.
f: Factor que representa la potencia de cómputo disponible para el atacante en relación con el sistema en el que se calculó "v".
p: paciencia del atacante en términos de tiempo.
p sale a ser 7.77 días, usando f = 200 (el atacante tiene 200 veces la potencia de cálculo) y usa 1 segundo para una derivación clave. Como se mencionó anteriormente, n = 28.
Ahora voy a mis preguntas:
- ¿Qué es una estimación realista para f. Sé que nadie puede aportar un valor exacto, pero las estimaciones como el peor de los casos, el caso promedio, etc. serían útiles.
- La publicación NIST mencionada anteriormente también sugiere el uso de un diccionario junto con reglas de composición para garantizar contraseñas más seguras. He descargado diccionarios de contraseñas aquí. Ahora quiero saber qué significa la publicación NIST por transformaciones de palabras de diccionario. ¿Significa que si el diccionario contiene la palabra "rock" , debería rechazar todas las frases de paso que tengan rock en ellas? Entonces, rechazar
rock@Ston3ea pesar de que parece una contraseña segura. - Quiero usar pimienta, así es como planeo usarla. La frase de paso se ingresa a PBKDF2 y
[random-salt(256bit)+pepper(256 bit)]es la sal para la operación. Varios miles de iteraciones. Luego alimente el hash resultante a SQLCipher, que a su vez realiza 64000 iteraciones de PBKDF2 con sal de 128 bits para alcanzar la clave de cifrado. ¿Hay algún problema con el uso sugerido anteriormente de pimienta y PBKDF2? - Uno de mis colegas sugirió no almacenar la frase de contraseña con hash en ningún lugar del disco. En su lugar, realice una consulta SQLite para obtener información del usuario de la base de datos (esta información es necesaria de todos modos y, por lo tanto, no es una sobrecarga). SQLCipher dará un error si la contraseña ingresada es incorrecta, ya que la clave de cifrado generada también será incorrecta y los datos de SQLite descifrados no tendrán ningún sentido (no están correctamente formateados como espera SQLCipher). La ventaja que veo en este enfoque es que la frase de contraseña ahora no se almacena tal como está, pero su información se distribuye en datos SQLCipher. Así que ahora el atacante no puede copiar el valor hash de un archivo y pegarlo en su código y ejecutar un ataque de diccionario sin conexión. Aún puede copiar el archivo SQLite en su computadora, pero ahora para verificar la contraseña, un atacante tendrá que realizar consultas en la base de datos o al menos validar la base de datos de alguna manera. Supongo que, si bien las GPU son rápidas para calcular los hash, no pueden realizar estas operaciones de base de datos con la misma eficiencia. Por lo tanto, la idea es reducir la velocidad del atacante al introducir operaciones para las que su hardware no está optimizado. ¿Mi suposición es correcta?