¿Quién es responsable de la seguridad de las contraseñas de los usuarios?

No puede responder a esta pregunta sin responder a la siguiente pregunta

  

Si la contraseña de un usuario está comprometida, ¿eso solo pone en riesgo los datos de ese usuario / usuario, o también pone en riesgo a otros usuarios?

Si el sistema no tiene cuentas en compartalize , entonces el usuario no puede mantener sus datos seguros al elegir los apropiados credenciales, por lo que los administradores deben ser responsables, en parte, de la seguridad general de la comunidad.

Si el sistema divide las cuentas, entonces un usuario solo puede dañarse a sí mismo al elegir credenciales débiles, por lo que transferir la responsabilidad al usuario puede ser apropiado.

Por ejemplo, los buzones de correo electrónico están bien compartimentados; comprometer una cuenta no compromete mucho a otras. Algunas cuentas pueden configurarse para que no se traten como correo no deseado de otras cuentas, pero hay muchas otras formas de suplantar a los remitentes de correo electrónico, por lo que la capacidad de enviar correos electrónicos como usuario no suele ser una gran escalada de autoridad. Un administrador puede renunciar a la responsabilidad de la seguridad de la contraseña sin comprometer la seguridad del sistema.

Pero los sistemas de archivos y los repositorios de código fuente no están bien compartimentados. Comprometer a una cuenta cuyo directorio ~/bin está en el PATH s de otros usuarios, o que tiene acceso comprometido a un repositorio de código fuente vital puede comprometer muchas otras cuentas y sistemas a través de trojans . En este caso, comprometer una cuenta aumenta la autoridad en todo el sistema; los administradores no pueden renunciar a la responsabilidad de la seguridad de la contraseña porque no pueden renunciar a la responsabilidad de la salud del sistema.

Si usted es un desarrollador, no debe ser el único requisito de configuración: esto debe ser establecido en la política por la organización para la que está desarrollando, sin embargo, si tiene conocimiento de la seguridad, debería poder hablar sobre una línea de base mínima. debiera ser. De hecho, es posible que pueda usar la seguridad de su aplicación como un punto de venta adicional sobre la competencia en el entorno actual de miedo por ser hackeado.

Pero absolutamente no debe ser su responsabilidad: la política de la organización debe definir los requisitos de contraseña según su nivel de riesgo, y las personas siempre pueden usar una contraseña más fuerte que la mínima requerida.

En la medida en que desee contraseñas seguras para proteger su servidor / servicio, es su "culpa" si sus políticas son demasiado indulgentes. Eso supone que su servidor / servicio está amenazado por un compromiso individual del usuario final, lo que no siempre es así.

En la medida en que sus usuarios deseen que su propia cuenta esté protegida, es su "culpa" si no eligen una contraseña lo suficientemente segura, independientemente de las políticas vigentes.

Si hay suficientes cuentas comprometidas, entonces la "falla" está determinada por quién hace girar su vista a los medios de manera más rápida y efectiva.

Es realmente un área donde puedes llevar un caballo al agua, pero no puedes hacer que beban. Las políticas de contraseñas draconianas usualmente causan que la seguridad se filtre en alguna otra dirección, como escribir contraseñas o confiar en secuencias no alfa adivinables, como las fechas de nacimiento. Las políticas de contraseña faltantes conducen a problemas de enlace más débiles, ya que alguien siempre elegirá 'secreto' como su contraseña dada la opción.

"falla" es un concepto bastante nebuloso aquí. Podrías preguntar sobre responsabilidad legal, que es más firme. Creo que ha habido uno o dos casos relacionados con contraseñas bancarias que se vieron comprometidas al que se culpó al banco por no requerir suficiente protección, pero no recuerdo los resultados.

En realidad, hay un ejemplo fascinante que vi la semana pasada. Una organización sin fines de lucro perdió $ 70k cuando alguien obtuvo contraseñas para sus operaciones bancarias y las aprovechó.

  

"Habíamos rechazado algunas de las medidas de seguridad que se nos ofrecieron, [pero si]   teníamos los que no nos hubieran sucedido ", dijo French.   "Pensamos que sería una carga administrativa, y yo era más   preocupado por las cosas internas, no por alguien pirateando nuestros sistemas ".

y luego

  

Desde entonces, MECA ha agregado más funciones de seguridad a su banca en línea.   cuenta, y el acceso a esa cuenta solo es posible a través de   Equipo dedicado y bloqueado.

     

"Todo esto es un día tarde y un dólar corto, supongo", dijo French.   "¿Por qué alguien no está gritando en los tejados sobre este fraude?   Las personas necesitan entender cuán expuestas están ”.

Eso ilustra las actitudes de las personas hacia la seguridad de la contraseña allí mismo. "Nos negamos a fortalecer nuestra seguridad ... ¿por qué alguien no nos dijo que fortaleciéramos nuestra seguridad?" ¿Qué tan lejos están de demandar a su banco por no requerir una mejor seguridad?

Me parece que hay dos temas separados que deben ser cubiertos en la pregunta.

Usuarios que eligen contraseñas débiles.

La responsabilidad de esta pieza se puede dividir de tres maneras:

1. Las oficinas de administración y seguridad de TI dentro de la organización deben definir las políticas adecuadas para la seguridad de la contraseña, la actualización y la reutilización.
2. Los Desarrolladores deben implementar adecuadamente las restricciones técnicas que hacen cumplir estas políticas.
3. Los usuarios deben seguir el espíritu de estas políticas, no solo la "letra de la ley", para crear contraseñas "fuertes".

Al final, la responsabilidad de la "fortaleza" de la contraseña depende totalmente del Usuario. (Aunque la ley puede juzgar de manera diferente, no soy un abogado, por lo que no puedo hablar de eso). Sin embargo, sería irresponsable de nosotros (Seguridad de TI, Administración, Desarrolladores, etc.) a no establezca y aplique las políticas de contraseña adecuadas y eduque a los Usuarios sobre la necesidad y la implementación adecuada de estas políticas.

Compromiso de la base de datos de contraseñas.

Para responder completamente a la pregunta:

  

"Si un usuario que tiene una contraseña de una palabra muy simple ha pirateado su cuenta en un ataque de diccionario, ¿es culpa suya o es culpa nuestra que hayamos permitido una contraseña tan simple?"

En primer lugar, también tenemos que abordar cómo fue posible el ataque del diccionario. Es decir, ¿quién fue el responsable de proteger la base de datos de contraseñas? Esto se divide en dos grupos y, si los medios de comunicación son una buena medida, probablemente refleja a quién es más probable que se culpe al menos públicamente, si no legalmente, por las cuentas secuestradas.

1. Las oficinas de Administración y Seguridad de TI dentro de la organización necesitan definir políticas apropiadas con respecto al mantenimiento y seguridad de los servidores de la organización.
2. Los Desarrolladores deben implementar estas políticas correctamente tanto en la aplicación técnica como en la práctica general.

Si la base de datos de contraseñas está expuesta a un atacante, las contraseñas se pueden descifrar independientemente de su fortaleza . Es solo una cuestión de cuánto tiempo y poder de cómputo el atacante está dispuesto a dedicar a la tarea. Es enteramente la responsabilidad de la organización (Seguridad de TI, Administración y Desarrolladores) cumplir con la diligencia debida y hacer su mejor esfuerzo para prevenir esto.

Si eres un desarrollador web, trabajando solo creando un sitio, decides qué tan aburrido será cuando alguien tenga su cuenta comprometida y culpe a tu sitio por no ser seguro.

Si trabajas en una empresa, a menos que estés en el gran comité que decide sobre seguridad, no debes preocuparte.

Si está a cargo (incluso parcialmente) de la seguridad, debe discutir que los usuarios son los únicos responsables de sus contraseñas, de la misma manera que los usuarios son responsables de no perder sus billeteras, o de no hacer un exterior con su banco. números de cuenta y contraseñas de pin. Pero ... culparán a su sitio si se utiliza su cuenta, y solo pensarán que la seguridad de las contraseñas es su responsabilidad. La filtración de Gawker fue un muy buen ejemplo de cómo la gente elige su contraseña de manera muy pobre.

La mejor idea que he leído hasta ahora, en una pregunta diferente, fue esta: (simplemente note que no parece que ningún sitio la esté usando):

• ponga un medidor de fuerza de contraseña en la contraseña. En lugar de usar la notación "débil - medio - bueno", haz que tenga más niveles, como 1-10 de medida

• indica (e implementa) una política que el usuario tendrá que cambiar la contraseña cada x días con esa fuerza. Si es muy bajo, indica que puede quedarse más tiempo con la contraseña si se fortaleció un poco más.

• si aún así elige una contraseña de baja calidad, haz que haga clic en cualquier verificación "Acepto".

El desarrollador, ya sea que sea tu culpa o no, te culparán cuando su cuenta se vea comprometida.

Quién es responsable es quién tendrá la culpa. Es una decisión de política, por lo que puede ser "cualquiera". Sin embargo, malas decisiones pueden suceder. Aquí hay algo para pensar:

• Los desarrolladores mismos no deben ser responsables de las decisiones de diseño, ya que esto significaría que cualquiera de ellos tomará las decisiones de diseño (en cuyo caso son diseñadores , una alternativa diferente). trabajo que pueden o no realizar en paralelo), o, peor aún, que se les culpe por los errores de otros (no es la mejor manera de mantener a sus desarrolladores cerca ...).

• No es posible medir la fuerza de una contraseña. La seguridad de la contraseña es una característica del proceso de generación de contraseña , no de la contraseña en sí. Hasta cierto punto, podría inferir algunos datos sobre ese proceso al observar muchas contraseñas elegidas por un usuario determinado, pero esto no es práctico. "Contadores de contraseñas" no dan resultados muy útiles; p.ej. este sitio calificará "BillClinton1992" en "100%", la puntuación más alta posible ... Ya que las comprobaciones de seguridad de las contraseñas no se pueden automatizar de manera confiable, no tiene sentido hacer que los diseñadores de software sean responsables de la seguridad de la contraseña.

• Lo que pueden hacer responsables a los diseñadores de aplicaciones es lo que pueden hacer, es decir, ofrecer formas de implementar políticas de contraseña . No deben descartar las políticas por sí mismas (es el trabajo de un arquitecto de seguridad), pero pueden implementar (o más bien, hacer que los desarrolladores implementen) algunas herramientas, como las restricciones de longitud de contraseña o los generadores de contraseña.

• Culpar a los usuarios es infructuoso. Para una seguridad de contraseña adecuada, los usuarios deben estar alistados; Usted no llegará a ninguna parte sin su cooperación. Pero los usuarios no son solo usuarios, también son seres humanos; como tales, no les gusta en absoluto ser dominados, y tienden a reaccionar adversamente a las restricciones. Si intenta imponer "reglas de contraseña estrictas" con una herramienta, entonces inventarán creativamente maneras de hacer frente a estas reglas, con un mínimo esfuerzo de su parte, y no necesariamente para el mejor en cuanto a seguridad. Por ejemplo, agregarán sistemáticamente "1A". a su contraseña (que de lo contrario es una palabra común en minúscula) para que pasen las pruebas de "necesitan dígitos, necesitan símbolos, necesitan letras en mayúsculas"). O anotarán las contraseñas, lo cual no es malo cuando lo hacen en un papel que guardan en su billetera, pero es bastante horrible cuando el papel es una nota adhesiva oculta debajo del teclado.

Una buena política es hacer cumplir la generación de contraseñas a través de una herramienta informática. Las computadoras son buenas para la aleatoriedad (siempre que usen /dev/urandom , por supuesto). La herramienta encarna el proceso de generación de contraseñas, para que pueda saber "qué tan seguras son" tales contraseñas. Dado que a los usuarios no les gustará el esfuerzo de recordar las contraseñas, infórmeles que pueden anotar la contraseña en piezas de papel (por ejemplo, tarjetas de visita), siempre que las guarden en un lugar seguro. De esa manera, los usuarios no son responsables de la contraseña Strength , pero son responsables de mantener la seguridad física de su billetera. Y, lo que es más importante, hacer saber que los usuarios que perdieron su contraseña no serán culpados porque lo que es peor que una contraseña robada es una contraseña robada no reportada . / p>

Incluso si prefiere la solución más tradicional de permitir que los usuarios elijan sus contraseñas, debería ofrecer un generador de contraseñas y promover su uso.

Para ayudar a los usuarios a recordar las contraseñas, pídales que escriban la contraseña diariamente. No muy a menudo: a nadie le gusta escribir una contraseña de 15 letras cada diez minutos. Pero si ingresan la contraseña cada mañana, la recordarán, y esto hará que sea más fácil forzar las contraseñas generadas automáticamente. Por favor, oh, por favor, no hacen obligatorios los cambios regulares de contraseña. Esto tiene beneficios de seguridad muy pequeños, pero también irrita a los usuarios y promueve el comportamiento de seguridad (por ejemplo, el uso compartido de contraseñas, que los usuarios tienden a proteger contra la pérdida de contraseñas por olvido).

Voy a afirmar que los desarrolladores de software no son no libres de responsabilidad en esta cuenta.

Si usted es el desarrollador, ¿parece justo afirmar que es al menos su responsabilidad de proporcionar un mechanism sólido para ¿Haciendo cumplir la política elegida por su cliente?

¿Cuál debería ser la política predeterminada para los clientes que no conocen? En otras palabras, ¿para la mayoría de sus clientes?

Seguramente el valor predeterminado no debería ser dejar el sistema abierto fuera de la caja.

I still veo casos en un historial bastante reciente (como en el día anterior) de, por ejemplo, proveedores de servidores de bases de datos que configuran al usuario administrador del sistema como "dba" y la contraseña a "sql" ?).

"Gran cosa, depende del cliente cambiar eso" ¿dices?

El problema es que tener ese tipo de nivel de seguridad predeterminado ridículo conduce directamente a al menos el producto de envío de algún ISV que no solo no cambia las credenciales predeterminadas, sino que confía en las débiles, bien conocidas credenciales predeterminadas, y para rematar, publica esa confianza en la documentación oficial de soporte del producto en tinta indeleble en blanco y negro.

Fácilmente podría nombrar múltiples productos, pero no lo haré. Solo confía en mí, es cierto. Solía ser cierto en el caso de SQL Server con su cuenta de usuario "sa" incorporada en aquellos días, pero Microsoft ha tenido ese agujero en la instalación reparada por un tiempo. Pero sigue siendo cierto en otros lugares.

Soy perfectamente consciente de los sistemas que se ejecutan en las empresas de todo el mundo ahora mismo , que contienen datos confidenciales de cualquier medida, con interfaces de aplicaciones que implementan controles de acceso en la aplicación que dan < fuerte> ilusión de cierta seguridad, pero que de hecho están completamente abiertas para un acceso administrativo completo a cualquier usuario con conocimientos vagos con una copia de Excel y acceso al manual de instalación del software, o cualquier pista sobre la base de datos back-end y una tendencia a experimentar.