¿Es una mala práctica de seguridad tener una contraseña que le permita acceder a cualquier cuenta de usuario en un sitio web con fines de asistencia? La contraseña se almacenaría de forma segura y sería muy compleja. ¿Gran error?
¿Es una mala práctica de seguridad tener una contraseña que le permita acceder a cualquier cuenta de usuario en un sitio web con fines de asistencia? La contraseña se almacenaría de forma segura y sería muy compleja. ¿Gran error?
Esto suena muy parecido a una cuenta de "Administrador", que normalmente tiene acceso ilimitado a las cosas de las que es administrador.
Las implicaciones de seguridad de una cuenta de administrador son bastante bien entendidas, al igual que las mejores prácticas. No voy a entrar en todos los detalles, pero su implementación se rompe con las mejores prácticas en una característica clave: trazabilidad.
Desea poder decir quién hizo qué, especialmente cuando se trata de administradores. Si un administrador puede iniciar sesión en mi cuenta con su contraseña, no hay forma de que un auditor después del hecho determine lo que yo hice frente a lo que hizo el administrador.
Pero si, en cambio, el administrador inicia sesión en su cuenta PROPIA con su contraseña super segura, entonces, a través del acceso que tiene a través de su propia cuenta, realiza alguna acción que podría haber hecho también. Bueno, ahora podemos tener un registro. diciendo quién hizo qué. Esto es bastante clave cuando el estiércol golpea el ventilador. Y más aún cuando una de las cuentas de administrador se ve comprometida (lo que lo hará , a pesar de sus mejores esfuerzos).
Además, diga que el negocio crece y que necesita 2 administradores. ¿Comparten la contraseña superawesome? NO NO NO. Ambos obtienen sus propias cuentas de administrador, con seguimiento y registro separados y todo eso. Ahora puedes decir QUÉ administrador hizo qué. Y, lo más importante, puede cerrar una de las cuentas cuando despida a uno de los administradores por robar las donas.
Hay mucha información excelente en las respuestas dadas hasta ahora que el póster original debe leerse y tomarse en serio. Sin embargo, creo que la mayoría de las respuestas no captan el espíritu de la pregunta, ya que se relaciona con el sitio web de su empresa "como si fueran los usuarios" con fines de soporte. El corazón de la pregunta parece ser que esta actividad se produce en la parte delantera de un sitio web en lugar de en la consola de un servidor.
Sé de una compañía que tiene esta misma necesidad en su aplicación web y ya la resolvió de una manera que creo que es el tipo de solución que buscaba el póster original.
Crearon un sistema de "enmascaramiento" en su aplicación web que permite a un empleado de un grupo especial ingresar un conjunto de páginas que pueden buscar cualquier usuario en el sistema y seleccionar a ese usuario como las credenciales para navegar por el sistema. Hace un seguimiento del usuario seleccionado para enmascararse como y el usuario empleado real como dos entidades separadas y simultáneas que se registran en todo momento y para cada acción.
Desde la perspectiva de la aplicación, se trata de "tratarme como este usuario, pero recuerde que en realidad soy este otro usuario". Tipo de versión de su aplicación web, pero incorporada en el front-end.
Este método:
Sí, es un error. ¿Qué sucede si el atacante logra obtener esta contraseña, sin importar qué tan seguro pienses que es? Él podrá manipular la información de la cuenta de usuario de una manera que probablemente sea difícil de diferenciar de la actividad normal.
Si controla el sitio web, ya tiene muchos métodos diferentes disponibles para la opción de soporte. Se pueden escribir herramientas administrativas adecuadas para leer y modificar la información necesaria. No tiene mucho sentido tener una contraseña "maestra".
Esta contraseña de "dios" es el equivalente de acceso de administrador / raíz: puede hacer todo. La pregunta es doble:
¿Es una buena idea tener algún tipo de acceso al tipo "puedo hacer todo"? En la práctica, es más "inevitable" que "bueno", pero sí, es algo normal. Sin embargo, asegúrese de tener procedimientos de uso apropiados: no desea que los administradores se encarguen de la administración de una máquina compartida en una cafetería; y quieres saber "quién lo sabe". En ese sentido, cuando hay dos o más personas con privilegios de administrador, es mejor si actúan "como ellos mismos" como miembros de un grupo de administradores (en el mundo de Unix, use sudo para que los comandos se registran).
¿Es una buena idea hacer que los administradores ejerzan sus privilegios a través de la API de usuario normal ? Este es discutible. Permitir una "contraseña de Dios" significa instalar la "excepción de Dios" en toda la aplicación, lo que corre el riesgo de que se abuse de ella. Aumenta la complejidad del sistema de autenticación + autorización en su sitio, y la complejidad es lo único que desea evitar en la seguridad. Los insectos crecen en la complejidad. Una "contraseña de Dios" puede ser conveniente durante el desarrollo, pero, en general, tiende a aumentar la probabilidad de un agujero de seguridad devastador, así que utilícelo con extrema precaución.
Por supuesto, el contexto lo es todo, y las respuestas anteriores simplemente se aplican generalmente . Sin embargo, desconfíe de las puertas traseras administrativas, en particular las puertas traseras que no mantienen un buen registro del origen de las solicitudes administrativas.
Un administrador aún puede actuar solo como él mismo: alguien con una contraseña de dios puede hacerse pasar por cualquier persona en el sistema. Se podría argumentar que si el Administrador tiene suficiente poder, esto no hace mucho para limitar el daño real que un atacante con esa cuenta podría hacer. Pero un atacante con la contraseña de dios tendría un tiempo mucho más fácil para cubrir sus huellas.
Tener una contraseña de "dios" es una solución simple, pero es simplemente una "autorización" para conocer la contraseña maestra, y no se presta para una buena gestión de acceso (es decir, controlar quién puede hacerlo), ni la responsabilidad (¿Quién realmente hizo qué?).
En cambio, cambie la estructura de datos de sus credenciales para tener un campo de usuario efectivo:
{
user: alice,
effective_user: bob,
}
El contenido de sus páginas web debe representarse para el effective_user , a menos que sea una página administrativa interna que necesite saber quién está realmente navegando. Tenga en cuenta que la mayoría de las personas externas que navegan por su sitio siempre tendrán la misma ID para ambos campos:
{
user: alice,
effective_user: alice,
}
Este acuerdo le permite controlar mejor quién puede convertirse en otro usuario y también le permite registrar / auditar quién hizo qué en nombre de quién. (Puede simplemente registrar tanto al usuario como a eficaz_user en las cosas que le interesa ver). Unix hace este tipo de cosa efectiva de usuario (y grupo) internamente si observa las fuentes para lo que define un proceso. Imitar esto en la web es aprovechar un paradigma conocido y exitoso.
Esta solución también le permite elegir las páginas que su personal puede "mirar por encima del hombro" de otro usuario. Puede elegir escribir una página que no se muestre según el effective_user , entonces su personal no podrá ver nada de esa página, incluso si tienen el privilegio de cambiar su identificación de usuario efectiva.
Por cierto, he implementado el concepto de usuario efectivo en la web, y también he implementado la contraseña de dios. Este último es fácil de instalar cuando toda la infraestructura ya está instalada. Pero realmente no es la mejor solución en términos de saber quién hizo qué y administrar el acceso. Eche un vistazo de cerca a la cantidad de refactorización realmente involucrada para agregar el campo de usuario efectivo: puede ser menos de lo que cree.
Nunca te haces pasar por el usuario. (Por diversos motivos de capacidad de rastreo / responsabilidad como otros ya mencionados.)
En cambio, usted ve una copia de la pantalla de la pantalla del usuario como si estuviera parado detrás de ellos mirando por encima del hombro.
Para eso están las herramientas de compartir pantalla / escritorio como VNC, TeamViewer, Asistencia remota, etc.
Si solo una persona tiene acceso, entonces no es necesariamente un problema, sin embargo, se puede hacer con la misma facilidad a través de una configuración para una cuenta de usuario que permita este acceso.
Con cualquier tipo de funcionalidad de root / superusuario / administrador, el registro y la auditoría del comportamiento son críticos, y eso significa que necesita saber quién estaba haciendo qué. Si varios usuarios necesitan poder realizar cambios como este, entonces debería haber una marca en su cuenta para permitirlo.
Es posible que aún desee tener una contraseña adicional y más complicada que deba ingresarse incluso cuando tengan acceso, pero debe requerir la autenticación segura de una persona que realiza cambios antes de hacer algo de esta naturaleza.
Puede que no tenga más remedio que tener una contraseña de 'dios'. Independientemente de lo que dijo Tylerl acerca de tener dos contraseñas de administrador diferentes, ¿cómo sería posible tener un registro y un rastreo a menos que alguien también se encargara de eso? Literalmente, tendrías que cifrar el registro y todo contra ti de tal manera que se lea solo al mundo exterior pero que aún pueda escribir por sí mismo. ¿Cómo determina si la información que está recibiendo es legítima o no? Obviamente, si no tiene acceso, entonces nadie lo tiene, por lo que tampoco funcionaría.
Creo que necesitas tener seguridad basada en roles en lugar de una cuenta con habilidades de modo "dios". De esta manera, puede tener varias personas que tienen los mismos roles con capacidades similares, de modo que si su dios / administrador no está disponible, alguien más puede hacer una corrección.
Sé que se prefiere especialmente si va a ser auditado.
Lea otras preguntas en las etiquetas web-application passwords