¿Qué tan importante es el riesgo de que alguien envíe un correo electrónico / mensajería instantánea con un hash htpasswd?

De forma predeterminada, la utilidad htpasswd tiende a usar una contraseña de hashing específica de Apache llamada "apr1" y documentada aquí . Parece ser una construcción personalizada que invoca a MD5 1000 veces. Suponiendo que no hay una debilidad estructural en esa construcción, el atacante todavía puede probar las contraseñas a una velocidad bastante rápida. Como se documenta aquí , una GPU AMD R9 290X puede calcular aproximadamente 11.5 billones de MD5 por segundo. Como cada intento de contraseña requiere mil invocaciones MD5, el atacante debería poder intentar 11.5 millones de contraseñas por segundo. Esto es bastante rápido, y uno tiene que asumir que una "contraseña de usuario normal" no durará mucho.

Incluso una fuerte 44-bit contraseña de entropía caerá dentro de una semana de cómputos, con un atacante utilizando una sola GPU lista para usar.

La identificación de la función no es difícil ya que está escrita en la propia cadena de hash (por ejemplo, comienza con $apr1$ ).

Personalmente, usaría el teléfono. Como sugiere @ André, también se puede usar PGP, siempre que PGP esté instalado. Otra opción es abrir una cuenta shell basada en SSH (esto requiere obtener una copia de la clave SSH pública del usuario) y almacenar la contraseña en un archivo en esa cuenta (o el usuario presiona su htpasswd). archivar allí).

Los correos electrónicos pueden estar bien si puede controlar el paradero del correo electrónico, lo que es difícil en general, pero en algunos casos puede ser mucho más fácil. A saber, haga que el usuario envíe el correo electrónico desde su cuenta de gmail a su cuenta de gmail; Es de suponer que los correos electrónicos enviados desde gmail a gmail no viajan sin protección a través de Internet. Sin embargo, dado que no hay seguridad alguna en los protocolos de correo electrónico, tal suposición no se puede hacer para cualquier servidor de correo electrónico.

(Como regla general, es mejor suponer que cualquier atacante que se moleste en leer tus correos electrónicos sabe bastante sobre lo que haces y para qué se intercambian las contraseñas. Después de todo, lee tus correos electrónicos .)

En general, debe tomar medidas para evitar que se exponga un hash, tal vez mediante el uso de correo electrónico cifrado o al menos una conexión cifrada. Dicho esto ...

Creo que el riesgo de que ocurra 1 (conexión comprometida) o 2 (correo electrónico interceptado) es bastante bajo, y el número 3 (resolver el hash) es la parte más importante, porque si la respuesta a 3 es que el hash no se puede resolver fácilmente, entonces no debería importarle tanto como 1 o 2. Voy a continuar con el cálculo de 11.5 millones de intentos por segundo de Tom, pero llegaré a una conclusión ligeramente diferente. Si solo usa letras y números (62 caracteres) y necesita un mínimo de 8 caracteres, el tiempo promedio para encontrar una contraseña es de alrededor de 11 días. Con un mínimo de 9 caracteres, el tiempo promedio sería de aproximadamente 2 años. Si agrega solo algunos de los caracteres especiales (18 símbolos o 80 caracteres en total), una contraseña aleatoria de 8 caracteres tomaría un promedio de 84 días para resolver, y una contraseña de 9 caracteres tomaría un promedio de 19 años. Si realizas el mínimo de 10 caracteres aleatorios sube hasta 1500 años. Agrega tantos más personajes como requiera tu paranoia.

Tengo dos pensamientos con respecto a esto:

1. Como los usuarios suelen almacenar sus contraseñas de Subversion dentro de su cliente (no necesitan memorizarlas), puede usar las contraseñas generadas. Si son contraseñas aleatorias de al menos 80 caracteres permitidos con una longitud mínima de al menos 10 caracteres, un hash comprometido no debe preocuparle.
2. Si los usuarios crean su propia contraseña y solo ve el hash, no tendría forma de saber si el usuario realmente generó la contraseña correctamente de acuerdo con las reglas especificadas. Entonces, si no puede garantizar que las contraseñas reales sigan las reglas requeridas para crear un hash seguro, entonces debe asumir que sus hashes no son seguros si están comprometidos.