Envoyer un mot de passe à distance ?

**bowoo** · 11/08/2015, 15h37

Salut à tous,

J'ai une problématique de mot de passe :

Comment envoyer à un utilisateur un mot de passe à distance ou par mail ?

Par exemple, je suis dans une agence A, mon utilisateur Toto dans une agence B.

Toto à oublié son mot de passe sur une application métier. Je le lui réinitialise, et lui indique un mdp temporaire. Il est forcé de le changer à sa prochaine utilisation. Mais comment le lui communiquer ?

En voyant un collègue le faire et lui transmettre par mail en clair (dans le corps du message avec 8106 destinataires), je me dit que ça ne fais vraiment pas propre !
On essaie de gérer un peu mieux le truc en faisant un fichier texte compressé contenant le mdp (un .txt compressé envoyé en pièce jointe du mail) mais bon ce n'est pas très satisfaisant et ça change les habitudes des utilisateurs

Connaitriez vous un outil (si possible open source) me permettant d'envoyer un mot de passe à distance ?
Je pensais à un service web, qui, par exemple, en reconnaissant le nom AD de l'utilisateur, lui dirait que son mdp est trucbidule ?

Merci de votre lecture

**Julien698** · 11/08/2015, 16h00

Salut,

Il y a plusieurs solutions,

Si c'est vraiment un problème ponctuel, je te conseille de lui téléphoner directement pour lui transmettre son mot de passe. Si c'est un problème récurrent et pour différents utilisateurs tu peux le chiffrer. Si tu utilises Outlook comme boite mail, tu as une option qui permet de chiffrer directement l'e-mail: tu peux aller voir ici https://support.office.com/fr-fr/art...rs=fr-FR&ad=FR . Sinon tu peux développer une petite UI où il pourra réinitialiser son mot de passe en fonction de son login.

**bowoo** · 11/08/2015, 16h40

Salut, merci de ta réponse !

Malheureusement, problème récurrent, impossible de le faire au tel
Pas possible non plus de chiffrer les mails, pas d'autorités de certif pour le moments, mais la solution est intéressante merci

Oui une petite UI pourrait être pas mal, mais je ne m'y connais très mal en dev ...
Alors s'il existait un outil qui pourrait par exemple héberger mon mdp crypté, et je donne à l'utilisateur un lien web : ça, ça serait cool

**cavo789** · 15/08/2015, 13h15

Bonjour

Va voir http://www.tools4noobs.com/online_tools/encrypt/ et, son équivalent, http://www.tools4noobs.com/online_tools/decrypt/

Tu peux faire plus direct, en choississant immédiatement la méthode dans l'URL : http://www.tools4noobs.com/online_tools/xtea_encrypt/ et http://www.tools4noobs.com/online_tools/xtea_decrypt/

Restera, juste, à communiquer l'URL de décryptage dans un mail et la clef utilisée et, dans un second email (voir via un autre canal (skype, facebook mail, ...)) le texte crypté.

Bonne journée.

**BufferBob** · 15/08/2015, 20h06

Envoyé par cavo789

Restera, juste, à communiquer (...) la clef

**gangsoleil** · 19/08/2015, 09h22

Envoyé par bowoo

héberger mon mdp crypté, et je donne à l'utilisateur un lien web : ça, ça serait cool

Quelle est la différence entre donner un mot de passe en clair d'une part, et donner un lien web sur une page qui contient le mot de passe crypté ?

Ton besoin est de transmettre une information sensible à une personne. Après, tu peux imaginer tout ce que tu veux, il faut bien que tu lui donnes à un moment un "secret" qu'il doit être le seul à connaitre. Envoie le mot de passe par mail, avec obligation de le changer dans un temps imparti, et tu obtiendras déjà un niveau de sécurité suffisant.

**BufferBob** · 19/08/2015, 09h50

l'idée de créer une petite UI est pas mal à mon sens, couplé avec le mail on retombe finalement sur un classique du genre :
on envoie par mail un lien unique permettant de réinitialiser le mot de passe, lequel lien a une durée de vie limitée dans le temps (en général ~1h), on enrobe le tout dans du https pour rassurer le client et on est pas mal on évite plusieurs écueils, dont le fait de transmettre un mot de passe en clair et qu'il reste stocké dans un mail que l'utilisateur n'effacera pas

**cavo789** · 20/08/2015, 08h25

Bonjour

Je vous trouve un peu sévère sur ce coup.

1. On envoie un email avec les données de connexion excepté le password.
2. Via un autre canal, on envoie un mdp crypté et une clef de décryptage avec le lien vers l'interface de décryptage.

Ainsi, un éventuel man-in-the-middle ne pourra pas intercepter l'ensemble des données de connexion (deux canaux) ni avoir un script automatisé de lecture/scan des emails puisqu'il y a una action manuelle à faire (se connecter sur l'interface web, introduire les données fournies et cliquer sur le bouton de décryptage) pour obtenir finalement le MDP.

Je trouve cela plutôt sécurisé moi. Maintenant, nous nous rejoingons tous : à un moment donné, il faut transmettre des données sensibles par email.

Votre idée d'obliger à changer le MDP oui, pourquoi pas mais reste que si quelqu'un a intercepté le MDP avant le client final, il aura pu s'introduire. Ok, cela sera visible puisque le MDP ne sera plus actif mais il aura pû s'introduire.

Couplons alors votre approche et celle que je proposais pour avoir quelque chose d'encore plus fort.

Bonne journée.

**BufferBob** · 20/08/2015, 11h44

Envoyé par cavo789

Je vous trouve un peu sévère sur ce coup.

possible

question d'habitude et de -manque de- recul peut-être, on est pas parfaits de toutes façons

un éventuel man-in-the-middle ne pourra pas intercepter l'ensemble des données de connexion (deux canaux)

bien sur que si

ni avoir un script automatisé de lecture/scan des emails puisqu'il y a una action manuelle à faire (se connecter sur l'interface web, introduire les données fournies et cliquer sur le bouton de décryptage) pour obtenir finalement le MDP.

le fait d'obliger l'utilisateur à changer de mdp, ça sous-entend 1) qu'on est pas en mesure de lui redonner son ancien mdp, normal vu qu'on ne le stocke pas, on ne stocke que son hash 2) qu'il est le seul à connaitre son mdp et que le niveau de sécurité de ce dernier lui incombe (légalement parlant c'est sans doute pas idiot)

tu dis on chiffre donc le nouveau mdp et on envoie le lien d'une part, et la clé de déchiffrement d'autre part, dans la continuité de ce que tu proposes, on pourrait chiffrer la clé de déchiffrement, avec un 2e lien et une 2e clé qu'on pourrait alors chiffrer elle aussi puisqu'après tout c'est toujours une donnée sensible assimilable à un mot de passe
tu sens que c'est un cercle sans fin et que ça n'a pas lieu d'être ?

le point critique dans ce que tu proposes, ce n'est pas le fait de chiffrer le mot de passe, c'est le fait que le lien ne soit pas valide éternellement, de telle sorte que si un pirate compromet la messagerie de l'utilisateur dans 3 jours, il ne pourra pas réutiliser le lien et la clé envoyés pour récupérer le nouveau mot de passe

la question d'éviter le man-in-the-middle se pose au moment de l'accès au lien donné par email (donc en HTTPS), si on imagine qu'il y a un MITM permanent sur la messagerie on parle de rien de toutes façons, la seule solution envisageable est que les mails soient chiffrés en asymétrique avec des clés vérifiées, autant dire que c'est pas la situation par défaut avec tous les clients, ou alors en guise de second canal il faut envisager de transmettre par la poste ou par téléphone, idem c'est pas tellement pratique, mais c'est safe...

alors il faut faire des compromis, tu as déjà perdu ton mdp sur un site xyz sur lequel tu es inscris ? ça se déroule comment/quelle est la procédure ?

**Neckara** · 20/08/2015, 15h16

Le problème n'est pas d'envoyer le mot de passe à l'utilisateur, mais de l'authentifier sans qu'il utilise son mot de passe.

On utilisait un couple login/mot de passe pour l'authentifier (ce qui a aussi ses limites) mais l'utilisateur a perdu son mot de passe. Comment donc authentifier l'utilisateur sans son mot de passe ?

Plusieurs solutions :

répondre à une question secrète ;
utiliser l'e-mail associé avec le compte ;
envoyer un e-mail en donnant quelques détails sur le compte (date de création, dernière connexion, etc.) ;
…

Mais quoiqu'il en soit, cette méthode permet de réinitialiser le mot de passe, c'est à dire contourner la protection offerte par le mot de passe. Il faudrait donc, idéalement, que le protocole de réinitialisation de mot de passe offre une sécurité supérieur au protocole d'authentification/connexion sinon on perdra en sécurité.

De là, on propose plusieurs solutions :

utiliser plusieurs canaux de communication (SMS/E-mail) car on considère qu'il est peu probable qu'une personne arrive a accéder à toutes ces données en même temps ;
utiliser des clés au lieu de mots de passes ;
utiliser un objet que possède l'utilisateur (ex. données dans une clé USB, générateur de mots de passes n'ayant une durée de vie que de quelques secondes, …)
…

Il n'y a pas de solution miracle, il faut juste chercher à authentifier au mieux ton utilisateur sans qu'il ai à fournir son mot de passe. Et si on veut entrer en mode paranoïde, rien que pour l'authentification/connexion, il n'existe aucune méthode parfaite pour le moment.

Juste un exemple, récupérer des clés RSA juste en regardant le champ électro-magnétique émis par le CPU. Un simple utilisateur ne peut rien y faire.
C'est d'ailleurs d'histoires de ce genre que les cartes bancaires font des calculs inutiles aléatoires pour brouiller les signaux et empêcher de retrouver les clés quand elles sont utilisées. Mais… et si ces signaux étaient pas tout à fait aléatoires ? Et si le constructeur était capable de les filtrer pour récupérer un signal "propre" ?
Bon, on peut publier les plans pour s'en assurer… et si le fabriquant ne respectaient pas tout à fait ces plans ?
Tester le matériel produit n'est pas trop possible, donc surveiller le fabriquant ? Laisser les espaces de productions ouvert au public ?
Mais puis-je me fier à mes sens ? N'y a-t-il pas moyen que par des diversions et illusions ils arrivent tout de même à cacher ce qu'ils veulent cacher ?
Et puis, il faut avoir des connaissances, et si tous les experts sont complices et ne disent rien ?

Et si les experts sont de bonne foi mais sont manipulé par l'appendice nouillesque du plat de spaghetti indétectable, qui orbite autours de la Terre ? Et si nous l'étions tous ?

Bref, on est obligé de s'arrêter à un moment et de faire confiance mais il ne faut pas non plus s'arrêter trop tôt ^^.

**cavo789** · 20/08/2015, 15h19

Bonjour

Envoyé par cavo789

Ainsi, un éventuel man-in-the-middle ne pourra pas intercepter l'ensemble des données de connexion (deux canaux).

Envoyé par BufferBob

bien sur que si.

Pour cela, le gars qui lit ma messagerie doit aussi lire p.ex. Skype sur lequel j'aurai envoyé le PWD crypté. Je parlais de deux canaux; je ne parlais pas de deux mails envoyé à trente secondes d'intervalle.
Cela peut être Skype ou un MP via FB ou un SMS ou ... Un second canal.

Envoyé par BufferBob

le fait d'obliger l'utilisateur à changer de mdp

Note : ce MDP pourrait être celui d'un compte FTP que tu as créé pour le gars; un type qui vient t'apporter un support temporaire parce que tu as un quelconque problème. Le gars se connecterait, apporte sa soluce puis te dis OK et toi tu désactives le compte. Je donne cet exemple pour dire : "le logiciel qui sera utilisé n'est pas forcément un appli web ni un CMS où l'utilisateur aura une interface de gestion". Dans le cas que je donne, le MDP pour le FTP, c'est toi qui l'a généré;

**BufferBob** · 21/08/2015, 00h12

Envoyé par cavo789

Pour cela, le gars qui lit ma messagerie doit aussi lire p.ex. Skype sur lequel j'aurai envoyé le PWD crypté. Je parlais de deux canaux; je ne parlais pas de deux mails envoyé à trente secondes d'intervalle.

oui, et tu parlais aussi de man-in-the-middle, donc l'attaquant peut potentiellement voir passer TOUT le trafic, et quand bien même Skype chiffre ses communications ça ne me semble pas un moyen très "pro" de faire transiter des données utilisateur

si certaines solutions ont été retenues plutôt que d'autres depuis des années dans le domaine de la sécurité c'est qu'il y a de bonnes raisons à cela, après on les comprend ou on ne les comprend pas, en revanche pour ma part je n'essaierais pas plus de t'en convaincre

**cavo789** · 22/08/2015, 10h02

Bonjour

Envoyé par BufferBob

en revanche pour ma part je n'essaierais pas plus de t'en convaincre

Dommage de conclure ainsi alors que la discussion ne me semblait pas mal partie... Les exemples que vous donnez, c'est pour une application qui gère les règles (durée de vie limitée du lien de réinitialisation, possibilité de changer son mot de passe soi-même, ...).

Au moment de répondre à cette question-ci, j'avais en tête un cas concret où cette "application" est un client FTP : quelqu'un doit envoyer à un autre un accès temporaire à son FTP; pour du support. Là, et je vous ai relu une fois de plus, vos propositions ne permettront pas d'arriver à la solution de 1. lui communiquer les données techniques pour la connexion 2. lui communiquer un mot de passe pour l'établir.

Ai-je mal compris vos propositions ?

Bonne journée.