¿Por qué es tan importante el hashing de contraseñas?

La experiencia le ha enseñado a la comunidad que efectivamente es imposible mantener alejados a los intrusos. Se trata de cuándo, y no si, alguien obtendrá acceso a su base de datos de contraseñas.

No importa si usted es un blog aleatorio o un departamento gubernamental de miles de millones de dólares, debe asumir que alguien algún día obtendrá acceso. Y muy a menudo, tendrán suficiente acceso para leer la base de datos, pero no suficiente para, por ejemplo, insertar un hombre en el medio que capture las contraseñas de texto simple como se usan para autenticar a alguien.

Por ejemplo, es posible que no pirateen su servidor primario, sino que solo piratean un servidor que contiene copias de respaldo de su base de datos.

Además, la mayoría de las organizaciones tienen muchos empleados. Un empleado no necesita piratear su red para ver la base de datos, es posible que ya tenga acceso sin restricciones (especialmente si son ingenieros o administradores de sistemas). Hay muchas razones por las que es una mala idea que sus empleados conozcan las contraseñas de los clientes.

Incluso si su sitio web no tiene ningún valor y no importaría que alguien lo pirateara. El nombre de usuario y la contraseña utilizados para iniciar sesión en su sitio web a menudo son exactamente los mismos que los utilizados para iniciar sesión en otros servicios mucho más importantes.

Por ejemplo, alguien podría escribir un bot que intente iniciar sesión en la tienda iTunes de Apple con cada nombre de usuario / contraseña en su base de datos, y si tiene éxito, comienza a comprar cosas a través de la tienda. Este ataque podría tener éxito hasta en el 10% de los usuarios de su base de datos, y muchos de ellos nunca notarán que se les ha facturado $ 4.99. Esto no es un ataque teórico, ocurre todo el día todos los días y los intentos de detenerlo no siempre tienen éxito.

EDITAR: Y en los comentarios, @emory hizo otro punto que olvidé: alguien podría presentar una citación o utilizar algún otro proceso legal para obtener acceso a la base de datos, lo que les permite ver las contraseñas de texto simple a menos que tenga un buen hash. Tenga en cuenta que no es solo la policía quien puede hacer esto, cualquier abogado privado con un caso legal sólido en su contra puede obtener acceso a su base de datos.

  

Si es así, ¿por qué se pone tanto énfasis en la creación de bases de datos de contraseñas seguras, en lugar de sistemas seguros que impidan el acceso no autorizado a información importante del usuario?

Porque esto es realmente difícil de hacer. No hay forma de garantizar que su sistema sea 100% a prueba de hackeo. De hecho, si realiza una reclamación de este tipo en Reddit, su sitio probablemente se verá comprometido dentro de una hora.

Hay un término comúnmente usado en seguridad llamado Defensa en profundidad . Una base de datos de contraseña comprometida no solo afecta a la aplicación su . La mayoría de las personas usarán la misma combinación de nombre de usuario y contraseña para varios sitios web. Esto hace que sea trivial para un atacante que ha comprometido una única base de datos de contraseñas para obtener acceso a los múltiples servicios que utiliza un usuario. Esta es la razón por la que a menudo ve recomendaciones de sitios web comprometidos para que el usuario cambie sus contraseñas en todas sus cuentas.

Incluso si solo considera que su aplicación es importante, hay muchas cosas que un atacante puede hacer si tiene las contraseñas de texto simple de sus usuarios. Es difícil para un atacante modificar directamente los valores de la base de datos sin ser detectado. Sin embargo, con una contraseña de texto simple comprometida, simplemente puede iniciar sesión en una cuenta de usuario y realizar los cambios. Esto es muy difícil de detectar.

Además de las razones ya expuestas hay otra:

¡Se supone que una contraseña es privada!

Tenerlo en texto no cifrado significa que usted o cualquiera de sus colegas que administran o están desarrollando tienen acceso a todas las contraseñas y puede hacerse pasar por cualquier usuario. Ahora probablemente estás pensando: nunca haríamos eso, ¡está mal!

Piense en un sistema bancario: todos los administradores de la base de datos tendrían acceso a las contraseñas. Esto significa que simplemente podrían iniciar sesión en su cuenta desde cualquier lugar y retirar dinero. ¿Pondría su dinero en un banco así sabiendo esto? Peor aún ... muchas personas usan la misma contraseña en múltiples ubicaciones. Ahora podrían iniciar sesión en la cuenta bancaria y, con suficiente información en muchos otros lugares.

Recuerde que muchos ataques se encuentran dentro de los trabajos: personas con información privilegiada. Los atacantes no vienen todos del exterior.

Hay muchas formas en que una base de datos con contraseñas puede terminar en manos no deseadas. Si las contraseñas no están mal ocultadas cuando esto sucede, el propietario del sitio web es responsable y tiene muchos problemas, porque a menudo los usuarios también reutilizan sus contraseñas en otros sitios. Me gustaría darles algunos ejemplos de cómo una base de datos puede filtrarse:

• La inyección SQL es un ataque fácil contra su sitio web. Hice una pequeña demostración para mostrar lo fácil que es. Simplemente haga clic en la siguiente flecha para obtener información maliciosa. La inyección de SQL puede tratarse escribiendo código limpio, pero a menudo usa bibliotecas de terceros o no ha desarrollado solo el código fuente, en cuyo caso el código inseguro podría haberse deslizado.
• Si está alojando su sitio web con un proveedor externo, al menos el personal de la empresa de alojamiento tiene acceso gratuito a la base de datos. A menudo, otras personas también tienen acceso: quizás necesite un desarrollador para solucionar un determinado problema o para ampliar su página.
• Las copias de seguridad también son un problema. Si las copias de seguridad no se almacenan con el mismo cuidado con que el servidor en ejecución está protegido, o si se desechan sin borrarlas correctamente, las contraseñas tienen fugas.
• Si se descarta un servidor, debe limpiarse antes de desecharlo. En el caso de hosting externo, esto no está bajo su control. La limpieza puede ser bastante difícil en los sistemas RAID.
• Cada vez más datos se almacenan en servicios en la nube. Una cosa útil, estas nubes, pero también está nublada donde termina su base de datos, y la limpieza adecuada en una nube puede ser incluso imposible.

Un principio en seguridad es que no existe un único mecanismo a prueba de balas, sino que debe confiar en múltiples mecanismos para proteger su sistema / datos. En otras palabras, la defensa en profundidad. Entonces, en lugar de decidir entre (a) proteger la base de datos de contraseñas o (b) proteger el sistema donde reside o se usa, debe hacer ambas cosas.

Esta publicación de blog trata esta pregunta. El resumen es que necesita el hashing de contraseñas como segunda línea de defensa, cuando los atacantes logran un descanso parcial de solo lectura . Esto es una consecuencia frecuente de los ataques de inyección de SQL, pero también ocurre cuando se roba una cinta de respaldo o cuando se descarta un disco antiguo. En particular, cuando falla un disco, la falla puede ser la de la placa electrónica, pero el medio magnético aún contiene todos los datos. Si el disco no se inicia, el administrador del sistema no podrá (fácilmente) borrar el contenido. Pero si el disco simplemente se tira en un contenedor de basura, un atacante laborioso podría recuperarlo, reemplazar la placa electrónica y leer todos los datos.

Si bien es mejor no permitir que los atacantes miren las entrañas de su servidor en primer lugar, tales brechas ocurren en la práctica, y es mejor que tenga algo de protección contra ellas. Vea también esta respuesta detallada sobre cómo se debe realizar el hashing de contraseñas ; la idea subyacente es que para verificar la contraseña de un usuario, el servidor DEBE contener algunos datos dependientes de la contraseña, y un volcado completo del contenido del servidor es suficiente para "probar las contraseñas en casa". Por lo tanto, el hashing de contraseñas es lo mejor que se puede hacer (teóricamente), a menos que aparezca en la imagen un hardware a prueba de manipulaciones con fines especiales.

msn mencionó la necesidad de privacidad interna; Yo agregaría otra razón basada en esto: no puede confiar completamente en todos los que tienen acceso físico a su base de datos. Hashing protege la base de datos contra el compromiso interno así como contra el compromiso externo.

Uno de los puntos que creo que no se menciona en las respuestas aquí. Creo que la razón principal para implementar el hash de contraseñas no es agregar una capa adicional para ataques desde el exterior, sino simplemente hacerlos ilegibles para aquellos que están dentro de la red.
Muchos ataques vienen de tu red de confianza. Un desarrollador o administrador del sistema que no esté enojado no debería poder leer las contraseñas no rotas del usuario, incluso si tiene acceso a la base de datos.