Cómo estimar el tiempo para que un hacker descifre una contraseña segura

No es posible responder cuánto tiempo tomará descifrar una contraseña sin saber cómo se crea la contraseña. Si crea una contraseña basada en su cumpleaños (o el de un familiar), dirección, segundo nombre, etc., se supone que es una contraseña de la semana debido a principio de Kerckhoffs . Como no sabes si un atacante sabrá esta información, es mejor asumir que lo harán y que saben el formato que decidiste usar.

Por motivos de demostración, supongamos que no saben nada sobre su familia, pero saben que ha formateado su contraseña como My[B0y or G1rl][day of month with suffix][abbreviated month][symbols on keyboard corresponding to year] . Eso es 2 posibilidades para un niño o una niña, 365.25 por mes y día, y seamos generosos y digamos 50 por año. 2 * 365.25 * 50 = 36,525. Eso no es nada. Un atacante podría probar cientos de métodos similares sin tener que hacer un número significativo de hashes.

La única forma de estimar de manera confiable la fortaleza de la contraseña es basando la estimación en el método de generación de contraseña . Si su método de generación de contraseña es generar 10 caracteres alfanuméricos aleatorios, elegirá aleatoriamente 1 contraseña de un conjunto de 62 contraseñas ¹⁰ . En promedio, un atacante adivinará su contraseña después de probar la mitad de las contraseñas posibles, por lo tanto, a menos que tengan mucha suerte, tendrán que adivinar alrededor de 62 ¹⁰ / 2 = 419649682934170112 veces antes de adivinar la suya (de Por supuesto, esto podría ser más alto o más bajo si tienen suerte).

Este 8x GTX 1080 benchmark ha estado flotando por un tiempo, si asumimos que es lo que usa un atacante, ellos puede hacer 200 mil millones de hash md5 o 826 bcrypt * hashes por segundo. Si te preocupa que tengan una habitación llena de ASIC, tómatelo a mil millones (aunque bcrypt es algo resistente a los ASIC). El peor escenario con bcrypt es de 62 ¹⁰ / 2/826000000000 = 508050 segundos, que es solo de unos pocos días, pero hasta donde sé, es poco probable que existan ASICs de bcrypt (o sean tan rápidos si existe). Por supuesto, puedes mejorarlo fácilmente usando 12 o 15 caracteres aleatorios en lugar de 10.

_{* Suponiendo un costo de 12; el índice de referencia proporciona 105.7 kH / s con un costo de 5, por lo que 105700/2 ^ (12-5) ≈ 826 H / s.}

La respuesta corta es que no hay respuesta y el tiempo que se tarda en descifrar una contraseña es directamente proporcional a 1) longitud y 2) complejidad. Esto es directamente de la org SANS:

  

Las contraseñas seguras son largas, mientras más caracteres tenga, más fuerte será la contraseña. Nosotros   Recomiende un mínimo de 14 caracteres en su contraseña. Además, recomendamos encarecidamente la   Uso de frases de contraseña, contraseñas compuestas de múltiples palabras. Los ejemplos incluyen "Es hora de vacaciones" o "bloque-curioso-hojas soleadas". Las frases de contraseña son fáciles de recordar y de escribir, pero   cumplir con los requisitos de fuerza.

Si tiene una contraseña larga y compleja (p. ej., más de 16 caracteres, puede tardar años en descifrarla. Sin embargo, incluso una contraseña larga es susceptible de descifrar SI utiliza palabras de diccionario, o usa una palabra y reordena las letras con números o símbolos (por ejemplo, P @ $$ w0rd no es una buena contraseña, aunque incluye números, mayúsculas y símbolos).

Le recomendaría que utilice un generador de contraseñas aleatorias como éste .

Finalmente, las contraseñas en sí mismas no son suficientes para proteger el sitio o la infraestructura de uno. Considere realizar pruebas regulares de lápiz, escaneos, evaluaciones de vulnerabilidad y herramientas como fail2ban . Las inyecciones de SQL son relativamente fáciles de proteger al sanear las entradas, pero requieren tiempo para comprender primero las vulnerabilidades. Si simplemente asegura su contraseña, alguien todavía puede usar pass-the-hash o algún otro exploit para hackear su sitio. La seguridad es un enfoque en capas, por lo que centrarse en una falla de seguridad específica no es un enfoque inteligente.

Mientras que otras respuestas aquí abordan la pregunta formulada, tengo la impresión de que el OP no está abordando realmente el problema. Así que esto es realmente un comentario en lugar de una respuesta.

  

obteniendo el hash de la contraseña de administrador ... sin conocer la SALT

Esto implica que la sal se mantiene independientemente del hash, lo que sugiere que la sal no se genera aleatoriamente y es única para cada cuenta. Eso no es bueno.

  

simplemente inyectamos nuestro sitio web

Aunque supongo que ya está buscando evitar las vulnerabilidades de inyección de SQL, esto también implica que la aplicación tiene acceso directo a las tablas que contienen información de autenticación. Erk! Incluso si soluciona las vulnerabilidades conocidas de SQLI, el acceso de la aplicación a estos datos debe estar mediado a través de procedimientos SQL con separación de privilegios.

  

Obviamente tendremos que cambiar el algoritmo a algo impredecible

No.

En primer lugar, la sha256 es Sólo una parte del algoritmo se utiliza para validar las contraseñas. Hay muchas otras cosas a considerar aquí. Simplemente reemplazar sha256 con algo que es computacionalmente más costoso no solucionará un problema en otra parte en la validación de su contraseña.

Le animo a considerar la imagen más grande.

En su respuesta, SomeGuy sugiere usar una contraseña grande y aleatoria. Si bien esto abordará la fuerza bruta del hash, todavía no ayuda si ha cometido un error en otra parte. También significa que las personas tienen más probabilidades de hacer un registro de la contraseña en algún lugar. Es de esperar que lo hagan en un administrador de contraseñas adecuado en lugar de hacerlo en una nota de post-it, pero incluso los primeros no son necesariamente 100% confiables. Has aumentado la superficie de ataque.

  

cambiaríamos la contraseña cada mes.

Tanto NIST como GCHQ han estado cuestionando esta sabiduría recibida relativamente recientemente. Ciertamente, no habría proporcionado ninguna protección contra el ataque que describe. Según la discusión sobre la complejidad de la contraseña, cuanto más frecuentemente cambie una contraseña, más probable será que se comunique y se escriba.

Dado que puedes cambiar el código de la aplicación y su código abierto, te recomendaría:

• observa detenidamente el código que rodea la llamada a sha256 (); asegúrate de utilizar una función de extensión de contraseña

• utiliza sales únicas y generadas aleatoriamente para cada cuenta

• implementas la autenticación de dos factores (con un servicio para habilitar esto según el privilegio o la preferencia del usuario)

• considera el aislamiento de privilegios de los datos de hash de contraseña