security - top - ¿Cómo se admite una aplicación web con contraseñas cifradas o cifradas?
session management (7)
¿Podría tener un entorno de prueba donde se copia un corte regular de datos en vivo (obviamente desinfectado para resolver cualquier problema de seguridad o protección de datos)? Un usuario similar en la configuración a la que tiene problemas podría ser utilizado para solucionar problemas o, de hecho, el mismo usuario, si esto está permitido.
Use un cliente de escritorio remoto como se menciona en otras respuestas, pero nuevamente esto puede no ser práctico para usted. Si tiene estos derechos dentro del dominio, he escuchado sobre el manejo de errores incluso haciendo un screencrape e incluyendo esto en los registros. pero esto me suena un poco extraño.
¿Podría tener una herramienta de administración para clonar a un usuario en una cuenta demo?
Al admitir una nueva aplicación web en un entorno empresarial, a menudo es necesario iniciar sesión como un usuario específico para diagnosticar un problema real o percibido que está teniendo. Dos problemas opuestos se aplican aquí:
La mejor práctica es usar contraseñas cifradas o cifradas , no texto claro. A veces, hay un SSO de terceros (inicio de sesión único) en el medio. No hay forma de recuperar la contraseña del usuario. A menos que el usuario lo proporcione (no recomendado), no hay forma de iniciar sesión como ese usuario.
Muchas aplicaciones web tienen personalización y autorización compleja . Diferentes usuarios tienen diferentes roles (administrador, administrador, usuario) con diferentes permisos. En ocasiones, los usuarios solo pueden ver sus datos: sus clientes o tareas. Algunos usuarios tienen acceso de solo lectura, mientras que otros pueden editar. Entonces, la vista de cada usuario de la aplicación web es única.
Suponga que en un entorno empresarial, no es factible ir al escritorio del usuario o conectarse directamente a su máquina.
¿Cómo manejas esta situación?
Editar: Quiero reiterar que en una gran institución financiera o una compañía típica de Fortune 500 con cientos de miles de empleados en todo el país y en todo el mundo, no es posible que un simple desarrollador en alguna unidad de TI pueda hacerlo directamente. acceder a la máquina de un usuario Algunas de ellas son aplicaciones web de uso público utilizadas por los clientes (como la banca en línea y el comercio de acciones). Y, muchas de esas aplicaciones de intranet dependen de Active Directory o SSO, lo que significa que las credenciales de los usuarios son las mismas para muchas aplicaciones. Les agradezco a todos por sus sugerencias; algunos pueden ser muy útiles en otros tipos de entornos.
Para nuestras aplicaciones web utilizamos un proceso que, por falta de un término mejor, se define como ''secuestro'' de la cuenta de un usuario.
Básicamente, los administradores pueden ''secuestrar'' la cuenta de un usuario con un simple clic de botón. En el código, simplemente usa un identificador único (el ID de usuario funciona en un entorno menos seguro) que luego establece las credenciales necesarias en la sesión para que luego puedan funcionar dentro del perfil de ese usuario. Para un entorno más seguro, puede usar un hash único para cada usuario.
Para garantizar que este método de secuestro sea seguro, siempre primero se verifica que la solicitud la realiza un administrador autenticado con los derechos apropiados. Debido a esto, es necesario secuestrar la sesión del administrador o capturar sus credenciales de autenticación para que alguien pueda explotar la función de secuestro dentro de la aplicación.
Por lo general, mediante algún tipo de software de control remoto que se puede utilizar para ver su escritorio. Si están en un servidor de terminal de Windows, entonces las herramientas de administración integradas se pueden usar para eso. De lo contrario, usaría algo como VNC en una red interna o un servicio externo como LogMeIn ( http://www.logmein.com/ ).
Tenía 4 ideas Mientras escribía, 3 de ellos ya fueron sugeridos (así que los subí)
Variante de la idea 3 - suplantación:
Para hacer esto lo más "idéntico posible" a un inicio de sesión normal con cambios mínimos de código, puede agregar la capacidad de suplantar directamente al iniciar sesión proporcionando credenciales de administrador más un nombre de usuario alternativo, por ejemplo, iniciar sesión como administrador: usuario, contraseña de administrador. El sistema trataría esto exactamente como iniciar sesión como usuario con userpassword.
Idea 4: ¿Puede acceder a la tienda de contraseñas? Si es así, reemplace temporalmente el hash del usuario con el hash de una contraseña conocida. (las contraseñas a menudo se almacenan en línea en una base de datos. Una herramienta de consulta SQL puede hacer los intercambios)
Un administrador debería poder cambiar la contraseña de un usuario. Cambia la contraseña para el usuario a algo que sabes. Luego puede iniciar sesión como ese usuario.
Dígale al usuario que restablezca su contraseña después de que haya terminado la depuración.
Varias de estas ideas son un inconveniente para el usuario, ya sea forzándolo a cambiar su contraseña u ocupando su escritorio para su sesión de depuración.
La idea de Markc es la mejor: aumente su lógica de autenticación para permitir que los superusuarios inicien sesión como un usuario en particular al proporcionar no las credenciales del usuario, sino el nombre del usuario más sus credenciales de superusuario.
Lo he hecho así en el pasado (python pseudo-ish):
if is_user_authenticated(username, userpassword):
login the user
else if '':'' in userpassword:
supername, superpassword = userpassword.split('':'')
if is_superuser_authenticated(supername, superpassword):
login the user
En otras palabras, si el nombre de usuario y la contraseña no se autentican, si la contraseña tiene dos puntos, entonces es en realidad el nombre de usuario administrador y la contraseña de administrador unidas por dos puntos, así que inicie sesión como nombre de usuario si es el nombre de usuario y contraseña correctos.
Esto significa que puede iniciar sesión como usuario sin conocer sus secretos y sin molestarlos.
La solución que hemos utilizado en nuestras aplicaciones web es hacer que authN / authZ devuelva el usuario deseado como usuario efectivo. Hacemos esto al tener una función de administrador para configurar un enmascaramiento, y luego cuando solicitamos el usuario actualmente conectado (usuario_actual), manejamos el enmascaramiento:
def current_user_with_effective_user
if masked?
current_user_without_effective_user.masquerade_as
else
current_user_without_effective_user
end
end
alias_method_chain, :current_user, :effective_user