¿Es un archivo de claves aleatorio más seguro que una clave derivada?

3

Estoy diseñando una capa de cifrado para algunas API de almacenamiento en la nube propietarias. Básicamente, esto debería actuar como un adaptador transparente que encripta blobs binarios completos (archivos) en la carga y los descifra en la descarga. El motivo de esto es almacenar los datos cifrados en el lado del servidor no confiable .

Quiero usar un algoritmo de cifrado simétrico. La clave para esto se generará y se mantendrá en el lado del cliente. Como no soy un experto en seguridad, mi pregunta es si sería más seguro generar una clave binaria del tamaño deseado mediante el uso de un pseudo-RNG que confiar en un función de derivación de clave ? La clave aleatoria estaría de alguna manera asegurada con una frase de contraseña, por supuesto.

Una pregunta relacionada es cómo verificar si la frase de contraseña ingresada es correcta.

    
pregunta aeisele 21.01.2013 - 10:44
fuente

2 respuestas

2

Si genera una clave aleatoria sin contraseña, entonces su entropía (una medida de cuánto tiempo lleva encontrar la clave a través de intentos de fuerza bruta) es el tamaño de la clave. Por ejemplo, si el algoritmo de cifrado es un modo de AES-128 (una opción común), entonces una clave aleatoria tiene 128 bits de entropía, lo que significa que toma hasta 2 intentos de 128 para encontrarlo. fuerza bruta. (Eso llevaría más de mil millones de años con mil millones de PC). El riesgo con una clave aleatoria sin contraseña es que si un atacante obtiene el archivo de clave, puede usarlo como si fuera usted.

Si usa una clave que se deriva de una contraseña, su entropía será mucho menor. ¿Cuánto depende de cómo se elige la contraseña , pero tiene que confiar en haber elegido una contraseña segura, que puede ser un problema si tiene muchos usuarios en los que no se puede confiar necesariamente para no elegir Passw0rd . Además, el atacante puede obtener información sobre la contraseña al ver que escribe u otros métodos "fuera de banda".

Si genera un archivo de clave y lo protege con una contraseña, obtiene lo mejor de ambos mundos, en términos de confidencialidad. El atacante tendría que obtener tanto el archivo de clave como la contraseña para obtener la clave. Tenga en cuenta que si el atacante obtiene el archivo de la clave, puede intentar averiguar la contraseña, pero incluso entonces es posible que tenga un poco más de tiempo para cambiar la clave mientras intenta descifrar la contraseña.

Dependiendo de la aplicación, ingresar una contraseña no válida puede indicarle que la contraseña es incorrecta sin comunicarse con el servidor, o puede calcular una clave incorrecta que el servidor rechazará. Lo último es mejor porque eso significa que todos los intentos de craqueo deben llegar al servidor, y el servidor puede limitar la tasa de intentos de craqueo. De esta forma, incluso si el atacante toma el archivo clave, estará limitado a la velocidad de intentos que el servidor permita, y sabrá que algo está sucediendo. Si la contraseña se puede validar solo con el archivo de la clave, el atacante puede hacer sus intentos de desconexión sin conexión y paralelizarlos con muchas computadoras.

Ten en cuenta que si haces que sea más difícil encontrar la clave, eso te dificulta tanto a ti como a los atacantes. Si utiliza un archivo de clave, debe hacer una copia de seguridad de ese archivo de clave. Si usa una contraseña, debe hacer una copia de seguridad de esa contraseña. Si usa un archivo de clave protegido por contraseña, debe hacer una copia de seguridad de ambos.

    
respondido por el Gilles 21.01.2013 - 12:02
fuente
0

Suponiendo que no publiques el archivo de claves cifrado, esto intentaría implementar "algo que tienes" (la computadora con el archivo de claves), junto con "algo que sabes" (la frase de contraseña).

Pero entonces tienes otro problema que resolver: la distribución de claves. En la práctica esto es un gran problema. Particularmente para sistemas más generales, y especialmente para paranioa completamente generalizada.

Si desea comprometerse con la generalidad / facilidad de uso para obtener seguridad, está bien. De lo contrario, podría ser mejor enfocar la atención en otro lugar, por ejemplo. Seguridad de contraseña, recuperación y supervisión de inicio de sesión del lado del servidor.

La seguridad de la contraseña de la OMI es un punto difícil para la mayoría de los sistemas, lo que lo convierte en un área importante en la que centrarse. La recuperación es un área estrechamente relacionada (y sin cuidado, puede terminar como un eslabón débil que compromete todo el sistema). Luego, la supervisión de inicio de sesión del lado del servidor puede lograr un objetivo similar al archivo de claves, de una manera más práctica.

Estoy pensando en el monitoreo de inicio de sesión como GMail. "ADVERTENCIA: La última vez que inició sesión desde China. Si esto le parece sospechoso, haga clic aquí para obtener consejos". Detectar, mitigar y reportar ataques de fuerza bruta. A nivel del navegador (o de hecho, de la aplicación), creo que algunos sitios mantienen una lista de dispositivos usados y envían un correo electrónico al usuario cuando agregan uno nuevo. Tener que agregar nuevos dispositivos también podría ser un lugar útil para poner la advertencia "¿realmente confía en este dispositivo que está usando con todos los datos almacenados en su cuenta?".

    
respondido por el sourcejedi 21.01.2013 - 11:36
fuente

Lea otras preguntas en las etiquetas