¿Por qué solo se ingresan las contraseñas?

Algunas cosas primero:

• Olvídate de MD5 inmediatamente. Es viejo y débil.
• Idealmente, olvídate de SHA1 también. Hay SHA2 y SHA3.
• Estos algoritmos hash en su forma pura son útiles para muchas cosas, pero no para contraseñas. Úsalos en combinación con por ejemplo. PBKDF2, o use bcrypt (y no se olvide de la salazón).

  

Por lo tanto, si no me equivoco, las contraseñas están hashed, de modo que en una rara   situación de su base de datos se compromete un pirata informático no puede ver todo   las contraseñas en su base de datos como las contraseñas están ocultas.

Correcto. Si bien esto no ayudará a hacer que su servidor sea más seguro (después de todo, ya está comprometido en tal situación), previene, por ejemplo. El atacante usa las contraseñas en otros sitios. Lamentablemente la mayoría de la gente usa una contraseña para varias cosas.

  

¿Es tan fácil hackear una base de datos? Quiero decir, en lugar de encontrar nuevas formas de   hash, ¿por qué no pueden hacer que su base de datos sea más segura o "a prueba de hackeo"?

Podrías (y deberías). Pero:

• Incluso con todos sus esfuerzos, siempre hay alguna posibilidad de que el atacante tenga acceso. Errores en software y dispositivos que no conoce y / o no puede solucionar, y muchas más cosas.
• A menudo no puedes dar lo mejor de ti porque los gerentes no creen que la seguridad sea importante, no tienen presupuesto para ello, etc.

  

Si un pirata informático logra piratear una base de datos, ¿por qué querría   ¿Sabes las contraseñas hash? Quiero decir que puede cambiar otras columnas de datos.   Por ejemplo, él podría buscar su nombre de usuario y aumentar su banco   equilibrar. Entonces, ¿no deberían estar todos los campos marcados?

Si todos los campos están en hash, la base de datos también es inútil para usted; así que no puedes hacer eso. Recuerda, un buen hash no puede ser revertido.

Como se dijo anteriormente, tan pronto como su base de datos / servidor se vea comprometida, el daño para usted ya ocurrió. Las contraseñas con hash evitan que el atacante también tenga acceso a otras cuentas de sus usuarios (y luego algunos usuarios lo demandarán, por lo que el hashing también lo ayuda).

MD5 y SHA-1 ya no son seguros no porque "la mayoría de los hash de contraseña están ahora en Internet". El uso de sales para hacer hashes de contraseñas globalmente únicas de hecho hace esto imposible. Son obsoletos porque son demasiado rápidos y demasiadas contraseñas candidatas pueden probarse contra un hash robado demasiado rápido para su comodidad.

El inconveniente del hash es que no es reversible. Por esta razón, no se puede utilizar para todos los datos confidenciales. El saldo de su banco, por ejemplo, no es muy bueno ni para usted ni para el banco si es hash, y ninguno de los dos sabe lo que es.

1. Si bien es probable que no sea tan fácil con los sistemas bien configurados en mente, múltiples vulnerabilidades en el sistema operativo o en el nivel de la aplicación (como la inyección SQL, posiblemente incluso la inclusión de un archivo) pueden llevar a un compromiso de la base de datos, como suele ser el caso. caso en realidad. Proteger las contraseñas con hash es un ejemplo de defensa en profundidad. Incluso si falla una línea de defensa, debería ser relativamente difícil obtener contraseñas reales.

2. Las contraseñas son un buen objetivo por varias razones. Por un lado, permiten la suplantación de usuarios, en lugar de leer, cambiar o eliminar datos con la cuenta del atacante (posiblemente comprometida). Además, los usuarios tienden a reutilizar las contraseñas, por lo que una contraseña robada de una aplicación tiene muy buenas posibilidades de ser válida para otras cuentas del mismo usuario. En cuanto a por qué otros datos no están hash - el hash es una forma, no puede recuperar el valor original de un hash (al menos no trivialmente, en realidad y con muchas funciones de hash, tiene una buena posibilidad, pero no lo tomemos en cuenta). momento). Ser de una manera significa que las funciones hash son buenas para verificar si una contraseña ingresada es la misma que la almacenada, pero no es buena para almacenar los datos que realmente necesita en su forma no encriptada. Y esa es la solución que puede haber estado buscando, el cifrado, a diferencia del hash. De hecho, es una buena idea cifrar datos confidenciales en una base de datos, pero eso también tiene sus propios problemas, por ejemplo, la administración de claves.

  

¿Es tan fácil hackear una base de datos? Quiero decir que en lugar de encontrar nuevas formas de hash, ¿por qué no pueden hacer que su base de datos sea más segura o "a prueba de piratería"?

A menudo, una base de datos puede ser hackeada a través de una aplicación web usando inyección SQL. Absolutamente deberíamos arreglar la inyección de SQL como una prioridad. Sin embargo, en una aplicación grande, solo hace falta un desarrollador para cometer un error en una línea para presentar dicha vulnerabilidad. Así que, mientras intentamos detenerlo, también planeamos otras defensas en caso de que se produzca una vulnerabilidad.

  

Si un pirata informático logra piratear una base de datos, ¿por qué querría saber las contraseñas con hash? Quiero decir que puede cambiar otras columnas de datos. Por ejemplo, podría buscar su nombre de usuario y aumentar su saldo bancario. Entonces, ¿no deberían estar todos los campos marcados?

En muchos casos, la inyección de SQL permite a los atacantes leer datos, pero no cambiarlos. Si las contraseñas no estuvieran ocultas, podrían iniciar sesión como otros usuarios y hacer cambios. El hash de contraseña ayuda a prevenir esto. Además, los usuarios a menudo reutilizan las contraseñas en muchos sitios web, aunque es una mala práctica hacerlo.

  

¿Por qué solo las contraseñas están ocultas?

En una aplicación bien diseñada, todos los tokens de autenticación están hash. Esto incluye identificadores de sesión y tokens de restablecimiento de contraseñas, así como contraseñas. Otros datos (por ejemplo, su saldo bancario) no se incluyen, porque la aplicación necesita los datos en formato de texto simple para funcionar.

  

¿Es tan fácil hackear una base de datos? Quiero decir que en lugar de encontrar nuevas formas de hash, ¿por qué no pueden hacer que su base de datos sea más segura o "a prueba de piratería"?

¿Por qué necesitamos hospitales? ¿Por qué no podemos hacer que la carretera sea más segura en lugar de tener hospitales?

Un sistema totalmente "a prueba de hackeo" es una ilusión. Hay millones de formas de hackear un sistema. Necesitas defenderte de todos ellos. Un atacante solo necesita encontrar uno.

Esto requiere que sepas sobre todas las formas. Y que no cometió un error (solo mire la configuración predeterminada para Mongo-DB: acceso de administrador no autenticado y luego combínelo con muchos administradores que configuran la base de datos para que sea accesible desde Internet por conveniencia o debido a manuales deficientes) . Y tener los recursos. Y estar al día cuando se descubren nuevas fallas. Y lo mismo para todos los proveedores de software, servicios y hardware que está utilizando. Y que ninguno de ellos tenía malas intenciones. Y que hay actualizaciones para las nuevas fallas descubiertas (se sabe que los teléfonos inteligentes Android no están muy bien atendidos con actualizaciones de seguridad). Y que no hay fallas desconocidas que el atacante sepa.

¿Estás seguro de que te defendiste contra todos ellos? ¿En quién confías? ¿Qué tal el administrador que se dejó ir y todavía tiene acceso a una copia de la copia de seguridad de la base de datos? ¿Borraste el almacenamiento correctamente antes de revenderlo o tirarlo? ¿Quién tiene acceso a las copias de seguridad?

  

Si un pirata informático logra piratear una base de datos, ¿por qué querría saber las contraseñas con hash? Quiero decir que puede cambiar otras columnas de datos. Por ejemplo, podría buscar su nombre de usuario y aumentar su saldo bancario.

1. Es posible que solo tenga acceso de solo lectura a la base de datos. Por ejemplo, cuando tenía una copia de seguridad en sus manos cuando estaba almacenada en un servidor web no seguro o su vector de ataque solo permite la lectura.
2. Es posible que solo tenga acceso a una parte del sistema donde se almacenan las contraseñas, pero no al sistema donde se almacenan los saldos.
3. Muchas bases de datos profesionales tienen un seguimiento de auditoría. Digamos que cambias tu saldo en la base de datos. Eso podría apagar sus alarmas porque el sistema no ve una reducción correspondiente en otro saldo y no hay autorización para esta transacción, etc. y es fácilmente visible. Si, en cambio, inicia sesión como otro usuario y presiona transferir $ 1000 a otra cuenta, se verá más legítimo.
4. Puede usar los datos de inicio de sesión para hacerse pasar por otro usuario y él será el culpable (muchos proveedores más grandes ya tienen heurísticas para detectar tales cosas automáticamente o cuando se afirma)
5. Tiempo de ataque (-vector) y tiempo de acceso: solo necesita atacar una vez, pero puede usar las credenciales más tarde (muchos usuarios no cambian las contraseñas por años o nunca)
6. Muchos usuarios menos técnicos reutilizan las contraseñas en otros sitios
7. Tienes más tiempo hasta que el atacante pueda hacerse pasar por los usuarios después de que atacó

Esas fueron las primeras razones por las que pensé y hay muchas más.

  

¿no deberían estar marcados todos los campos?

Es una pregunta interesante, por lo que consideremos las ramificaciones si (por ejemplo) el nombre de usuario también estaba oculto. En este momento estoy "Nick Gammon" en Stack Exchange. Si mi nombre de usuario estuviera oculto, en lugar de una publicación de Nick Gammon , veríamos una publicación de 80a8694f4a2950e075d142e97ddb809b415bf85f084dafd9fb78fed9551905f3 en respuesta a una pregunta de 76d6d4c28518362c96d55f52cfdf27908baadf6f37973eb42cfd515b4c96294a ¹ . Puedes ver que esto sería increíblemente tedioso. (Recuerda, no puedes revertir un hash para recuperar el original).

Bien, podría decir "bueno, mantenga un nombre de inicio de sesión (que tiene hash) y también un nombre para mostrar". Pero luego, si viste que mi nombre de usuario era "Nick Gammon", puedes adivinar que también fue mi nombre de inicio de sesión (o alguna variante simple), por lo que el hashing no ha logrado nada.

Entonces puede que te preocupe que si alguien se encuentra en la base de datos también puede ver las direcciones de correo electrónico, por lo que también las hash. Pero no puede enviar un correo electrónico a una dirección de correo electrónico con hash (por ejemplo, para notificarle las nuevas publicaciones o una disminución de su saldo bancario), por lo que no funcionaría. De acuerdo, guarde la dirección de correo electrónico como texto simple, pero ahora probablemente pueda deducir el nombre de usuario a partir de la dirección de correo electrónico.

  

¿Por qué no pueden hacer que su base de datos sea más segura o "a prueba de piratería"?

Ningún diseño atenderá el soborno de un empleado de confianza para hacer una copia de la base de datos. Si los datos están allí, entonces las personas con suficiente autorización tendrán que poder acceder a ellos, o bien puede que no existan.

Creo que algunas de las recientes fugas de seguridad han ocurrido en organizaciones que pensaban que su base de datos estaba tan "a prueba de pirateo" que no necesitaban molestar a sus contraseñas. Ups.

1. Marcas extra para averiguar quién es. :)

"Defensa en profundidad" es el principio de que múltiples capas redundantes de seguridad son las mejores, y más específicamente que ningún componente de un sistema seguro debe confiar en ningún otro componente de un sistema seguro. En este caso, la capa de hash no debe asumir que la base de datos es segura.

Usted hizo otras preguntas técnicas sobre el hash que se cubren en detalle en las otras respuestas, pero el principio más fundamental de la defensa en profundidad: "¿por qué cerrar la puerta dos veces?" - Es algo que parece que te estás perdiendo.

Estoy seguro de que escuchó suficientes casos de violaciones de seguridad de alto perfil en 2016 como para saber que, en conjunto, estamos haciendo demasiado poco , no demasiado.

No te limites solo analizando el ataque desde afuera. Tienes que ver la imagen más grande ... piensa en medidas de seguridad como capas de una cebolla. Apila tantos como puedas con la esperanza de cerrar cualquier ángulo de ataque. Los hashes de contraseña son una de esas capas.

  

¿Es tan fácil hackear una base de datos? Quiero decir que en lugar de encontrar nuevas formas de hash, ¿por qué no pueden hacer que su base de datos sea más segura o "a prueba de piratería"?

No importa lo difícil que sea hackear la base de datos. Tenga en cuenta que el hashing de la contraseña debe proteger la contraseña incluso desde el sistema o el administrador de la base de datos.

Tenga en cuenta que incluso si tratara de hacerlo, no es necesariamente fácil proteger la base de datos de contraseñas. ¿Cómo lo protegerías? ¿Con otra contraseña? ¿Dónde almacenaría esa contraseña maestra? ¿Cómo protegería la contraseña maestra de que alguien pueda leer todo el sistema?

  

Si un pirata informático logra piratear una base de datos, ¿por qué querría saber las contraseñas con hash?

Bueno, para intentar atacarlos.

Observe cómo se usan las contraseñas: el usuario legítimo entrega un nombre de usuario y una contraseña de texto simple a la pantalla de inicio de sesión, el texto claro se revisa y se compara con el hash de la contraseña.

Todos los atacantes pueden hacer exactamente lo mismo, excepto que hacerlo en la pantalla / indicador de inicio de sesión real es ineficaz: lleva tiempo y se detecta fácilmente; muchos sistemas bloquearán una cuenta después de algunos intentos fallidos.

Entonces, cuando el atacante obtiene la lista de hashes de contraseñas, puede hacer el mismo hashing en su propio programa: cegadoramente rápido, y especialmente con ataques "dicitoneales" o "arco iris", que intercambian RAM / almacenamiento contra el tiempo. p>

  

Entonces, ¿no deberían estar todos los campos con hash?

No puede hash todos los campos porque su aplicación necesita conocer el valor de los otros campos, simplemente. Es difícil recuperar el valor de una versión con hash, incluso para un usuario legítimo.

Pero, de hecho, hay bases de datos que hacen algo así: cifran (no hash) los datos reales también. Desea evaluar si vale la pena desde el punto de vista del rendimiento, y luego tiene que asegurarse de que el cifrado realmente proporcione seguridad real. Es decir, debe asegurarse de que su clave permanezca protegida mientras el DB necesita tener acceso a ella, y así sucesivamente.

El cifrado no es apropiado para las contraseñas porque en realidad no queremos que se puedan descifrar (las mismas ideas que al comienzo = > trabajos internos, y la dificultad de hacer que la clave de cifrado sea más segura que las contraseñas reales querías asegurarte en primer lugar).

Porque no es solo el acceso remoto, no autorizado, el que debe protegerse. A veces, todo centros de datos desaparecidos. Una vez que los malos tienen los discos que contienen los archivos de la base de datos, se pueden leer a su gusto. Luego, todos se pueden tomar los datos sin cifrar: números de tarjeta de crédito, nombres, dirección, correo electrónico, números de teléfono, historial de compras. Cualquier cosa que facilite el robo de dinero o el robo de identidad.

La buena práctica actual es cifrar todo lo que sea personalmente identificable o financieramente sensible. Varios DBMS admiten el cifrado en reposo (es decir, en el disco) y en vuelo (mientras se transfieren desde el servidor DB a la aplicación).

  

¿Es fácil hackear una base de datos?

No, no es tan fácil. Una configuración mal configurada es lo que hace que las bases de datos sean vulnerables y las exponga a los atacantes. Uno debe aplicar cualquier parche disponible para la versión de la base de datos que se usa, y si es posible, ejecutar la última versión.

  

Quiero decir, en lugar de encontrar nuevas formas de hash, ¿por qué no pueden hacer su   ¿Una base de datos más segura o a prueba de hackeo?

La gente sigue intentando encontrar nuevos algoritmos para el hash porque las colisiones se detectan en el algoritmo de hashing actual. No es que no podamos encontrar formas de proteger las bases de datos.

  

¿Por qué Hashing?

1. Hashing garantiza al usuario final que sus tokens y contraseñas secretas se almacenan en un formato irreversible.

2. Hashing garantiza que la aplicación que está accediendo a la base de datos no tenga acceso a datos secretos en forma de texto simple.

3. El hash también evita que los datos secretos se vean expuestos incluso a los administradores de la base de datos y del sistema.

  

Si un pirata informático logra piratear una base de datos, ¿por qué querría   ¿Sabes las contraseñas hash? Quiero decir que puede cambiar otras columnas de datos.   Por ejemplo, podría buscar su nombre de usuario y aumentar su cuenta bancaria.   equilibrar. Entonces, ¿no deberían estar todos los campos marcados?

Desfigurar la base de datos oculta a través de las aplicaciones que tienen acceso a ella es diferente de irrumpir en el servidor de bases de datos. Si un atacante irrumpe en el servidor que aloja la base de datos, entonces, por supuesto, puede hacer todo lo posible para cualquier nivel de privilegio al que tenga acceso.

Pero, ¿no crees que obtener contraseñas en texto claro es peligroso en una forma que es irreversible, porque la única posibilidad que queda para el atacante es lanzar fuerza bruta pasiva para encontrar las contraseñas, lo que da suficiente tiempo para Las víctimas cambiarán sus contraseñas comprometidas.

Puede ver muy bien la diferencia en la fuerza de los desafíos criptográficos que enfrentará el atacante para alcanzar este hash.

  

¿Por qué solo las contraseñas están ocultas?

La autenticación de contraseñas se utiliza para probar la autenticidad de una entidad, por lo que la posesión de una contraseña es suficiente para que un atacante pueda hacerse pasar por otro usuario. Por lo tanto, existe un riesgo de seguridad en el robo de identidad si no se trata de un hash.

Existen algunas soluciones que cifran todos los datos confidenciales en su base de datos, por ejemplo Azure . Pero la seguridad no es gratuita y cuesta dinero, tiempo y puede obtener un peor rendimiento debido al cifrado. Ningún almuerzo es gratis.

Imagine un negocio de compra en línea de una sola persona con bajo presupuesto. Este negocio no puede permitirse alguna solución costosa. Su elección es elegir el más barato o nada. La seguridad no es una opción, porque no tienes dinero para eso. La seguridad comienza a ser importante a medida que la empresa crece.