¿Ofuscar un modelo de seguridad tiene un lugar en la seguridad de las contraseñas?

Question

Cuando se trata de la seguridad con contraseñas, hay cosas en las que las personas están de acuerdo, como almacenar hashes de contraseñas salados, lo que brinda una defensa estadística contra un modelo y datos comprometidos.

Con lo que algunos no parecen estar de acuerdo, es qué hacer con las sales. Hay un número infinito de técnicas que puede hacer para tratar de proteger las sales, pero muchos expertos sugerirán que son simplemente una ofuscación inútil del modelo de seguridad, y que con el tiempo el modelo quedará expuesto, y me encuentro en desacuerdo con esto, pero puede que no esté entendiendo el otro punto de vista.

Lo que no entiendo es si su modelo está en peligro, ¿por qué debería asumir un compromiso total en lugar de un parcial? Si su modelo de seguridad se distribuye en diferentes partes de la infraestructura que no están igualmente protegidas, un compromiso parcial podría no ser un problema. (Si hace algo así como, digamos, encriptar la sal y recuperar la clave de encriptación de un entorno más seguro que es menos probable que se vea comprometida)

Supongo que un compromiso no siempre es 100% aquí . Nunca me han pirateado el sistema ni he pirateado, así que no tengo una imagen completa.

Answer 1

La gran diferencia entre la ofuscación y cifrado es que lo que se ofusca puede ser aclarado sin necesidad de nada más allá de la información ofuscado - siempre y cuando se puede averiguar el tipo de datos que se está viendo, entonces se puede encuentra una manera de aclararlo.

El cifrado, mientras tanto, solo se puede descifrar con la herramienta de clave/contraseña/grieta correcta. Los datos encriptados sin esas cosas son muy seguros.

En consecuencia, la ofuscación puede, en el mejor de los casos, enlentecer a un atacante determinado, aunque podría posponer una menos determinada.Hay muchas cosas más fáciles y más fáciles de mantener en torno a la seguridad de su sistema y sus servidores para protegerlos contra atacantes menos decididos, por lo que el costo de ofuscación en términos de trabajo adicional para usted y sus sistemas rara vez se justifica en mi opinión.

Asumir un compromiso no es 100% cuando se produce es un esfuerzo muy arriesgado, ya que lo que en realidad está asumiendo es que es más inteligente y más consciente de su sistema que su atacante. Puede que tengas razón, pero si asumes y estás equivocado, entonces estás en un problema muy serio. Tienes que demostrarlo, y teniendo en cuenta los problemas para demostrar que es negativo, es más seguro actuar como si hubieras estado completamente comprometido cuando se produce un compromiso y diseñar tus sistemas para que estén lo más seguros posible, incluso en una situación en la que compromiso ha ocurrido.

Answer 2

La seguridad a través de la oscuridad, es, en el mejor de los casos, una apuesta. ¿Vale la pena almacenar la sal en otro lugar? Probablemente. Pero debe observar el costo versus la recompensa cuando comience a utilizar estas configuraciones de seguridad de varios pasos. Yo diría que si su aplicación lo requiere, lo sabrá. De lo contrario, agregar más pasos en la aplicación por el bien de tener una seguridad súper intensa puede darte dolores de cabeza solo cuando las cosas van mal. No todo el mundo necesita seguridad a nivel de la NASA para sus sistemas. Eso no quiere decir que la seguridad no es importante. Es solo que necesitas atemperarlo en tu entorno actual.

Answer 3

si su modelo está en peligro, ¿por qué debería asumir un compromiso completo en lugar de un parcial?

Siempre debe asumir el peor de los casos en materia de seguridad. Este es el enfoque más seguro.

un compromiso parcial podría incluso no ser un problema

Tal vez. ¿Pero estás realmente seguro?
En su OP está basando su análisis en demasiadas suposiciones. Quizás en una configuración muy específica su evaluación de que un compromiso parcial podría no ser un problema podría ser justificable.
Pero, de nuevo, supones que el atacante no es lo suficientemente bueno para encontrar un agujero.
No base su modelo de seguridad en suposiciones.