Mi administrador dice que no necesitamos saltear nuestras contraseñas porque es probable que las personas no usen la misma contraseña porque todas tienen diferentes idiomas nativos, además de los sitios web en los que están activos. ¿Cuál es el mejor argumento en contra de esto?
No estoy seguro de dónde eres. En primer lugar, su opinión está en contra de las mejores prácticas consideradas de la industria, según lo define NIST . Además su gerente está peligrosamente equivocado. Cuantos más usuarios, más probabilidades hay de obtener las mismas contraseñas para varios usuarios. También las siguientes compañías lo hacen y estoy bastante convencido de que tienen una base de usuarios global más grande que su sitio web:
Otra razón que es algo que puede explicar desde una perspectiva empresarial es el riesgo de daños a la imagen / marca cuando recibe publicidad negativa . Para darle un ejemplo, Adobe usó una implementación incorrecta para el almacenamiento de contraseñas, lo que lo llevó a tener el mismo problema que tiene ahora: el valor resultante del hashing (en el caso de Adobe que estaban usando cifrado en lugar de hashing) la contraseña fue la misma para varios usuarios si estaban usando la misma contraseña (en su caso debido a que no usaron una IV mientras realizaban el cifrado simétrico, pero esto no es relevante). Esto causó una tormenta masiva de publicidad negativa, después de todo, una compañía de Internet debería estar adhiriéndose a algo tan simple como el hashing de contraseñas, ¿no? El costo financiero resultante de dicha publicidad negativa puede ser significativo.
También dependiendo del país en el que viva y las leyes vigentes, en estos días se puede responsabilizar a la administración personalmente si se determina que fueron negligentes cuando se trata de proteger la privacidad de los datos (si se descifran Las contraseñas se utilizan para obtener datos personales de los usuarios, por ejemplo). También, dependiendo del tipo de información almacenada, financiera, médica, de tarjetas de crédito, se pueden aplicar diferentes reglas que también pueden resultar en otros tipos de multas.
Esto es algo que puede no ser relevante para el hash de contraseñas directamente, pero puede ser útil si su gerente toma otras decisiones erróneas. Así que asegúrese de hacer copias de los correos electrónicos donde explique claramente el problema y también guarde la respuesta de sus gerentes. (solo para cubrir tu propio trasero)
El hecho de que no esté utilizando sales probablemente también signifique que no está utilizando un algoritmo de hashing correcto, ya que a menudo se encargan de generar las sales y realizar una cantidad de iteraciones. Los tres algoritmos aceptados son:
El propósito principal de las sales es evitar que un atacante salve el trabajo comparando un solo hash calculado con todos los hashes almacenados. Este problema es independiente de si las contraseñas son únicas o no.
Sin sales, el atacante puede simplemente revisar su lista de posibles contraseñas, calcular el hash para cada una y luego verificar si el resultado coincide con alguno de los hashes almacenados. Así que solo se requiere un cálculo por conjetura.
Con las sales, el atacante debe revisar su lista para cada usuario, porque no puede reutilizar los resultados. Esto lo obliga a hacer un cálculo por conjetura y por usuario. Esto aumenta masivamente los costos del ataque.
Pero como Lucas ya dijo, el verdadero problema aquí es que no estás usando un algoritmo adecuado. Las sales son solo un aspecto del hashing de contraseñas.
El "mejor" argumento en contra depende de lo que estás tratando de lograr.
Si solo quiere ser científicamente correcto, basta con decir que las sales no son, y nunca han sido, un método para hacer frente a dos usuarios distintos que eligen la misma contraseña. En particular, porque dos usuarios que eligen la misma contraseña no son un problema para empezar, por lo que no hay nada que arreglar. Las sales son para evitar ataques paralelos, incluido el uso de tablas precomputadas. La falta de sales fue el pecado capital de LinkedIn .
Ahora estar en lo correcto tiene un efecto solo en las personas que están listas para reconocer que pueden estar equivocadas o al menos informadas de manera incompleta. Lo que cita de su gerente tiende a demostrar que es completamente incompetente en el tema y también está convencido de que lo domina por completo. Si quieres convencer a ese gerente de que está equivocado, entonces, buena suerte con eso. Lo que más temen las personas es admitir, aunque sea de forma implícita, que dijeron algo estúpido.
Si desea que su organización cambie realmente al hashing de contraseña adecuado (lea esto ), entonces, lo que podría poder hacer es convencer a otras personas de que lo que el gerente acaba de decir es pura tontería, que ni siquiera tiene suficiente sentido para estar realmente equivocado Si el administrador se queda aislado, puede hacer la vista gorda sobre la implementación del hashing de contraseña adecuado, sin que, por supuesto, lo reconozca. Una vez más, el argumento científicamente correcto no es necesariamente el más eficiente. En América del Norte (especialmente en áreas con influencia británica como Nueva Inglaterra), las reuniones de negocios consisten en evitar los choques y diluir la responsabilidad, por lo que debería difundir un poco de información a
Uno de los tipos de argumentos más eficientes, en general, es el recurso a la autoridad. En Publicación especial NIST SP800-118 (actualmente en borrador), una Puede ver:
Otro ejemplo de la debilidad del algoritmo hash es que algunos algoritmos no utilizan salting.
"Sin sal"="debilidad". NIST dice eso. ¿Quién es este gerente que piensa que es más inteligente que NIST?
En cierto sentido, si estás discutiendo sobre la sal, entonces ya perdiste el bote. El estado de la técnica con respecto a la seguridad del almacenamiento de contraseñas va mucho más allá de la cuestión de "saltear o no saltear", y desde entonces ha pasado a contar iteraciones.
Pero empecemos por lo básico. Aquí hay una respuesta que escribí hace poco que fue sorprendentemente popular. Explica por qué la sal es mejor, y muchas personas han dicho que hizo clic en un clic donde otras explicaciones no se concretaron. Es más o menos lo que estás preguntando: muéstraselo a tu jefe si crees que funcionará bien:
¿Por qué son más seguros los hashes salados?
Pero el punto importante es el último hecho allí. Es decir, almacenar un hash SHA1 salado y considerarlo bueno ya no se considera responsable. La potencia de cálculo ha llegado al punto en que miles de millones de hashes por segundo ya no son teóricos, lo que te permite volar todo el espacio de 32 bits de un ataque de fuerza bruta más rápido de lo que se necesitaría para explicar lo que estás haciendo. p>
Ahora el foco está en obligar al atacante a resolver el problema miles o cientos de miles de veces solo para hacer una conjetura. Ahí es donde se muestra PBKDF2 (con su traje y corbata emitidos por el NIST), así como scrypt y amigos (con aspecto desaliñado pero poderoso).
El algoritmo que elija no es realmente la clave. Todos resuelven aproximadamente el mismo problema, solo que de diferentes maneras con diferentes énfasis. Pero tienes que usar algo , un algoritmo que dificulta la fuerza bruta incluso con una sola contraseña. La razón es simple: es el estándar de la industria, es mucho más segura y no tiene un costo significativo por usarla. Reúna esos factores y rápidamente se hace evidente que si no lo hace, entonces puede ser considerado negligente en caso de una infracción.
El mejor argumento es sacar una lista de las contraseñas más comunes y mostrar que aproximadamente 1 % de tus usuarios elegirán "123456". El segundo mejor sería sacar un fuga de contraseña analice un sitio grande y muestre que solo la mitad de sus usuarios lograrán crear una contraseña única.
Debes hacer dos puntos:
El uso de un salt reduce el valor de un archivo robado que contiene contraseñas con hash. Esto es cierto independientemente de los idiomas que hablan los usuarios del sistema, porque un atacante que tiene una tabla de arco iris para su algoritmo de hash puede usarlo para revertir la contraseña con hash independientemente del idioma nativo de la persona que eligió eso. contraseña.
El uso de una sal es casi gratis. No le gana casi nada para excluirlo, e incluso en la estimación actual de su gerente, excluirlo solo es "probable" que no cause un problema de seguridad grave. Por lo tanto, úsalo.
Hay una objeción que su gerente podría plantear contra el primer punto, pero espero que no: "estamos usando nuestro propio algoritmo de hashing personalizado, por lo que no existe peligro de que exista una tabla de arco iris". En ese caso, debe también establecer el caso para usar un algoritmo de hashing de contraseña estándar.
También encuentro:
[los usuarios] todos tienen diferentes idiomas nativos
para ser un supuesto extraño para hacer acerca de un sistema. Si confía en una suposición para su análisis de seguridad, entonces su sistema se vuelve inseguro (o, en cualquier caso, no se evalúa la seguridad) tan pronto como se rompe la suposición. Por lo tanto, después de confiar en esta suposición de seguridad, debe hacer cumplir que no hay dos usuarios del producto que tengan el mismo idioma nativo . ¿Por qué demonios alguien querría restringir su sistema de esa manera y, en particular, cómo va a ser más fácil hacer cumplir esta restricción que usar una sal?
Sin embargo, en este caso, esa suposición ni siquiera lleva a la conclusión de que su gerente hace que la sal no sea necesaria (por la razón que mencioné anteriormente). Por lo tanto, la cuestión de si se puede mantener el supuesto es bastante irrelevante, ya que no ayuda.
Finalmente, para tu información, hay una razón específica por la que mi primer punto anterior contradice el análisis de tu gerente:
no es probable que use la misma contraseña
es un análisis defectuoso de la debilidad que trata la sal. No le importa al atacante si dos usuarios del sistema tienen la misma contraseña o no, a menos que el atacante sea uno de esos dos usuarios y, por lo tanto, conozca la contraseña que comparten. Las sales no solo se defienden contra este ataque, también se defienden contra los ataques de la mesa del arco iris. Por lo tanto, incluso si este inusual ataque por la misma contraseña de uno de sus usuarios fuera imposible en su sistema, aún necesitaría sales.
Supongo que esto es más un problema de personas que un problema técnico. Por lo tanto, debe responder con habilidades blandas en lugar de explicaciones técnicas. Si su gerente reacciona positivamente con las explicaciones técnicas, elija una de las respuestas antes.
Si quieres ponerte del lado de las habilidades sociales, puedes probar algunas cosas:
Un cuadro de diálogo de ejemplo podría tener este aspecto (tenga en cuenta que no soy un hablante nativo de inglés):
Jefe: "No necesitamos sales".
Usted: "No necesitamos esa protección adicional".
Jefe: "Sí, nuestros usuarios no reutilizan la misma contraseña".
Usted: "La contraseña segura ya es segura".
Jefe: "Eso es correcto".
Usted: "De acuerdo, entiendo. Nuestros usuarios hacen que la contraseña sea segura y simplemente vivimos sin sales".
Jefe: "Sí, tal vez no todos los usuarios ..."
Tú: smile
O como esto:
Jefe: "No necesitamos sales".
Usted: "El beneficio de usar sales no vale la pena el esfuerzo".
Jefe: "Eso es correcto".
Usted: "Así que eliminamos la sal de la lista de tareas y continuamos con el resto".
Jefe: "Bien, ya estamos atrasados".
Usted: "Si cumpliéramos con el cronograma de otra manera, podríamos implementar la sal".
Jefe: "No, no entiendo ese concepto de sal".
Tú: "Esas cosas criptográficas siempre son difíciles de entender".
Jefe: "Incluso cuando leí un artículo, no entendí la pista".
Tú: "Lo que te hace pensar que es mucho esfuerzo".
Jefe: "Sí, perderemos dos días más o menos".
Tú: "Con la ayuda de un framework puedo hacerlo en 2 horas".
Jefe: "¿En serio?"
Tú: smile
Tenga en cuenta que no hay ningún signo de interrogación. El jefe nunca está bajo la presión de responder a preguntas a las que tal vez no sepa la respuesta.
Desafortunadamente, es bastante difícil aplicar tales técnicas si nunca lo hiciste antes.
Si este enfoque tampoco funciona bien, hay una opción más:
Solo implementalo. No debería ser demasiado esfuerzo y su jefe probablemente no lo notará, excepto que está revisando el código o mirando las tablas de la base de datos.
Simplemente lanza algunos hashs (tal vez su propia contraseña) en Google. Lo más probable es que devuelva la contraseña. Su hash débil es como ningún hash en absoluto.
Si eso no lo convence, busque un nuevo trabajo ...