¿Cómo puedo convencer a mi jefe de que almacenar contraseñas de terceros en texto simple es una mala idea?

¿Por qué es una idea terrible?

Al registrar las credenciales de inicio de sesión de otros, la empresa está asumiendo una responsabilidad . Dado que la compañía ahora es responsable de la malicia que podría ocurrir al usar esas credenciales, la compañía debe tomar medidas para minimizar el riesgo. Además, las compañías que interactúan con las suyas deben asumir la responsabilidad de confiar en usted, algo que puede perjudicar a las empresas si un incidente se hace público (como lo menciona symcbean)

El almacenamiento de contraseñas en texto sin formato (como usted sabe) no ofrece protección contra ese riesgo.

¿Qué es una mejor solución?

Como mencionaste en un comentario, lo que necesitas es algo así como un administrador de contraseñas . De hecho, lo que quieres es un administrador de contraseñas.

Dado que hay mucho margen de error cuando se trata de criptografía, sugiero usar un administrador de contraseñas establecido. Puede encontrar innumerables comparaciones en línea, pero al final, sus opciones incluyen las basadas en una GUI (como 1password, LastPass, keepass, etc.) o una basada en un cli para el acceso automático (como pase o a través de LastPass cli)

Sí, estás haciendo algo horriblemente mal. Que su empleador parezca que se especializa en el cumplimiento lo hace mucho, mucho peor. El negocio de la compañía se basa en una reputación de excelencia en el cumplimiento que usted está desobedeciendo activamente.

Desafortunadamente en todos los niveles de una organización, es difícil convencer a sus superiores de que lo que están haciendo actualmente es una mala idea. Si yo fuera usted, sugeriría que consideren cómo reaccionarían sus clientes si:

• se les dijo que usted almacena sus credenciales en texto simple (presumiblemente sin controles de liberación / auditoría sobre el uso)
• leyeron en el documento que otro cliente había sido comprometido como resultado de esta práctica

En cuanto a lo que sería un enfoque mejor ... realmente desea el enfoque correcto , equilibrando la confidencialidad, la integridad, la disponibilidad y el presupuesto. Hay productos comerciales y de código abierto que podrían ayudar con esto, pero necesitarían mucha más investigación y análisis de lo que sea apropiado para este foro.

No desea almacenar las contraseñas de los usuarios, ni siquiera en KeePass o algo similar.

• La información está oculta de forma predeterminada, pero aún se puede ver fácilmente
• Las contraseñas se comparten fácilmente, perdiendo la responsabilidad, es decir, ¿cómo sabes que fue el usuario y no alguien más que usa su cuenta?
• Si se actualiza una contraseña (por ejemplo, se descubre un agente incorrecto y desea evitar un mayor acceso), debe actualizarse en cualquier otro lugar donde se esté utilizando

Estas son algunas opciones, desglosadas por escenario:

1. Si los sistemas que está utilizando son propios y se mantienen activamente, puede solicitar una función de suplantación de identidad del usuario. Cada persona con acceso de administrador inicia sesión con su propia cuenta de administrador que puede cambiar a la cuenta de cualquier usuario básico sin tener que conocer su contraseña. De esta manera, usted tiene una mejor auditoría. Puede ver que no fue el usuario real el que realizó las acciones, sino el usuario administrador específico que falsificó al usuario. Esto lo protege tanto a usted como al usuario, ya que ninguno de los dos puede acusar al otro de malicia, a menos que se pueda probar que el usuario tenía la contraseña de administrador o que el administrador tenía la contraseña del usuario y estaba usando su cuenta directamente.

   • Solo tiene conocimiento de su propia contraseña y no puede descubrir la contraseña de ningún otro usuario, incluso si está amenazado (un buen esquema de hashing tarda cientos de años en romperse por contraseña, en promedio)
   • Usted solo es responsable de sus propias acciones, no de todos los demás
   • Si la contraseña de un usuario se actualiza, no te afecta porque no cambia la forma en que accedes a su cuenta

2. Si los sistemas son externos, es decir, de terceros, puede intentar negociar el mismo tipo de función de suplantación de identidad del usuario, teniendo en cuenta que esto puede ser una prioridad muy baja o incluso una prioridad para algunas empresas. , es decir, podría no suceder nunca, o podría suceder muy lentamente (piense en años).

3. Si los sistemas ya no se mantienen, no tienes suerte. Sus opciones son dejar de usarlas debido al riesgo, o seguir almacenando las contraseñas localmente y aceptando el riesgo.

Recuerda, no es una cuestión de si se producirá una infracción, sino cuando se producirá una infracción.

Sí, múltiples cosas. Almacenar contraseñas en texto plano es obviamente una mala idea. Encriptarlos es mejor, pero normalmente las contraseñas no se almacenan en absoluto. Un hash irreversible se almacena en su lugar.

Pero el problema más grande aquí es que usar una contraseña de usuario para completar formularios significa que no hay manera de saber quién hizo qué con estas contraseñas. Digamos que uno de los usuarios en su base de clientes hace algo incorrecto, incluso ilegal. Afirman que debe haber sido alguien de tu organización. ¿Puedes probar que no lo fue? Los usuarios saben que tienes acceso a las contraseñas, ¿verdad?

Y como se mencionó en las otras respuestas, es mucho más probable que los terceros puedan obtener estas credenciales y usarlas. Si esto sucede, su organización puede ser nuevamente el objetivo de la culpa.

Si yo fuera tú, te explicaría los riesgos a quien puedas escuchar. Si entiendo correctamente, estas credenciales son para sistemas de terceros. Idealmente, tendría cuentas en esos sistemas que son para sus usuarios internos. Si no puede hacer eso, debe intentar tener algún tipo de implementación que evite que las personas de su organización puedan ver las contraseñas y los registros cuando accedieron a cada sistema.

Si necesita iniciar sesión en una cuenta extranjera de otra persona, necesita su nombre de usuario y contraseña. No hay manera de evitar eso. No puede hacer hash o cifrar ¹ , necesita los valores simples.

Por supuesto que es una pesadilla, ya que los usuarios necesitan revelar sus credenciales a usted. Ellos confían en que no los estás abusando. Suponiendo que no está abusando de ellos intencionalmente (como venderlos en el mercado negro como parte de su modelo de negocio), debe evitar fugas. Eso incluye infracciones de datos en su infraestructura o administradores de base de datos que pueden acceder a ellos. Por lo tanto, la mejor práctica aquí sería no almacenarlas en absoluto . El negocio de su empresa es ayudar al usuario a completar formularios, no a proporcionar un servicio de administrador de contraseñas. Para " facilitar a los [usuarios] recordar " sus credenciales no son su trabajo.

Una solución podría ser escribir una extensión de navegador para que los usuarios la instalen. Ellos inician sesión en esas cuentas extranjeras, en su máquina, y su complemento hace su trabajo allí. Su servidor nunca entra en contacto con las credenciales. (Por supuesto, el usuario todavía debe confiar en la extensión para no espiarlos).

Si esa no es una opción y el trabajo, incluido el inicio de sesión, debe realizarse en su servidor, entonces no debe almacenar las credenciales del usuario. Simplemente reenvíelas al servicio de inicio de sesión extranjero y luego almacene solo el token de sesión que se utilizará con la API en su base de datos durante el tiempo que lo necesite. Si la base de datos está dañada, el atacante podría secuestrar las sesiones (lo que es peor), pero no obtiene la contraseña de texto simple. Haga que el usuario vuelva a proporcionar las credenciales si su servidor necesita iniciar sesión varias veces.

_{1: Por supuesto, debería cifrar siempre los datos confidenciales cuando los almacena en cualquier lugar, pero en última instancia, la clave debe residir en algún lugar de su servidor, a la que un presunto atacante podría acceder. acceso también.}

Los gerentes hablan el idioma de los negocios, no la tecnología.

Realice una estimación del riesgo que su empresa enfrenta con estas prácticas, expresada en moneda (USD, EUR, según corresponda). Hay varios métodos para hacer eso. Un buen enfoque es estimar un escenario realista y el peor de los casos. Decirle a un gerente que hay un 10% de probabilidad por año de un incidente de seguridad que podría costarle a la compañía hasta 5 millones de daños debería llamar su atención.

Además de los posibles daños ocasionados por reclamos contractuales en su contra por parte de las compañías de sus clientes, también debe considerar las responsabilidades civiles y penales causadas por negligencia grave. Una posibilidad de ir a la cárcel es otra cosa que tiende a atraer la atención del gerente.

Si su empresa cuenta con administración de riesgos, coordine con los empleados de allí con respecto a los métodos y estimaciones, siguiendo las prácticas corporativas hará que su enfoque sea más respetable.

La precaución mínima que debe tomar es usar un administrador de contraseñas u otro sistema que a) almacene las contraseñas cifradas yb) descifre solo la contraseña necesaria, cuando sea necesario.

Lo ideal sería pasar a un método basado en certificados, pero esto también depende de sus clientes y no está totalmente bajo su control.

También debe tener una política de manejo de contraseñas que documente cómo se manejan las contraseñas y contiene sanciones por violarlas. Los filtros de egreso podrían evitar un desastre por correo electrónico.

Sí, almacenar contraseñas de texto plano es una tontería. Incluso tuvimos un empleado que accidentalmente envió por correo electrónico todas sus contraseñas "almacenadas" a una lista de distribución interna en un accidente de copiar y pegar. Afortunadamente, no había clientes en la lista.

Así que pasamos a utilizar Teampass, que funciona realmente bien como una base de datos centralizada de información de contraseñas.

También permite grupos con diferentes niveles de acceso, y cada usuario puede tener su propio conjunto de contraseñas privadas almacenadas que nadie más puede leer.

Es una configuración de un administrador de contraseñas individual donde todos guardan una copia de las contraseñas localmente. Entonces, si la contraseña de un servicio se actualiza, todos verán esa actualización.

El historial también se mantiene, por lo que puede obtener las contraseñas anteriores para el servicio X (tal vez un host no se actualizó y necesita volver atrás en el tiempo)

enlace

Otro ángulo, excepto lo obvio (que ya sabe, como se muestra en la pregunta: almacenar las contraseñas no cifradas es incorrecto):

No compartir / dar contraseñas es o debería ser uno de los primeros puntos en cualquier directriz de seguridad. Ningún banco, servicio en línea o cualquier otra entidad que solicite una contraseña. Esto está arraigado en todos los usuarios, por buenas razones.

Si yo fuera tu cliente y tu empleador me pidiera una contraseña, no te la daría y b) correré a mi gerencia con bastante rapidez. Intentaría asegurarme de que no seamos su cliente en cualquier momento.

Ni siquiera le doy mi contraseña a mis propios compañeros de soporte (en el caso poco probable de que necesiten que inicie sesión por ellos durante una sesión de soporte, lo haré yo mismo). He estado en el extremo receptor de los controles de seguridad (para sistemas y / o aplicaciones) y nunca se ha pasado alguna cuenta de usuario real a la compañía de seguridad. Si necesitan iniciar sesión, obtienen sus propias cuentas temporales. Hice que los clientes intentaran decirme su contraseña y me aseguro de interrumpirlos de inmediato y hacer que escriban ellos mismos.

TL; DR: Siéntase libre de mostrarle a su gerencia esta respuesta: sería un cliente perdido para usted.

La mejor respuesta es no tener ni usar las credenciales de su cliente en absoluto. El hecho de solicitarlos a su cliente es una seguridad masiva, no, no, y debe mostrar señales de alerta para cualquier persona de sus clientes que tenga algún tipo de conocimiento de seguridad.

De hecho, yo diría que al hacer esto probablemente ya está perdiendo negocios entre clientes potenciales que tienen algún tipo de política de seguridad. Mi propio empleador tiene una política de contraseña estricta y es probable que se consideren motivos de despido para que comparta cualquiera de nuestras contraseñas con usted.

Otro factor realmente importante que nadie más ha tocado es la responsabilidad. Al compartir una contraseña con usted, el cliente se ha abierto a posibles problemas si alguna vez se utiliza mal la cuenta. Un empleado falso dentro de la empresa puede ser el culpable, pero si se ha compartido la contraseña, se abre una posibilidad de negación plausible. Pueden ponerle sospechas y hacer que la investigación sea mucho más difícil.

Pero necesita iniciar sesión en este sitio remoto para ver qué están haciendo para poder verificar su cumplimiento, entonces, ¿cómo puede evitar eso sin tener sus contraseñas?

Hay una serie de opciones aquí. Todos requerirán más trabajo del que estás haciendo ahora, pero tendrás que aceptarlo.

1. Averigüe si el sitio remoto ofrece suplantación de cuentas o cuentas multiusuario. De ser así, debería poder acceder a la misma información sin necesidad de utilizar las mismas credenciales. El proveedor del sitio o el cliente deben configurar un conjunto adicional de credenciales solo para usted con acceso para ver los datos del cliente en el sitio. Este inicio de sesión sería diferente del inicio de sesión principal del cliente y la contraseña para el inicio de sesión sería solo suya, por lo que no habría problemas de almacenamiento. Lo ideal sería que esta cuenta para usted hubiera reducido los permisos de solo lectura, para minimizar cualquier riesgo de responsabilidad para usted.

2. Discuta con el proveedor del sitio remoto la posibilidad de que le proporcionen una copia fuera de línea de los datos relevantes. Esto puede ser en la forma de un volcado de base de datos o una API o un archivo de registro; sea lo que sea, no implica que deba iniciar sesión en la cuenta del cliente; simplemente puede solicitar la última copia de los datos del sitio y revisarla para averiguar qué desea saber. Obviamente, esto tendría que acordarse con el cliente, y si el proveedor del sitio no tiene estas instalaciones disponibles, es posible que le cobren por el trabajo para crearlas, pero le daría acceso completo a lo que necesita, mientras permanece aislado. de tener que iniciar sesión en el sitio real.

La FTC ha ido tras las compañías por tales malas prácticas ( vea las secciones 3 & 4 ), litigando contra ellos financieramente y públicamente avergonzándolos.

La FTC también tiene la Regla de salvaguardias que da alguna orientación (algunas prácticas técnicas de alto nivel, pero en su mayoría procedimientos). Aunque se refiere a organizaciones financieras, su definición es bastante amplia, en cualquier caso, es un buen punto de partida.