J'utilise couramment un gestionnaire de mots de passe pour stocker et partager des mots de passe. Il existe de nombreux gestionnaires de mots de passe qui ont cette fonctionnalité.

Un mot de passe est partagé d'un compte à l'autre, la notification du partage étant envoyée par e-mail à l'autre personne, qui peut choisir d'accepter, de refuser, ou ignorez simplement le partage. La communication du mot de passe est sécurisée, tandis que la notification du partage circule sur des canaux moins sécurisés comme le courrier électronique, utilisant ainsi la force de chaque méthode sans compromettre la sécurité. Certains produits permettront le partage du mot de passe sans divulguer le mot de passe au destinataire. Dans ce cas, la révocation du mot de passe devient possible.

Je recommande vivement d'utiliser un gestionnaire de mots de passe pour tous vos mots de passe. Certains commerciaux sont LastPass, 1Password ou Dashlane mais il y a aussi la possibilité d'en héberger un vous-même si vous ne voulez faire confiance à personne. Une recherche rapide sur Google du "gestionnaire de mots de passe" devrait vous mettre sur la bonne voie.

Une pratique courante consiste à envoyer à l'utilisateur un mot de passe initial par e-mail qui n'est valable que pour une très courte période et doit être changé immédiatement lors de la première connexion.

Ce n'est pas parfait non plus. Un attaquant disposant d'un accès en lecture au courrier électronique de l'utilisateur pourrait intercepter ce mot de passe initial avant l'utilisateur et l'utiliser en son nom. L'utilisateur le remarquera dès qu'il essaiera d'utiliser son mot de passe initial. Ils informeraient l'administrateur que le mot de passe est incorrect, l'administrateur enquêterait et remarquerait l'accès illégitime. Mais l'attaquant a déjà eu un certain temps pour accéder au compte, il peut donc déjà y avoir des dommages. Mais c'est toujours mieux que d'envoyer un mot de passe valide en permanence.

Il faut également que le système prenne en charge cela. Ce n'est donc pas une pratique universellement applicable.

Lorsque vous ne faites pas confiance à votre fournisseur de messagerie pour garder vos e-mails secrets (vous utilisez gmail, un service de messagerie financé par l'exploration de données le contenu de votre e-mail et la monétisation des résultats), puis le cryptage des e-mails est une option. Il y a le bon vieux PGP, le PEP plus moderne, le standard IETF S / MIME ainsi que quelques solutions propriétaires non standardisées. C'est la bonne chose à propos des normes: il y en a tellement de choix! Mais ils ont tous une chose en commun: ils ne comprennent tout simplement pas. Faire en sorte que vos partenaires commerciaux chiffrent leurs e-mails selon un schéma que vous comprenez peut être une tâche ardue.

Deux facteurs

Ce n'est peut-être pas littéralement adapté à votre situation, mais un moyen raisonnable d'envoyer des données sensibles sur des canaux qui ne sont pas entièrement sécurisés consiste à s'assurer que deux facteurs distincts sont nécessaires pour accéder à ces données et qu'ils soient envoyés sur différents canaux. Par exemple, j'ai vu des approches où les données sont envoyées par e-mail dans un fichier zip crypté, et le mot de passe de ces données est envoyé par SMS. De cette manière, ni une personne disposant de cet e-mail ni une personne ayant accès à votre téléphone ne peuvent accéder aux informations sensibles.

De la même manière, il pourrait être préférable d'envoyer les informations de connexion par e-mail et le mot de passe peut être dit au téléphone (surtout si c'est comme une phrase de passe) - mais ce choix appartient principalement à l'organisation envoyant les données (qui est censée être la partie prenante qui a besoin que ces données restent confidentielles ), pas à quelqu'un qui vient de le recevoir.

Si vous lui faites confiance, onetimesecret (qui est open source) existe exactement dans ce but.

Lorsque vous envoyez des personnes sensibles des informations comme les mots de passe et les liens privés par e-mail ou par chat, il existe des copies de ces informations stockées dans de nombreux endroits. Si vous utilisez un lien unique à la place, les informations persistent pour une seule visualisation, ce qui signifie qu'elles ne pourront pas être lues par quelqu'un d'autre plus tard. Cela vous permet d'envoyer des informations sensibles de manière sûre en sachant qu'elles ne sont vues que par une seule personne. Pensez-y comme un message autodestructeur.

Le courrier électronique n'est pas un bon mécanisme pour partager des mots de passe en texte clair étant donné sa nature intrinsèquement non chiffrée.

Si les mots de passe sont partagés de cette manière, le service doit s'assurer que le mot de passe est changé lors de la première connexion pour réduire exposition (et pour vous permettre de détecter si quelqu'un a utilisé le mot de passe volé), pas une option parfaite car elle permet toujours à quelqu'un de profiter de la fenêtre d'opportunité pour accéder au site mais c'est mieux que de ne pas savoir que quelqu'un d'autre a le mot de passe .

Comme cela ne semble pas être une option pour vous compte tenu de votre réponse au commentaire de schroeder, je vous suggère de regarder un mécanisme qui garantit le cryptage du mot de passe tout le chemin entre votre client et vous-même - soit par chiffrement de bout en bout du contenu des e-mails ou à l'aide d'un site de partage authentifié et chiffré sur lequel les mots de passe en clair peuvent être chiffrés. Pensez également que si vous êtes vraiment à l'aise avec d'autres personnes (votre client, les autres membres de votre équipe) connaissant votre mot de passe, cela dépendrait des exigences de sécurité de l'application à laquelle vous accédez.

Le principal risque serait ici soyez qui, en dehors de vous, connaît le mot de passe. Dans votre cas, ce serait au moins:

• La personne de votre organisation cliente qui a généré le mot de passe et qui vous l'a envoyé par e-mail
• Toute personne gérant un e-mail infrastructure entre votre client et vous
• Toute personne ayant accès au réseau dans l'un des chemins de messagerie entre votre client et vous
• Les autres membres de l'équipe qui travaillent avec le même compte et le même mot de passe (déduit de votre réponse au commentaire de schroeder)
• Toute personne pouvant avoir accès à votre boîte aux lettres (par exemple, votre commentaire sur le fait de laisser votre client de messagerie sans surveillance)

Si le seul objectif du mot de passe est d'éviter tout accès non autorisé aux services B2B et que vous êtes à l'aise avec d'autres personnes connaissant votre mot de passe, vous pouvez regarder le chiffrement pour la distribution du mot de passe. Alors que de nombreux serveurs SMTP implémentent le cryptage pour le transfert de données entre les sauts de serveur de messagerie, il n'y a pas de garantie de cryptage, et les courriers électroniques ne sont pas cryptés par nature, de sorte que le mot de passe résidera en texte brut au moins pendant son traitement à chacun des sauts de transfert de courrier (SMTP).

Cela signifie que vous devez examiner le chiffrement de bout en bout pour vous assurer que le mot de passe n'est pas disponible pour quiconque espionne, comme PGP, S / MIME ou une autre technologie propriétaire de chiffrement asymétrique. Celles-ci garantiraient la confidentialité du mot de passe pendant le transit, et vous pouvez toujours utiliser l'e-mail pour sa distribution - avec le compromis d'une configuration difficile et des coûts opérationnels.

Vous pourriez faire des compromis et utiliser quelque chose comme un chiffré Fichier ZIP ou document Office avec un mot de passe de cryptage prédéfini qui est partagé via un canal sécurisé (par exemple, un appel téléphonique), ce qui réduira à la fois la surcharge opérationnelle et la protection du mot de passe. De même, un fichier hébergé dans le cloud avec les mots de passe et protégé par un secret partagé en toute sécurité aurait les mêmes avantages / inconvénients.

Je ne comprends pas pourquoi vous leur envoyez les mots de passe?

Les clients définissent leur mot de passe préféré, vous le hachez, stockez le hachage, et personne à part le client / son programme de gestion de mots de passe ne le sait le mot de passe d'origine (pas même vous), et quand ils l'oublient, vous leur envoyez un lien de réinitialisation.

Cependant si vous devez vraiment lui envoyer le mot de passe, je vous suggère de lui envoyer un lien pour générer dynamiquement page Web qui affiche son mot de passe (pour 1 fois seulement).

vous devez temporairement stocker quelque chose comme ça dans votre base de données

  emailTocken char (32) password varchar + - -------------------------------- + ----------------- - + | emailTocken | mot de passe | + ---------------------------------- + -------------- ---- + | 202CB962AC59075B964B07152D234B70 | jhds7ytht_id | | CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874 # | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5) | | 2510C39011C5BE704182423E3A695E91 | 6 # hdyd98_jee | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e | + ---------------------------------- + -------------- ---- +  

et lui envoyer un email que vous exposez uniquement l'emailTocken pas le mot de passe

  Bonjour, client Suivez ce lien pour voir votre mot de passe https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543

sur le serveur Web lorsque quelqu'un demande ce lien, procédez comme suit

1. sélectionnez le mot de passe qui a le emailTocken fourni
2. supprimer son enregistrement de la base de données

Le premier qui demande ce lien verra quelque chose comme

  Bonjour client, votre mot de passe client est yeheb8cvddt5) REMARQUE: NOUS SUPPRIMERONS CE MOT DE PASSE DE NOS SERVEURS, VOUS DEVEZ VOUS RAPPELER / LE SAUVEGARDER  

Si quelqu'un demande plus tard le même lien, il verra quelque chose comme

  Désolé, ce mot de passe n'existe pas ou a déjà été consulté!  

Avantages de cette approche par rapport à l'envoi du mot de passe par e-mail:

1. le mot de passe n'est exposé qu'une seule fois pour le premier spectateur, pas pour celui qui verra l'e-mail plus tard .
2. si quelqu'un d'autre a d'abord consulté le mot de passe (un homme du milieu), l'utilisateur légitime ne pourra pas le voir et demandera de l'aide, ce qui nous fera savoir qu'il y a quelque chose de mal s'est produit, mieux que quelqu'un d'autre le voit, et nous ne savons même pas. J'espère que votre programme d'agent de messagerie ne le demandera pas automatiquement pour quelque raison que ce soit :( .

inconvénients de cette approche par rapport à l'envoi du mot de passe par e-mail:

1. nécessite un serveur Web
2. plus de travail que d'envoyer simplement le mot de passe par e-mail facilement

Comme je vous l'a déjà dit, personne à part le client ne devrait connaître le mot de passe, et je n'ai jamais essayé cette approche, mais au moins c'est mieux que d'exposer le mot de passe en texte brut dans un EMAIL qui peut résider sur de nombreux ordinateurs / serveurs pendant un certain temps.

J'ai créé un petit projet que j'appelle "Secure Messaging Service" qui vous permettra de saisir un message et de générer un lien pour afficher ce message. Une fois le message affiché, il est supprimé de la base de données. Il prend même en charge l'envoi d'un e-mail lorsque le message a été lu!

Tapez un message et appuyez sur "envoyer", notre serveur générera un GUID basé sur uuidgenerator.net, une phrase de passe aléatoire de 8 caractères basée sur passwordwolf.com (qui n'est pas stocké dans notre base de données), et cryptera votre message en utilisant AES-256-CBC. Vous recevrez alors un lien contenant le GUID et la phrase de passe pour afficher le message (ou à envoyer à quelqu'un pour afficher le message), dès que le lien est utilisé, le message n'existera plus dans notre base de données.

Vous avez désormais la possibilité pour notre service de vous envoyer un e-mail lorsque votre message est lu par le destinataire. Lorsque vous fournissez votre e-mail, nous le cryptons avant de l'insérer dans notre base de données en utilisant la même méthode de cryptage que votre message secret, y compris la même phrase de passe. Cette phrase de passe n'est pas stockée sur notre serveur, elle est donnée dans le cadre du lien pour afficher le message.

Puisque tout ce qui est envoyé à notre serveur est crypté avec AES-256-CBC, et la phrase de passe n'existe que dans le lien fourni, cela signifie que seuls vous et la personne à qui vous envoyez le lien pouvez voir le message. Si quelqu'un d'autre voulait le voir, il doit le forcer. Cinquante supercalculateurs capables de vérifier un milliard de milliards (1018) de clés AES par seconde (si un tel appareil pouvait être fabriqué) nécessiteraient, en théorie, environ 3 × 1051 ans pour épuiser l'espace de clé de 256 bits. Nous avons fait de notre mieux pour que ces messages ne soient visibles par personne d'autre que la personne avec le lien, même si cette personne a accès à la base de données, mais nous ne donnons aucune garantie et ne sommes pas responsables des dommages causés par l'utilisation de ce service.

Le service de messagerie sécurisée prend également en charge l'API, ce qui signifie que vous pouvez potentiellement générer et envoyer automatiquement un e-mail aux utilisateurs qui s'inscrivent avec un lien pour afficher leur mot de passe.

Voici comment les données dans la base de données est stockée, comme vous pouvez le voir, il n'y a aucun moyen de récupérer le contenu du message en utilisant les informations de la table, car cela nécessite une phrase secrète spéciale qui n'est ajoutée qu'au lien qui vous est donné lors de la création le message, et n'est pas stocké dans la base de données.

Pour commencer, c'est une sorte de mauvaise situation. On dirait que vous partagez des comptes d'utilisateurs. Parfois, il n'y a pas de bonne alternative à cela, mais il ne devrait pas être utilisé avec quelque chose de particulièrement sensible car il devient beaucoup plus difficile de vérifier l'utilisation de la ressource lorsque plusieurs personnes se connectent sous le même nom.

Si il est vraiment nécessaire d'avoir plusieurs personnes utilisant les mêmes comptes, alors les informations d'identification doivent être livrées en personne.

Ce n'est probablement pas pratique, donc votre meilleure option est de les envoyer via un téléphone fixe. (Dans la plupart des pays au moins.) Les lignes fixes sont relativement difficiles à intercepter et dans la plupart des pays, il est interdit à la compagnie de téléphone d'écouter sans une décision du tribunal. Les agences d'espionnage gouvernementales vous écoutent peut-être, mais si elles veulent vos mots de passe, elles vous battent jusqu'à ce que vous les transmettiez de toute façon.

À peu près le même niveau de sécurité est le courrier électronique crypté via GPG ou similaire. Il est plus facile pour des tiers d'intercepter et de stocker les données, mais plus difficile pour eux de les lire jusqu'à ce qu'ils aient suffisamment de temps pour déchiffrer la clé. Assurez-vous de changer le mot de passe tous les quelques années et assurez-vous de ne pas utiliser la même lettre type à chaque fois, car cela facilite le craquage.

Si vous ne pouvez pas les intégrer avec cela, un le code du livre est votre meilleur pari. Doit être un livre que tout le monde a et utilise tout le temps de toute façon, donc cela pourrait être un peu délicat. Le format typique est quelque chose comme pagenumber-paragraphnumber-wordnumber. Faites en sorte que les mots de passe soient de quatre ou cinq mots et cela fonctionnera bien. Ou épelez-le en utilisant la première lettre de chaque mot spécifié si nécessaire.

Si un code de livre ne fonctionne pas, tant que le mot de passe ne contient pas de mots ou de structures verbales, une simple substitution ou un chiffrement de transposition comme celui utilisé pour les cryptogrammes dans le journal sera suffisant pour empêcher tout sauf le attaquants les plus déterminés. Mais le mot de passe doit être composé de caractères aléatoires ou une analyse statistique le fera rapidement et vous devez toujours fournir la clé de cryptage via un canal sécurisé. Évidemment, avec cette méthode, vous ne cryptez que le mot de passe pour limiter votre surface d'attaque et, de préférence, ne faites aucune mention du fait que vous l'avez brouillé dans le reste de l'email. Toute discussion sur le fait que le mot de passe est crypté et comment doit être via un canal sécurisé.

Il existe un cas d'utilisation typique pour les équipes de développement distribuées où SysOps et TeamMembers créent des informations d'identification pour une ressource (base de données, service, serveur) et doivent les communiquer à l'équipe. SI vous ajoutez un nouveau membre à l'équipe:

• Vous ne pouvez pas simplement hacher le mot de passe.
• Vous ne pouvez pas simplement réinitialiser le mot de passe ou il cessera de fonctionner pour le reste de l'équipe.

Nous utilisons un gestionnaire de mots de passe distribué. Cela nous permet d'ajouter un nouveau mot de passe et de le partager avec des individus ou des groupes. Vous recevrez un e-mail du type "BOFH-1 a partagé le mot de passe 'JenkinAdmin'". Vous devez vous connecter pour voir le vrai mot de passe qui voyagera via https.

Un outil centralisé peut être excessif pour certains scénarios car il vous oblige à une installation et une configuration. C'est formidable si tout votre service l'utilise pour le mettre à jour. Une seule personne doit mettre à jour les informations d'identification dans le gestionnaire de mots de passe. Nous utilisons un outil open source, mais les programmes spécifiques sont mieux traités dans les Recommandations logicielles

Correct, il n'est pas sûr d'envoyer un mot de passe dans un e-mail.

Un protocole de compte initial sûr est:

Envoyer à l'utilisateur un lien hypertexte expirant et autoriser l'utilisateur pour définir leur mot de passe initial à partir de ce lien, puis vérifiez éventuellement que l'utilisateur a configuré le deuxième facteur, puis vérifiez éventuellement l'identité de l'utilisateur d'une autre manière (appel vidéo?) Enfin, attribuez au compte de l'utilisateur l'accès dont il a besoin.

Je suggère d'utiliser Signal pour envoyer et recevoir des mots de passe. C'est une application de chat cryptée de bout en bout.

Les messages signal et les appels sont toujours cryptés de bout en bout et minutieusement conçus pour assurer la sécurité de votre communication. Nous ne pouvons pas lire vos messages ni voir vos appels, et personne d’autre ne le peut non plus.

Aucun e-mail n’est dangereux car même si vous utilisez SSL sur vos serveurs de messagerie, il existe un enregistrement de le message sur le disque du serveur qui peut être lu par un administrateur. Seuls les e-mails chiffrés PGP / GPG ou SMIME seraient en sécurité.

Quelqu'un a ajouté ce qui suit à ma réponse. Je n'en ai pas entendu parler, donc je ne peux pas le recommander.

En plus de Signal - une autre option cryptée d'échange de messages peut être utilisée, qui ne nécessite pas de confirmer votre identifiant en cliquant sur des liens ou en fournissant e-mail, etc. C'est aussi multi-plateforme, ce qui est très important. C'est

1. pour Android: application de conversation
2. pour Linux et Windows: application Gajim

Il peut utiliser le cryptage PGP ou OMEMO - le plug-in devra peut-être être installé séparément.

Il existe également une autre méthode, probablement la meilleure dans votre situation.

Cela nécessite que vous ayez un site Web avec SSL et sur un site Web et boîte intégrée. Quelqu'un peut écrire un message dans cette boîte et lors de l'envoi, le message doit être crypté avec [c'est-à-dire] une clé publique PGP qui ne peut être décryptée automatiquement que sur le courrier électronique de votre PC.

Demandez-leur à la place de prendre le téléphone et de vous appeler. L'utilisation de la communication hors bande réduit considérablement la probabilité qu'un espion ait accès à vos informations. C'est en partie parce qu'il n'est pas improbable qu'un attaquant ait compromis votre système de messagerie ou votre système téléphonique, mais les chances qu'ils aient compromis les deux sont faibles. si vous pouvez diviser les informations vitales (par exemple le nom d'utilisateur dans l'e-mail, le mot de passe par téléphone, etc.), cela devient simplement plus difficile pour l'attaquant, par rapport à l'augmentation du travail qui vous est demandé.

Si votre adresse e-mail est prédéfinie par l'entreprise, une solution est de ne pas avoir de mot de passe du tout (le mot de passe est précédé d'une longue chaîne compliquée, etc. que personne ne connaît).

Vous demandez alors un nouveau (via la fonctionnalité "Mot de passe oublié"), qui vous envoie un lien de réinitialisation vers votre e-mail.

Le bon vieux coup de téléphone est une méthode qui a fait ses preuves.

En dehors de cela, une poignée de main SSH est une bonne méthode ...

Vous et le destinataire générez une clé SSH. Vous générez un mot de passe et cryptez le mot de passe à l'aide de votre clé. Vous envoyez un mot de passe crypté au client. Ils ajoutent un cryptage supplémentaire à votre message à l'aide de leur clé. Ensuite, ils vous renvoient le message à double cryptage. Vous décryptez ce message en ne laissant que le mot de passe chiffré par la clé du destinataire. Vous renvoyez ce message. Ils le déchiffrent en utilisant leur mot de passe pour obtenir le mot de passe. De cette façon, les données non chiffrées ne touchent jamais le Web.

OAuth est l'alternative pour accéder à des systèmes tiers sans avoir à configurer l'authentification par mot de passe dans ces systèmes et élimine le besoin d'échanger des mots de passe. Bien sûr, cela exigerait que les systèmes prennent en charge OAuth, ce qui n'est pas toujours le cas.

La première chose qui me vient à l'esprit est le cryptage asymétrique (par exemple GPG). Cela pourrait être particulièrement utile sans trop compliquer les choses.

Trouvez ou configurez un serveur de clés publiques et laissez tout le monde partager leurs clés publiques. Ensuite, chaque fois que vous avez besoin de partager quelque chose de sensible avec un destinataire spécifique, vous pouvez saisir sa clé et crypter le contenu. Personne d'autre ne connaîtra le contenu original, à l'exception du destinataire.

Un exemple d'e-mail deviendrait:

Bonjour iBug,

Voici votre identifiant de connexion à Échange de pile de sécurité de l'information. Il est chiffré avec votre clé DEADBEEF trouvée sur notre serveur de clés d'entreprise.

  < GPG Encrypted Message >  

Vous pouvez utiliser SendPass ( https://sendpass.app)

À mon avis, les deux plus grands risques liés à l'envoi de mots de passe en texte brut sont qu'ils peuvent résider dans les archives, les journaux ou encore dans la boîte aux lettres de l'utilisateur, et le second étant l'interception du mot de passe et le destinataire réel ne le sachant pas (et donc ne notifiant pas l'administrateur).

Pour faire face à ces risques, j'ai créé une application gratuite que vous pouvez utiliser pour envoyer un code à usage unique qui peut être utilisé par le destinataire pour récupérer le mot de passe. J'ai publié SendPass pour aider d'autres personnes, en particulier des personnes non techniques, mais cela peut également vous être utile.

SendPass vous offre un moyen gratuit, simple et sécurisé de partager des mots de passe. SendPass fonctionne en générant un code unique et unique que vous pouvez envoyer à votre destinataire. Le code ne peut être utilisé qu'une seule fois, après quoi le mot de passe sera instantanément supprimé.