¿Por qué se deben cifrar las contraseñas si se almacenan en una base de datos segura?

Tengo un servicio web. En este momento, tengo contraseñas almacenadas en texto sin formato en una tabla MySQL en mi servidor. Sé que esta no es la mejor práctica, y es por eso que estoy trabajando en ello.

¿Por qué se deben cifrar las contraseñas si se almacenan en una base de datos segura? Me doy cuenta de que si alguien piratea mi base de datos, obtendrá la contraseña de todos. Pero tengo otros problemas si alguien ingresa a mi base de datos, por ejemplo, eliminando datos.

El escenario en el que puedo pensar es que estás pirateado. Restaura una base de datos de hace un par de horas y todo está bien. Sin embargo, si sus contraseñas son de texto sin formato ... El ladrón tiene todas las contraseñas y debe restablecerlas todas. Problemas para sus usuarios.

Si las contraseñas estuvieran encriptadas, simplemente podría restaurar a la base de datos anterior. ¿Es este el pensamiento correcto?

En primer lugar, debería ser más libre con derechos de acceso de solo lectura que lectura-escritura. Es posible que un hacker tenga acceso a sus datos pero no pueda editarlos.

Pero, mucho más importante, esto no se trata de ti. El hecho de que pueda estar jodido si alguien tiene acceso completo a su base de datos es irrelevante. Mucho más importante son los datos de su usuario.

Si recupera su base de datos, el hacker aún tiene acceso a la cuenta de su usuario.

¿Y quién sabe qué más? ¿Qué pasa si usan la misma contraseña en Google? O PayPal? ¿Qué pasa si eso le da acceso a un pirata informático al apellido de soltera de su madre, o los últimos 4 dígitos de su tarjeta de crédito?

¿Qué pasa si eso los lleva a otras cuentas? No deje pasar a un hacker para que pase por un sistema de soporte al usuario y obtenga más información .

Solo ... simplemente no. Esa es la información privada de su usuario y no necesita poder verla. También es tu reputación. Cifrarlo.

EDITAR: Un comentario adicional, para evitar que cualquier futuro lector lea cada respuesta y comentario ...

Si va a cifrar (en el sentido más estricto), entonces necesita usar un par de claves pública / privada , lo cual está bien pero hace la vida un poco más difícil tanto para usted como para su usuario.

Una solución más simple e igual de efectiva es saltear aleatoriamente y hash la contraseña. Hashing solo no es suficiente; Si su usuario usa una contraseña común, aparecerá en las tablas de hash inverso, que están fácilmente disponibles con una simple búsqueda en Internet.

Si te piratean, puedes restaurar el sitio desde copias de seguridad y arreglarlo. ¡Pero el hacker todavía tiene contraseñas para las cuentas de todos! Hay ejemplos documentados de que esto está sucediendo en el mundo real (Sony, Linked-in), donde si las tablas de contraseñas hubieran sido correctamente procesadas y saladas, asegurar y restaurar el servicio rápidamente habría sido mucho más fácil.

Probablemente sea una buena idea asumir que será hackeado, y diseñar su estrategia de copia de seguridad y cifrar cualquier información confidencial teniendo en cuenta esta suposición. Y no es solo contra los hackers contra los que debes protegerte. Los empleados descontentos, deshonestos o simplemente despistados podrían regalar contraseñas de texto sin formato.

Sin hashing, tendrá que deshabilitar el acceso para todos hasta que cambien su contraseña (lo que, aunque sea posible, será un gran dolor de cabeza para todos). Si las contraseñas se hubieran cifrado y salado, podría restaurar el servicio web y sería mucho más difícil para un atacante obtener acceso a las cuentas de las personas.

Una contraseña correctamente saneada y con hash es básicamente unidireccional. No puede adivinar fácilmente la contraseña de la contraseña hash. Incluso usted, como el proveedor de servicios no podrá adivinarlo, solo puede restablecerlo.

Además, como dijo Elin, no intentes rodar tu propio hash (o cifrado). Utiliza una biblioteca estándar.

Pero tengo otros problemas si alguien ingresa a mi base de datos, es decir, borrando datos.

No se trata de los problemas que tiene, se trata de los problemas que podría causar a todos sus otros usuarios. Se trata de eliminar la tentación (o peor aún, la posible responsabilidad) de las personas que trabajan en el sitio para abusar de los datos almacenados allí.

Verán, aunque las personas deberían usar contraseñas diferentes en sistemas diferentes, la realidad es que no lo hacen .

... y como es muy fácil descifrar contraseñas, no tiene excusas para no seguir las mejores prácticas de la industria.

Los ataques notables, como la eliminación de datos, generalmente son cosa de aficionados y son la menor de sus preocupaciones. Una de las primeras cosas que hará un atacante experimentado es intentar obtener acceso legítimo, por lo que incluso si reparas la vulnerabilidad original que utilizó, aún podrá entrar. Hará todo lo posible para evitar llamar la atención hasta que logra lo que desea. Al dejar sin contraseña las contraseñas, usted potencialmente hizo su trabajo mucho más fácil. También hizo que sea más difícil detectar y aislar su futuro comportamiento malicioso.

Además, no todos los compromisos le dan acceso completo al shell. ¿Qué sucede si la vulnerabilidad utilizada por un atacante es solo una inyección SQL de solo lectura en la userstabla? Dejar las contraseñas sin usar solo le dio acceso casi completo.

Eso se suma a las razones dadas por otras respuestas sobre su responsabilidad de proteger los datos de sus usuarios. Mi punto es que no solo los usuarios tienen algo que perder.

Tengo que publicar una respuesta aquí sobre una falacia en la pregunta misma. Usted pregunta si las contraseñas deben estar encriptadas. Nadie encripta las contraseñas; nadie, con la excepción de servicios y programas como Firefox Sync y Roboform, cuyo único propósito es encriptar contraseñas.

Echemos un vistazo a las definiciones:

En criptografía, el cifrado es el proceso de codificar mensajes (o información) de tal manera que solo las partes autorizadas puedan leerlo.

Y hash:

Una función hash es cualquier algoritmo que asigna datos de longitud arbitraria a datos de una longitud fija.

En otras palabras, el cifrado es una conversión bidireccional y el hash es una conversión unidireccional , por lo que, a menos que esté descifrando para verlos más adelante, esto no es cifrado.

Además, ¡no solo hachís, sal ! Lea esta página completa antes de descifrar sus contraseñas.

En cuanto a los algoritmos de hashing, que el OP ahora está investigando, sugeriría cualquiera de las variantes SHA-2 de gama alta, como SHA-384 o SHA-512.

Y asegúrese de usar rondas de hash . No hash una vez, hash varias veces.

Considere leer esta página para asegurar más su proceso de inicio de sesión.

En segundo lugar, su base de datos nunca puede ser lo suficientemente segura. Siempre habrá agujeros de seguridad y riesgos en constante evolución. Debe seguir la Ley de Murphy y siempre prepararse para la peor eventualidad.

Los otros puntos que pdr hace son exactamente qué más diría: personas que usan la misma contraseña para cada sitio web, hackers que usan ingeniería social para obtener más información, etc.

Hay un principio importante en juego aquí. Solo hay una persona que tiene negocios que conoce la contraseña de un usuario. Ese es el usuario. No su esposa / esposo, su médico o incluso su sacerdote.

Definitivamente no incluye al programador, administrador de la base de datos o técnico del sistema responsable del servicio que están utilizando. Eso crea un desafío, ya que el programador tiene la responsabilidad de recibir pruebas de que el usuario realmente conoce la contraseña, lo cual es un problema no trivial para resolver de manera pura.

La solución pura es tener un mecanismo donde el usuario sea desafiado con algunos datos nuevos e impredecibles, y luego tenga que devolver una respuesta que se base en estos datos y su contraseña. Una implementación de esto sería pedirle al usuario que firme digitalmente algunos datos recién generados con su firma digital, y podríamos demostrar matemáticamente que usaron el mismo par de claves criptográficas que usaron originalmente para crear la cuenta.

En la práctica, las soluciones puras requieren una infraestructura y procesamiento sustancial del lado del cliente, y para muchos sitios web, esto a menudo no es apropiado para los datos que se protegen.

Una solución más común sería:

En el punto donde se recibe una contraseña por primera vez en la aplicación, la contraseña se pasa a la función hash, junto con el valor aleatorio 'salt' de su aplicación en la función hash.

La cadena original se sobrescribe en la memoria y, a partir de este momento, el hash salado se almacena en la base de datos o se compara con el registro de la base de datos.

Los aspectos clave que proporcionan seguridad aquí son:

1. El conocimiento del hash no proporciona directamente la autenticación.
2. El cálculo inverso de la contraseña del hash no es práctico.
3. El uso de tablas de arco iris (largas listas de contraseñas y sus hashes calculados) se vuelve más difícil porque el hash resultante depende tanto del nombre de usuario como de la contraseña.

Debe "encriptar" (en realidad, "hash", para una noción adecuada de hashing) las contraseñas como una segunda capa de defensa : esto está destinado a evitar que un atacante, que tuvo una visión de solo lectura de la base de datos, escale eso en el acceso de lectura y escritura y, precisamente, comenzar a alterar los datos. Las infracciones parciales de solo lectura ocurren en el mundo real, por ejemplo, a través de un ataque de inyección SQL desde una cuenta con acceso de solo lectura, o al recuperar un disco duro descartado o una vieja cinta de respaldo de un contenedor de basura. He escrito extensamente sobre este tema allí .

En cuanto a las formas adecuadas de hash contraseñas, vea esta respuesta . Esto implica sales, iteraciones y, sobre todo, no inventar sus propios algoritmos (la criptografía casera es una receta segura para el desastre).

No repetiré lo que han dicho otras personas, pero suponiendo que tenga PHP 5.3.8 o superior, debería usar el nativo de PHP bcryptpara almacenar sus contraseñas. Esto está integrado en PHP. Si tiene PHP 5.5, puede usar la mejor constante de contraseña disponible. También puede usar una biblioteca para hacer que 5.3.8 o mejor se comporte como 5.5.

Pregunta de desbordamiento de pila ¿ Cómo se usa bcrypt para contraseñas hash en PHP? lo explica, y las otras respuestas allí explican más. Por favor, no pierdas el tiempo tratando de hacerlo tú mismo

Estoy de acuerdo con la respuesta de pdr, por las razones indicadas en esa respuesta.

Agregaría lo siguiente: debe hacerlo porque es fácil de hacer y generalmente aceptado como la mejor práctica para cualquier aplicación. Más específicamente, las contraseñas siempre deben ser saladas y codificadas antes de escribir en cualquier almacenamiento persistente. Aquí hay una buena referencia sobre la importancia de salar y elegir un buen hash criptográfico (que también proporciona código fuente gratuito en varios idiomas populares): https://crackstation.net/hashing-security.htm

La pequeña cantidad de tiempo de desarrollo adicional bien vale la protección que brinda a sus usuarios y a su reputación como desarrollador.

El escenario en el que puedo pensar es que estás pirateado.

Otro escenario en el que debe pensar: alguien deslizó su DBA (o quien sea que pueda ejecutar consultas seleccionadas en su base de datos) $ 100, para darles las contraseñas de los usuarios. O ingenieros sociales, algunos internos para hacer eso.

Luego usan esas contraseñas para iniciar sesión en el Gmail del usuario ... o en el sitio de comercio ... (porque las personas son ... menos inteligentes, digamos, y usan la misma contraseña en todos los sitios).

Luego, el usuario furioso demanda a su empresa por exponer su contraseña.

NADIE (incluidas las personas de su empresa) debería poder leer la contraseña de texto sin formato. Siempre. No hay una necesidad comercial o técnica legítima para eso.

Por un lado, incluso los administradores de bases de datos no deberían ver las contraseñas de los usuarios. Hashing evitará esto en caso de que el administrador decida buscar una contraseña e iniciar sesión en la cuenta de sus usuarios.

Bueno, es sorprendente que nadie haya mencionado esto todavía, pero ¿qué pasa con la seguridad FÍSICA de su base de datos?

Es posible que tenga configurada la mejor seguridad de TI del mundo, pero eso no detiene a nadie que pueda obtener acceso físico a sus medios de almacenamiento. ¿Qué sucede cuando su equipo gana el Superbowl esta tarde y estalla un pequeño motín en el centro de la ciudad donde se encuentra su oficina / proveedor de alojamiento? (Dado que es Seattle vs. Denver, dos grandes áreas de TI en los Estados Unidos, no creo que sea irrazonable). La mafia se estrella contra su edificio y, mientras las autoridades están abrumadas, ¿alguien toma parte de su hardware con una base de datos que contiene contraseñas de texto sin cifrar?

¿Qué sucede cuando los federales aparecen y confiscan su equipo porque algún ejecutivo de alto nivel estaba usando su posición en la compañía para ejecutar operaciones ilegales? Luego, los federales usan esas contraseñas para investigar a sus clientes, aunque no hicieron nada malo. Entonces se dan cuenta de que fue USTED quien los dejó vulnerables.

¿Qué sucede cuando su departamento de TI se olvida de borrar las viejas unidades RAID que contenían su DB cuando hacen reemplazos programados antes de "entregar" las viejas unidades a los pasantes, y luego sus compañeros de habitación encuentran lo que quedó atrás y se dan cuenta de que pueden " vender "y nunca se les ha rastreado?

¿Qué sucede cuando su Servidor DB vuela una placa base, TI restaura una imagen en su nuevo servidor y la "carcasa" del antiguo servidor se arroja al montón de reciclaje? Esas unidades siguen siendo buenas, y esos datos todavía están allí.

Cualquier arquitecto decente sabe que la seguridad no es algo que "atornille" más adelante con firewalls y políticas de operaciones. La seguridad tiene que ser una parte fundamental del diseño desde el principio, y eso significa que las contraseñas son unidireccionales, NUNCA se transmiten sin cifrado (incluso dentro de sus propios centros de datos) y nunca se pueden recuperar. Cualquier cosa que se pueda recuperar puede verse comprometida.

Dejando a un lado el caso de que su base de datos sea pirateada: como cliente, no quisiera que USTED sepa mi contraseña. Sé que puedes atrapar fácilmente la contraseña cuando se trata de una solicitud, pero tengo una mejor sensación cuando no la tienes a tu disposición para realizar consultas en cualquier momento que desees.

Si las contraseñas se almacenan en texto sin formato, significaría que son conocidas por el usuario y por quien tenga acceso a esa tabla. La idea general sobre la implementación de usuarios y contraseñas es garantizar que una determinada sesión en su sistema pertenezca a dicha persona, tanto por razones de privacidad como de seguridad.

Si un grupo de personas conoce un nombre de usuario / contraseña, resulta inútil identificar inequívocamente a una persona, y eso crea muchos escenarios posibles para el robo de identidad, el fraude ...

Es por eso que las contraseñas se almacenan utilizando protocolos de cifrado asimétricos, para asegurarse de que pueda validarlos sin ser capaz de leerlos.

Creo que hay una falla fundamental en la pregunta. El hecho es que no existe una "base de datos segura". Debe tomarse como un hecho que hay fallas en su sistema en algún lugar que podrían permitir a los usuarios malintencionados acceder a datos arbitrarios en sus servidores. Heartbleed es un excelente caso en cuestión, ya que fue una hazaña que estuvo en la naturaleza durante más de dos años antes de que los investigadores lo notaran. Es posible que haya hecho todo lo que sabe hacer para proteger los datos, pero no puede dar cuenta de todas las otras piezas de software que está utilizando en sus servidores y las formas complicadas en que interactúan.

Si alguien se interesa por ti, serás pirateado. Es importante hacer todo lo posible para evitar ser pirateado en primer lugar, pero también para mitigar el daño que se produce cuando ocurre colocando tantos obstáculos como sea posible. Hash tus contraseñas. No es tan difícil de configurar, y estás perjudicando a tus usuarios al no tomar en serio su privacidad. Es arrogante pensar que de alguna manera estás mejor protegido contra ataques maliciosos que compañías como Yahoo , Sony o Target , todas las cuales han sido pirateadas.