Connexion pour webapp, doit être disponible pour le personnel de soutien

Question

Je sais que le titre est un peu éteint, mais il est difficile d'expliquer le problème dans une courte phrase. Je suis l'administrateur d'une application Web héritée qui permet aux utilisateurs de créer des sondages et de les distribuer à un groupe de personnes. Nous avons deux types d '"utilisateurs".

1. Les détenteurs de licence autorisés qui se configurent tous eux-mêmes.
2. Les clients qui veulent juste avoir une course d'enquête, mais ont encore besoin d'un utilisateur (parce que le webapp a « Utilisateur » comme l'entité supérieure dans un surveyenvironment.)

Parfois, les utilisateurs # 1 veulent que nous fassions la configuration pour eux (que nous proposons de faire). Cela signifie que nous devons nous connecter comme eux. C'est aussi la façon dont nous soutenons: nous nous identifions comme eux, puis les suivons, les guidant.

Ce qui m'amène à mon dilemme. Actuellement, notre sécurité est inférieure à la normale. Mais cela nous facilite la tâche. Nous voulons augmenter notre sécurité, et une chose que je considère est de faire le hachage normal à DB, cependant, nous devons pouvoir nous connecter en tant que client, et s'ils changent leur mot de passe sans nous le dire, et le mot de passe est haché dans le db, nous n'avons aucun moyen de le savoir. Donc, je pensais à une sorte de cryptage à deux voies pour les mots de passe. Soit ça ou une sorte de mot de passe principal.

Des suggestions?

(La plate-forme est ASP classique ... Je l'ai dit était héritage ...)

Answer 1

sonne comme vous voulez découpler votre authentification de votre identité un peu. Peut-être que quelque chose comme un administrateur surcharger la page, de sorte qu'après vous être connecté en tant qu'administrateur, vous avez le choix de l'identité de l'utilisateur que vous souhaitez assumer. Après avoir sélectionné une identité, vous continuez à utiliser l'application sans autre authentification.

Answer 2

Ce que je voudrais faire est de laisser le personnel de support se connecter avec leur nom d'utilisateur/mot de passe mais de choisir un utilisateur pour "usurper l'identité". Donc, dans votre session, vous aurez:

1. logged_user - l'utilisateur réel qui a tapé dans son/son nom d'utilisateur et mot de passe
2. utilisateur personnifié - l'utilisateur (1) est agissant au nom de

Tout ce que vous faites est fait avec les permissions et les préférences de impersonated_user. Si vous n'êtes pas usurper l'identité de quelqu'un impersonated_user=logged_user. De cette façon, vous devez toujours enregistrer toute opération avec le nom d'utilisateur "réel" et le nom d'utilisateur "usurpé"; par exemple:

2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie' 

Answer 3

Les deux options que vous présentez ne me semblent pas attrayantes.

• Un mot de passe maître est sans doute encore plus dangereux que ce que vous faites des mots de passe en ce moment

• (Encrypting au lieu de hash) dans la base de données ne suffit pas bon non plus l'OMI, car il ne prend que une pause -de votre côté pour obtenir tous les mots de passe. Ils devraient vraiment être hachés.

Je suppose que le produit, étant une ancienne application héritée, est impossible (ou non économique) pour changer d'une manière que les comptes d'administrateur peuvent usurper l'identité des comptes d'utilisateurs, qui à mon avis est toujours la meilleure approche à ce dans un scénario réel (pas tout le monde partage cette opinion, discussion sur la question here).

Que diriez-vous d'introduire une deuxième colonne de mot de passe (password2) contenant un mot de passe haché que vous entrez? Le processus de connexion de l'application peut être facile à modifier dans une deuxième colonne. Il peut être facile à implémenter, et je ne vois pas de problèmes de sécurité supplémentaires (corrigez-moi si je me trompe bien sur.)

Answer 4

J'aime la solution proposée par Manrico Corazzi. Cela m'a rappelé que lorsque vous avez besoin de l'assistance de Microsoft, il est possible de confier le contrôle de votre machine à un technicien. Cela pourrait être une autre façon de réaliser le mécanisme d'usurpation d'identité. Pour qu'un compte d'administrateur puisse se connecter, un licencié autorisé devrait explicitement lui permettre de rejoindre sa session et d'agir avec tous ses privilèges.