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

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

Pero, lo que es más importante, esto no se trata de usted. El hecho de que pueda estar jodido si alguien tiene acceso completo a su base de datos es irrelevante. Mucho más importante es la información del usuario.

Si recuperas tu base de datos, el pirata informático aún tiene acceso a la cuenta de tu usuario.

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

¿Y si eso los lleva a otras cuentas? No deje que un pirata informático pase por un sistema de asistencia al usuario y obtenga más información .

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

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), debe usar un par de claves pública / privada , lo cual está bien, pero dificulta un poco la vida tanto para usted como para su usuario.

Una solución más simple y igual de efectiva es la de random-salt y hash la contraseña. El hash solo no es suficiente; Si su usuario usa una contraseña común, aparecerá en 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 las copias de seguridad y arreglarlo. ¡Pero el pirata informático aún tiene contraseñas para las cuentas de todos! Hay ejemplos documentados del mundo real de este suceso (Sony, Linked-in), donde si las tablas de contraseñas se hubieran rellenado y rellenado correctamente, se aseguró y restauró El servicio rápidamente hubiera 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 con esta suposición en mente. Y no es solo contra los hackers contra los que debes protegerte. Los empleados descontentos, deshonestos o simplemente despistados podrían revelar contraseñas de texto sin formato.

Sin hash, tendrá que deshabilitar el acceso para todos hasta que cambien su contraseña (lo cual, incluso si es posible, será un gran dolor de cabeza para todos). Si las contraseñas hubieran sido procesadas y almacenadas, 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 hash y con sal es básicamente unidireccional. No se 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.

También, como dijo Elin, no intentes tirar tu propio hash (o cifrado). Utilice una biblioteca estándar.

  

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

No se trata de los problemas que tienes , sino de los problemas que puede causar a todos los demás usuarios. Se trata de eliminar la tentación (o, lo que es peor, la posible responsabilidad) de las personas que trabajan en el sitio para abusar de los datos almacenados allí.

Vea, aunque la gente debería usar diferentes contraseñas en diferentes sistemas, la realidad es que no .

... y dado que es tan fácil de hash de contraseñas, no tiene excusas para no seguir las mejores prácticas de la industria.

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

Además, no todos los compromisos le dan acceso total al shell. ¿Qué sucede si la vulnerabilidad de un atacante es solo una inyección de SQL de solo lectura en la tabla users ? Dejando las contraseñas sin dañar, solo le dio acceso completo.

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

Tengo que publicar una respuesta aquí sobre una falacia en la pregunta en sí. Usted está preguntando si las contraseñas deben ser cifradas. Nadie encripta las contraseñas; nadie, con la excepción de servicios y programas como Firefox Sync y Roboform, cuyo único propósito es cifrar las contraseñas.

Echemos un vistazo a las definiciones:

  

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

Y hashing:

  

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

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

Además, ¡no solo el hash, sal ! Lea esta página completa antes de codificar sus contraseñas.

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

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

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

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

Los otros puntos que hace pdr son exactamente lo que más diría: gente que usan la misma contraseña para cada sitio web, piratas informáticos que usan ingeniería social para obtener más información, etc., etc.

Hay un principio importante en juego aquí. Solo hay una persona que tiene un negocio 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 usando. Esto crea un desafío, ya que el programador tiene la responsabilidad de recibir la prueba de que el usuario realmente conoce la contraseña, lo cual no es un problema fácil de resolver de manera pura.

La solución pura es tener un mecanismo donde el usuario se enfrenta a algunos datos nuevos e impredecibles, y luego tiene que devolver una respuesta basada 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 probar matemáticamente que utilizaron el mismo par de claves criptográficas que usaron originalmente para crear la cuenta.

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

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 de hashing, junto con el valor aleatorio de 'sal' de la aplicación en la función de hash.

La cadena original se sobrescribe en la memoria y, a partir de este punto, 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 autenticación directamente.
2. El cálculo inverso de la contraseña del hash no es práctico.
3. El uso de tablas de arco iris (listas largas de contraseñas y sus hash calculados) se hace más desafiante porque el hash resultante es depende tanto del nombre de usuario como de la contraseña.

Necesitas "cifrar" (en realidad, "hash", para una noción adecuada de hash) las contraseñas como segunda capa de defensa : esto está destinado a evitar que un atacante, que tiene una Un vistazo de solo lectura de la base de datos, desde la escalada hasta el acceso de lectura y escritura y, precisamente, comienzan a alterar los datos. Las infracciones parciales de solo lectura ocurren en el mundo real, p. Ej. a través de algún ataque de inyección SQL desde una cuenta con acceso de solo lectura, o recuperando un disco duro desechado o una cinta de copia de seguridad antigua de un contenedor de basura. He escrito extensamente sobre este tema allí .

En cuanto a las formas adecuadas de hash de contraseñas, consulte 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 otras personas han dicho, pero suponiendo que tenga PHP 5.3.8 o mejor, usted Debería estar usando el PHP nativo bcrypt para 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 puedes usar una biblioteca para hacer que 5.3.8 o mejor se comporte como 5.5.

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

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

Yo agregaría lo siguiente: debe hacerlo porque es fácil y generalmente aceptado como la mejor práctica para cualquier aplicación. Más específicamente, las contraseñas siempre deben estar selladas y con hash antes de escribir en cualquier almacenamiento persistente. Aquí hay una buena referencia sobre la importancia de utilizar sal y elegir un buen hash criptográfico (que también proporciona código fuente gratuito en varios idiomas populares): enlace

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 eres hackeado.

Otro escenario en el que debes pensar: alguien deslizó tu DBA (o quien más pueda ejecutar consultas de selección en tu base de datos) $ 100, para darles las contraseñas de los usuarios. O ingenieros sociales, algún interno para hacer eso.

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

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

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

Por un lado, incluso los administradores de bases de datos no deberían ver las contraseñas de los usuarios. Hash les 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 impide que cualquiera que tenga acceso físico a sus medios de almacenamiento. ¿Qué sucede cuando su equipo gana la Superbowl esta tarde y surge un pequeño motín en el centro de la ciudad donde se encuentra su proveedor de oficina / alojamiento? (Dado que son Seattle vs. Denver, dos grandes áreas de TI en los EE. UU., 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 no cifrado?

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

¿Qué sucede cuando su departamento de TI se olvida de borrar las unidades RAID antiguas que contenían su base de datos cuando realizan reemplazos programados antes de "entregar" las unidades antiguas a los internos, y luego sus compañeros de habitación encuentran lo que quedó atrás y averiguan? ¿Pueden "venderlo" y nunca se lo han rastreado?

¿Qué sucede cuando su servidor DB sopla una placa base, TI restaura una imagen a su nuevo servidor y la "carcasa" del antiguo servidor se desecha en el montón de reciclaje? Esos discos siguen siendo buenos y los datos siguen ahí.

Cualquier arquitecto decente sabe que la seguridad no es algo que se "aplique" 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 están en un solo sentido, NUNCA se transmiten sin cifrado (incluso dentro de sus propios centros de datos) y nunca se pueden recuperar. Cualquier cosa que pueda ser recuperada puede ser comprometida.

Dejando de lado el caso de que su base de datos haya sido hackeada: Como cliente, no quisiera que USTED conociera mi contraseña. Sé que puede captar fácilmente la contraseña cuando la solicite, pero tengo una mejor idea cuando no la tiene a su disposición para realizar consultas cuando lo desee.

Si las contraseñas se almacenan en texto sin formato, significaría que el usuario las conoce y quién tiene acceso a esa tabla. La idea general de implementar 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, se vuelve inútil identificar de manera inequívoca 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 mediante protocolos de cifrado asimétricos, para asegurarse de que pueda validarlos sin poder leerlos.

Creo que hay una falla fundamental en la pregunta. El hecho es que no existe una "base de datos segura". Se debe tomar en cuenta que hay fallas en su sistema en algún lugar que podrían permitir el acceso de usuarios malintencionados a datos arbitrarios en sus servidores. Heartbleed es un excelente ejemplo de ello, ya que se trata de un exploit que estuvo en libertad 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, se será hackeado. Es importante hacer todo lo posible para evitar que lo pirateen en primer lugar, pero también para mitigar el daño que se hace cuando sucede, colocando tantos obstáculos como sea posible. Hash tus contraseñas. No es tan difícil de configurar, y está perjudicando a sus usuarios al no tomar en serio su privacidad. Es arrogante pensar que de alguna manera estás mejor protegido contra ataques maliciosos que empresas como Yahoo , o Sony , o Target , todos los cuales han sido hackeados.