¿Una clave privada SSH protegida con frase de contraseña es susceptible de un ataque de diccionario?

Lo que importa no es la longitud de la frase de contraseña, sino su aleatoriedad; Es decir, lo diferente que podría haber sido. La longitud deja espacio para la aleatoriedad, pero no la genera.

El cifrado simétrico de las claves privadas SSH no está muy bien diseñado; se basa en algunas características antiguas de OpenSSL, que datan de antes de hashing de contraseña era un problema bien entendido. Consulte esta respuesta para un análisis detallado. La conclusión es que los atacantes podrán probar contraseñas potenciales por mil millones por segundo, a menos que inviertas algún esfuerzo en envolver tu clave en un objeto PKCS # 8 con PBKDF2 y suficientes rondas.

Si genera su contraseña como una secuencia de letras, cada una elegida al azar y de manera uniforme, obtendrá 4.7 bits de entropía por letra (porque 26 es aproximadamente igual a 2 ^4.7 ). Para alcanzar un nivel de protección decente (por ejemplo, 100 bits), necesitará 22 letras ... Si prefiere generar palabras significativas , diga entre una lista de 2048" palabras comunes ", luego obtendrá 11 bits por palabra y 9 palabras lo llevarán a 99 bits de la entropía. De nuevo, cada palabra debe elegirse al azar, de manera uniforme e independientemente de las otras palabras.

Con PKCS # 8 + PBKDF2 y un millón de rondas (OpenSSL necesitaría un cierto esfuerzo para producir eso), ganas 20 bits (porque 2 ²⁰ es aproximadamente igual a un millón).

Recuerde que recordar , de hecho, puede ser complicado. Recordará una frase de paso muy larga, pero solo si la escribe con la frecuencia suficiente. Si no lo haces, entonces el olvido está casi garantizado. Le sugiero que imprima su frase de contraseña muy larga y la guarde en una caja fuerte del banco (imprima con una impresora láser, no con una impresora de inyección de tinta: la tinta de esta última puede desaparecer bastante rápido). O, más sencillo, corte al intermediario e imprima la propia clave en el papel que puso en la caja fuerte del banco.

^{(*) Nota: los sistemas de impresión pueden mantener una copia en caché de trabajos de impresión anteriores. Eliminar todos los rastros puede ser complicado. Puede usar un proceso de "impresión manual" con un bolígrafo y su mano ... para un almacenamiento realmente prolongado, considere grabar en piedra o en algún metal resistente al óxido.}

  

Si esta clave privada SSH no es realmente descifrable, tengo la intención de protegerla con una frase de paso MUY larga y luego olvidarme de protegerla.

Las claves privadas cifradas son susceptibles de ataques de fuerza bruta si el atacante puede poner sus manos en su clave privada cifrada. Y si él no puede, entonces no lo son. El cifrado no es mágico; por lo general es un triple-DES muy común, y siempre es un ataque sin conexión, por lo que el atacante es libre de usar hardware dedicado.

Probablemente, colocar la clave cifrada en el buzón de Gmail o Google Drive o Dropbox sea lo suficientemente seguro. La lista de personas interesadas en su clave no se solapa mucho con la lista de personas que tienen acceso a su cuenta de Gmail.

Pero mostrarlo públicamente en tu página web es un poco exagerado. Literalmente estás pidiendo que alguien intente descifrarlo. Por lo menos, poner medidas para evitar el acceso a observadores casuales.

Una contraseña alfanumérica de 20 caracteres tiene aproximadamente 120 bits, que la tecnología actual no puede forzar con fuerza bruta. Pero aún así, un poco de sentido común probablemente esté en orden.

Este es un tema muy interesante. Uno que ha sido respondido antes en Stack Exchange. Bruce Schneier es un reconocido experto en criptografía. Puede encontrar un artículo sobre el tema de los ataques de fuerza bruta aquí:

¿Por qué no usar claves de cifrado más grandes?

Los pasajes más interesantes se reproducen aquí:

  

Las longitudes de clave más largas son mejores, pero solo hasta un punto. AES tendrá   Longitudes de clave de 128 bits, 192 bits y 256 bits. Esto es mucho más largo que   Necesario para el futuro previsible. De hecho, ni siquiera podemos imaginar una   mundo donde son posibles las búsquedas de fuerza bruta de 256 bits. Requiere   Algunos avances fundamentales en la física y nuestra comprensión de la   universo.

     

Una de las consecuencias de la segunda ley de la termodinámica es que una   Cierta cantidad de energía es necesaria para representar información. A   registrar un solo bit cambiando el estado de un sistema requiere una   cantidad de energía no inferior a kT, donde T es la temperatura absoluta   del sistema yk es la constante de Boltzman. (Quédate conmigo; el   La lección de física casi ha terminado.

     

Dado que k = 1.38 × 10 ⁻¹⁶ erg / K, y que la temperatura ambiente de   El universo es 3.2 Kelvin, una computadora ideal que funciona a 3.2 K lo haría   consume 4,4 × 10 ⁻¹⁶ ergs cada vez que se establece o se borra un poco. Para ejecutar un   computadora más fría que la radiación de fondo cósmico requeriría   Energía extra para hacer funcionar una bomba de calor.

     

Ahora, la producción de energía anual de nuestro sol es de aproximadamente 1.21 × 10 ⁴¹ ergs.   Esto es suficiente para alimentar aproximadamente 2.7 × 10 ⁵⁶ cambios de un solo bit en nuestra   computadora ideal suficientes cambios de estado para poner un contador de 187 bits a través   Todos sus valores. Si construimos una esfera de Dyson alrededor del sol y la capturamos.   Toda su energía durante 32 años, sin ninguna pérdida, podríamos potenciar una   computadora para contar hasta 2 ¹⁹² . Por supuesto, no tendría la energía.   para realizar cualquier cálculo útil con este contador.

     

Pero eso es solo una estrella, y una miserable en eso. Un tipico   supernova lanza algo así como 10 ⁵¹ ergs. (Cerca de cien veces como   Se liberaría mucha energía en forma de neutrinos, pero déjalos   ir por ahora.) Si toda esta energía pudiera canalizarse en una sola   Una orgía de cómputo, un contador de 219 bits podría ser ciclado a través de todos   sus estados.

     

Estos números no tienen nada que ver con la tecnología de los dispositivos;   Son los máximos que permitirá la termodinámica. Y ellos   implica fuertemente que los ataques de fuerza bruta contra claves de 256 bits serán   no es factible hasta que las computadoras se construyen a partir de algo más que materia   y ocupan algo más que el espacio.

Espero que encuentres esto de interés.

Esta es una pregunta antigua, pero en caso de que alguien se encuentre con esto buscando respuestas, las cosas han cambiado desde entonces :

 -o      Causes ssh-keygen to save private keys using the new OpenSSH
         format rather than the more compatible PEM format.  The new
         format has increased resistance to brute-force password cracking
         but is not supported by versions of OpenSSH prior to 6.5. Ed25519
         keys always use the new private key format.

(de la página de manual de ssh-keygen)

Aparentemente, este utiliza bcrypt , lo que se considera bastante lento , fuerte KDF. Si bien su uso de memoria fija lo hace más vulnerable a los ataques paralelos masivos que usan GPU, FPGA o ASIC que algo como scrypt (que puede ajustarse para requerir una cantidad de memoria limitada para computar), está a la vanguardia de la única ronda de MD5 que Utiliza el formato antiguo.

Además, puede usar la opción -a para especificar el factor de trabajo utilizado, que se puede usar para aumentar aún más la resistencia de fuerza bruta del archivo de claves. Vale la pena experimentar con esto para encontrar el valor más alto tolerable; Utilicé 200, que en mi anterior segunda generación de dispositivos móviles i7 tarda aproximadamente 2 segundos en descifrar.

Para referencia, aquí es un punto de referencia de lo que puede hacer una plataforma de cracking de primera línea en 2017 : ~ 100k conjeturas / seg en 8 GPU de gama alta. Esto es con un factor de trabajo bcrypt de 5, que es mucho más bajo que el que usa OpenSSH (que creo que es 16 por defecto? (Es una escala exponencial; aumentar el factor de trabajo en 1 duplica el tiempo de hashing) La relación entre -a El valor y el factor de trabajo real de bcrypt no están claros.)