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

78

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?

phpmysqlguy
fuente
124
Yo iría un paso más allá. No es suficiente cifrarlo. Querrías picadillo. De esa manera, ni siquiera usted debería poder saber cuáles son las contraseñas de texto sin formato de sus usuarios.
Santa
67
@Santa Hashing la contraseña no es suficiente. Tienes que agregar un poco de sal para que la receta sea lo suficientemente buena ...
Bakuriu
16
Por favor, eche un vistazo a esta publicación relevante de Security.StackExchange: ¿Cómo hash de contraseñas de forma segura?
Adi
10
El DBA descontento dice ... seleccione * del usuario, y luego vende esa lista por indemnización por despido. Nada es seguro nunca.
Jon Raynor
también security.blogoverflow.com/2011/11/…
David J. Liszewski el

Respuestas:

194

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.

pdr
fuente
89
O mejor, hash!
Blorgbeard
29
Esta. "Tengo otros problemas si alguien entra en mi base de datos". Es su base de datos, espera tener problemas si se piratea. Pero al almacenar contraseñas de texto sin formato, le da problemas a todos sus usuarios con, potencialmente, todas sus otras cuentas. ¿Cuántas personas crees que realmente usan una contraseña diferente en cada sitio web?
Carson63000
13
Por favor, siga los consejos de Blorgbeard, tal vez lea esto . Cifrar contraseñas no proporciona protección cuando su servidor web se ha visto comprometido. La clave para descifrar las contraseñas debe almacenarse en algún lugar del servidor. El hash de las contraseñas significa que incluso en el caso de que alguien tenga acceso completo a la máquina, no pueden recuperar las contraseñas fácilmente.
Slicedpan
77
¿Por qué necesitaría encriptar contraseñas si no proporciona valor a su sistema? ¿En qué momento tendrá que descifrar las contraseñas, aparte de la comparación? @pdr, no deberías decirle al OP que cifre, deberías decirle que se ponga sal y picadillo.
NobleUplift
44
También desea analizar las respuestas a sus preguntas de recuperación de contraseña. De lo contrario, también se pueden usar para acceder a otros sitios, como las contraseñas.
Zan Lynx
64

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.

david25272
fuente
13
+1 por mencionar empleados descontentos. Es fácil pasarlo por alto cuando se trata de una tienda unipersonal o una pequeña empresa, pero eventualmente habrá personas trabajando con los datos que no ha investigado personalmente.
2
Escribir el foreach para recorrer una lista de usuarios y luego descifrar sus contraseñas es el trabajo de unos minutos y, francamente, 4000 no es casi nada. php.net/manual/en/function.hash.php
Elin
3
Sigue cambiando entre los términos "cifrar" con "hash y salt" @ david25272. No confundas los dos, que son completamente diferentes. Ahora el OP está buscando un algoritmo de cifrado, y no un algoritmo hash. Además, es "sal y hachís", no "hachís y sal". No puedes salar después de hash.
NobleUplift
1
También @phpmysqlguy, lea mi respuesta para sugerencias sobre algoritmos de salazón y hash .
NobleUplift
36

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.

Sean McSomething
fuente
99
Usted hace lo que creo que es el punto más importante: USTED y sus trabajadores no deberían tener acceso a la contraseña del usuario. A quién le importa el hacker, son las personas que poseen los datos lo que concierne a los usuarios.
Adam Davis
1
+1 por el hecho de que como desarrollador / administrador no debe tener acceso a las contraseñas de sus usuarios. Eso en sí mismo es razón suficiente.
Matt
21

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.

Karl Bielefeldt
fuente
18

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.

NobleUplift
fuente
+1 para hachís más sal. Romper hashes sin sales es muuuy fácil.
Código Maverick
3
¿Sabes qué hay al otro lado de una mesa arcoiris @CodeMaverick? Una olla de oro.
NobleUplift
En el contexto del hashing de contraseñas, MD5 no tiene vulnerabilidades conocidas más allá de ser rápido, y eso se aplica también a SHA-2. Usar una construcción lenta e iterada es mucho más importante que elegir SHA-2 sobre MD5.
CodesInChaos
44
"Lea toda esta página antes de hash de las contraseñas" - que la página se menciona que se debe no utilizar cartuchos de hash, sino un método de codificación que ha sido diseñado específicamente para ser tan lento como sea necesario, como PBKDF2.
jhominal
2
Use SCrypt o PBKDF2, los cuales están diseñados para ser muy caros en términos de memoria o CPU. Use un Salt generado aleatoriamente que almacene en el registro de usuario. No realice múltiples rondas de hashing, eso solo conduce a problemas de colisión.
tom.dietrich
14

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.
Michael Shaw
fuente
66
En general, se prefiere usar una sal aleatoria en lugar del nombre de usuario.
CodesInChaos
Wow, gran captura @CodesInChaos. No me di cuenta de eso en mi primera lectura de la pregunta. Sí, tu sal debe generarse al azar. No tiene que ser un blob loco almacenado en MySQL (y eso sería malo porque entonces no sería portátil). De lo contrario, +1 por decir que solo el usuario debe conocer la contraseña del usuario.
NobleUplift
Bien, la respuesta actualizada sugiere que la aplicación tiene su propio valor de sal aleatorio.
Michael Shaw
44
No, la aplicación tampoco tiene un valor de sal. Debe haber un valor de sal diferente, muy aleatorio, para cada hash almacenado. (Almacena la sal junto con el hash). Eso es lo que protege contra los ataques estadísticos. Si utilizó el mismo hash para toda la aplicación, los mismos hashes de texto plano tienen el mismo valor. Eso es mucho peor que usar el nombre de usuario como hash.
Ben Voigt
No es un servicio web, pero la autenticación de par de claves SSH usa la solución 'pura', donde el servidor almacena una clave pública y el usuario se autentica con una clave privada.
cpast
10

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).

Thomas Pornin
fuente
+1 por conocer la diferencia entre cifrado y hashing.
NobleUplift
8

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

Elin
fuente
2
Desafortunadamente, estoy usando PHP 5.3.3 para que sus sugerencias no se apliquen
Phpmysqlguy
44
¿5.3.3 a 5.3.8 es una gran actualización?
gbjbaanb
¿Alguna posibilidad de que estés en Red Hat? Porque han respaldado la solución para bcrypt. De lo contrario, use SHA256 en lugar de brcypt.
Elin
1
El cifrado y el hash son cosas diferentes. Hash contraseñas, no las cifre. Nunca necesitas saberlos. Solo necesita que el usuario pueda usar la contraseña para demostrar quién es. Hashing (con sal) lo permite. Cifrado, esp. el cifrado simétrico es incorrecto ya que permite recuperar contraseñas.
Paul de Vrieze
Lo único que agregaré es que lo bueno de la función password_hash () en php 5.5+ es que maneja la salazón, etc., de manera sensata por defecto. Antes de eso, debe seguir adelante y usar algo como la biblioteca de ircmaxell que lo respalda (escribió la implementación 5.5). No asumas que puedes generar una sal al azar por ti mismo. Es muy muy difícil y es mejor dejarlo en manos de expertos; Es realmente fácil obtener resultados aleatorios pero no uniformes que sean explotables.
Elin
7

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.

AngCaruso
fuente
+1 por mencionar tanto la salazón como el hash, así como no mencionar el cifrado, que ni siquiera pertenece a esta pregunta.
NobleUplift
2

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.

DVK
fuente
2

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.

Rolen Koh
fuente
1
esto no agrega nada digno de lo que ya se publicó en respuestas anteriores
mosquito
3
+1. De hecho, dijo "hashing", en lugar de cifrado como muchos otros. Además, contradijo directamente al OP, quien dijo que quería que las contraseñas de texto simple ingresaran en las cuentas de otros usuarios.
NobleUplift
0

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.

Wesley Long
fuente
-1

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.

piet.t
fuente
1
En realidad, si el OP lo llevó un paso más allá y se cifró en JavaScript, entonces el hash se enviaría por cable y nunca se vería en la solicitud.
NobleUplift
1
En ese caso, un atacante solo necesitaría enviar el hash por el cable también. El hash simplemente funcionaría como una contraseña elegante pero no encriptada, ¿no? (Editar: no si tenía que ser salado con una sal diferente cada vez, y la sal provenía del servidor. Creo)
RemcoGerlich
1
@RemcoGerlich El concepto clave se conoce como nonce, que se utiliza para evitar un ataque de repetición .
-1

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.

Alpha1983
fuente
2
¿Quién almacena las contraseñas con cifrado asimétrico? Esa es la criptografía de clave pública, lo que significa que incluso después de cifrar mi contraseña, se puede descifrar y leer si alguien alguna vez obtiene mi clave privada. Con el hash, yo y solo yo sé mi contraseña (a menos que la escriba o la guarde en un administrador de contraseñas, donde en realidad es cifrado asimétrico).
NobleUplift
Por favor, consulte la página de Wikipedia para la criptografía de clave pública: en.wikipedia.org/wiki/Public-key_cryptography "Criptografía de clave pública, también conocida como criptografía asimétrica"
Alpha1983
2
... sí, dije eso using asymmetric encryption? That's public-key cryptography. ¿Cuál es tu punto?
NobleUplift
-1

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.

lobati
fuente
1
esto no parece ofrecer nada sustancial sobre 14 respuestas anteriores
mosquito
No estoy de acuerdo, de lo contrario no lo habría publicado. Sin embargo, no estoy seguro de ver cómo su andar haciendo comentarios negativos se suma a la conversación, además de desanimar a las personas a participar.
lobati
bueno, no sé si ha leído otras respuestas antes de publicar la suya, pero según mi lectura, todos los puntos aquí ya se hicieron (y según mi lectura mejor presentados) en otros lugares. Por ejemplo, el punto sobre la falla en la pregunta se hizo hace más de 2 meses en esta y esta respuesta. El punto sobre las contraseñas hash se hizo al menos en otras 7 respuestas. El punto sobre hacer copias de seguridad y dar cuenta de posibles problemas en otras partes del sistema también se hizo hace mucho tiempo. Etc, etc.
mosquito
El punto de falacia vinculado era diferente al mío. Indicaban la diferencia de significado entre el cifrado y el cifrado, mientras que decía que era una falacia pensar que una base de datos podría considerarse "segura". Todavía no veo ninguna otra respuesta que discuta otras piezas de software y sus interacciones sean inseguras, y no hice ningún comentario sobre las copias de seguridad.
lobati
"asuma que será hackeado" - así es como se deletrea en una respuesta publicada hace más de 2 meses
mosquito