Alternative à l'envoi d'un mot de passe par courrier?
Récemment, j'ai commencé à travailler comme entrepreneur pour une entreprise, ce qui m'oblige souvent à me connecter à différents services B2B.
La façon dont je reçois les données de connexion se fait généralement par e-mail en texte brut. Mon intuition me dit que l'envoi de données sensibles en texte brut n'est pas une bonne idée mais je ne sais pas s'il existe une alternative, ou peut-être qu'elle est déjà protégée par le service de messagerie (dans ce cas gmail)?
Je suis conscient du danger probablement le plus évident qui serait de laisser mon compte de messagerie connecté et sans surveillance, mais je suis plus intéressé par une sorte d'homme au milieu des attaques ou d'autres dangers.
Le cœur de ma question est:
Existe-t-il une alternative à l'envoi de mots de passe par e-mail, et quels seraient les plus grands dangers de l'utilisation de l'e-mail pour cela?
Une pratique courante consiste à envoyer à l'utilisateur un mot de passe initial par e-mail qui n'est valable que très peu de temps et doit être modifié 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 remarquerait dès qu'il tenterait 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 avait déjà un certain temps pour accéder au compte, il pourrait donc déjà y avoir des dommages. Mais c'est toujours mieux que d'envoyer un mot de passe valide en permanence.
Cela nécessite également que le système le prenne en charge. 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 du contenu de votre e-mail et la monétisation des résultats), le cryptage des e-mails est une option. Il y a le bon vieux PGP , le plus moderne PEP , la norme IETF - S/MIME ainsi que certaines solutions propriétaires non standardisées. C'est la bonne chose au sujet des normes: il y a tellement de choix! Mais ils ont tous une chose en commun: ils ne font tout simplement pas l'affaire. Faire en sorte que vos partenaires commerciaux chiffrent leurs e-mails dans un schéma que vous comprenez peut être une bataille difficile ennuyeuse.
J'utilise couramment un gestionnaire de mots de passe pour stocker et partager des mots de passe. De nombreux gestionnaires de mots de passe disposent de cette fonctionnalité.
Un mot de passe est partagé d'un compte à l'autre, avec la notification du partage envoyée par e-mail à l'autre personne, qui peut choisir d'accepter, de refuser ou simplement d'ignorer le partage. La communication du mot de passe est sécurisée, tandis que la notification du partage passe par 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 autoriseront 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 fortement 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'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.
Deux facteurs
Peut-être que ce n'est pas littéralement approprié à 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 sont 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 pour ces données est envoyé par SMS. De cette manière, ni quelqu'un qui a cet e-mail ni quelqu'un qui a accès à votre téléphone ne peut accéder aux informations sensibles.
De la même manière, cela pourrait être une meilleure pratique si vous envoyez les informations de connexion par e-mail et que le mot de passe peut être dit par téléphone (surtout s'il s'agit d'une phrase secrète) - mais ce choix appartient principalement à l'organisation envoi les données (qui est censé être la partie prenante qui a besoin que ces données soient gardées confidentielles), pas à quelqu'un qui vient de les recevoir.
Si vous lui faites confiance, onetimesecret (qui est open source ) existe dans ce but précis.
Lorsque vous envoyez des informations sensibles aux gens comme des mots de passe et des 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 à usage unique à la place, les informations persistent pour une seule visualisation, ce qui signifie qu'elles ne peuvent pas être lues par quelqu'un d'autre ultérieurement. Cela vous permet d'envoyer des informations sensibles en toute sécurité sachant qu'elles ne sont vues que par une seule personne. Considérez-le comme un message autodestructeur.
Le courrier électronique n'est pas un bon mécanisme pour partager des mots de passe en texte brut é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 modifié lors de la première connexion pour réduire l'exposition (et pour vous permettre de détecter si quelqu'un a utilisé le mot de passe volé), ce n'est pas une option parfaite car il permet toujours à quelqu'un de prendre avantage 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, étant donné 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 le cryptage de bout en bout du le contenu des e-mails ou l'utilisation d'un site de partage authentifié et crypté où les mots de passe en texte brut peuvent être cryptés. Pensez également si vous êtes vraiment à l'aise avec d'autres personnes (votre client, les autres membres de votre équipe) connaissant votre mot de passe, quelque chose qui dépendrait des exigences de sécurité de l'application à laquelle vous accédez.
Le principal risque ici serait de savoir 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 vous l'a envoyé par e-mail
- Toute personne gérant une infrastructure de messagerie entre votre client et vous-même
- Toute personne disposant d'un accès au réseau dans l'un des chemins de messagerie entre votre client et vous-même
- 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 envisager le cryptage pour la distribution du mot de passe. Bien que de nombreux serveurs SMTP implémentent le cryptage pour le transfert de données entre les serveurs de messagerie, il n'y a aucune garantie de cryptage, et les e-mails ne sont pas intrinsèquement cryptés, de sorte que le mot de passe résidera en texte clair au moins pendant son traitement à chacun des sauts de transfert de messagerie (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. Ceux-ci garantiraient la confidentialité du mot de passe pendant le transport, et vous pouvez toujours utiliser le courrier électronique pour sa distribution - avec le compromis d'une configuration difficile et des coûts d'exploitation.
Vous pouvez compromettre et utiliser quelque chose comme un fichier Zip crypté ou un 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 les frais généraux opérationnels 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 sauf le client/son programme de gestion de mot de passe ne connaît 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 vers une page Web générée dynamiquement qui affiche son mot de passe (pour 1 fois seulement).
vous devez stocker temporairement quelque chose comme ça dans votre base de données
emailTocken char(32)
password varchar
+----------------------------------+------------------+
| emailTocken | password |
+----------------------------------+------------------+
| 202CB962AC59075B964B07152D234B70 | jhds7ytht_id |
| CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874# |
| 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5) |
| 2510C39011C5BE704182423E3A695E91 | 6#hdyd98_jee |
| 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e |
+----------------------------------+------------------+
et lui envoyer un e-mail que vous exposez uniquement l'e-mailTocken pas le mot de passe
Hello, client
Follow this link to see your password
https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543
sur le serveur Web lorsque quelqu'un demande ce lien, procédez comme suit
- sélectionnez le mot de passe qui contient l'e-mailTocken
- supprimer son enregistrement de la base de données
Maintenant, le premier qui demande ce lien verra quelque chose comme
Hello, client
your password is yeheb8cvddt5)
NOTE: WE WILL DELETE THIS PASSWORD FROM OUR SERVERS, SO YOU HAVE TO REMEMBER/SAVE IT
Si quelqu'un demande plus tard le même lien, il verra quelque chose comme
Sorry, this password is not exist or has been viewed before!
Avantages de cette approche par rapport à l'envoi du mot de passe par e-mail:
- le mot de passe n'est exposé qu'une seule fois pour le premier utilisateur, pas pour celui qui verra l'e-mail plus tard.
- si quelqu'un d'autre a d'abord vu 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 s'est passé quelque chose de mieux, mieux que quelqu'un d'autre le voir, et nous ne savons même pas. J'espère que votre programme d'agent de messagerie électronique ne le demande pas automatiquement pour une raison quelconque: (.
inconvénients de cette approche par rapport à l'envoi du mot de passe par e-mail:
- nécessite un serveur web
- plus de travail que d'envoyer simplement le mot de passe par e-mail facilement
Comme je vous l'ai 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 un petit projet que j'ai créé que j'appelle "Secure Messaging Service" qui vous permettra de taper 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ée dans notre base de données) , et cryptera votre message à l'aide de l'AES-256-CBC. Vous recevrez alors un lien qui contient le GUID et la phrase secrète pour afficher le message (ou pour envoyer à quelqu'un pour l'afficher) ), dès que le lien sera utilisé, le message n'existera plus dans notre base de données.
Vous avez maintenant 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 secrète. Cette phrase secrète n'est pas stockée sur notre serveur, elle est donnée dans le cadre du lien pour visualiser le message.
Étant donné que tout ce qui est envoyé à notre serveur est crypté avec AES-256-CBC et que la phrase secrète n'existe que dans le lien fourni, cela signifie que vous et la personne à qui vous envoyez le lien peuvent afficher le message. Si quelqu'un d'autre voulait le voir, il doit le forcer brutalement. Cinquante supercalculateurs qui pourraient 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 clé de 256 bits. Nous avons fait de notre mieux pour que ces messages ne soient visibles que par la personne disposant du 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 pourriez potentiellement générer et envoyer automatiquement un e-mail aux utilisateurs qui s'inscrivent avec un lien pour afficher leur mot de passe.
C'est comme cela que les données de la base de données sont stockées, comme vous pouvez le voir, il n'y a aucun moyen de récupérer le contenu du message en utilisant les informations du tableau, car cela nécessite une phrase de passe spéciale qui n'est ajoutée qu'au lien fourni lorsque vous créez le message et n'est pas stocké dans la base de données.
Pour commencer, c'est une sorte de mauvaise situation. Il semble que vous partagiez 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.
S'il est vraiment nécessaire que plusieurs personnes utilisent les mêmes comptes, les informations d'identification doivent être fournies en personne.
Ce n'est probablement pas pratique, donc votre prochaine meilleure option est de les envoyer par téléphone fixe. (Dans la plupart des pays au moins.) Les lignes fixes sont relativement difficiles à intercepter et dans la plupart des pays, la compagnie de téléphone n'a pas le droit d'écouter sans ordonnance du tribunal. Les agences d'espionnage du gouvernement peuvent être à l'écoute, mais si elles veulent vos mots de passe, elles vous battront jusqu'à ce que vous les remettiez de toute façon.
Environ le même niveau de sécurité est le courrier électronique crypté via GPG ou similaire. Il est plus facile pour les 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 casser la clé. Assurez-vous de changer le mot de passe toutes les quelques années et assurez-vous de ne pas utiliser la même lettre type à chaque fois, car cela facilite le déchiffrement.
Si vous ne pouvez pas les embarquer avec cela, alors un code livre est votre prochain 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 les mots de passe 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 aucun mot ou structure semblable à un mot, un simple chiffrement de substitution ou de transposition comme pour les cryptogrammes du journal sera suffisant pour empêcher tous les attaquants, sauf les plus déterminés. . Mais le mot de passe doit être composé de caractères aléatoires ou une analyse statistique fera rapidement l'affaire et vous devrez 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'e-mail. Toute discussion sur le fait que le mot de passe est crypté et comment doit l'ê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 (DataBase, service, serveur) et doivent la 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 passera par https.
Un outil centralisé peut être une exagération pour certains scénarios car il vous oblige à une certaine installation et configuration. C'est génial 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 discutés dans Software recommendations
Je suggère d'utiliser Signal pour envoyer et recevoir des mots de passe. Il s'agit d'une application de chat cryptée de bout en bout.
Les messages et les appels sont toujours cryptés de bout en bout et minutieusement conçus pour assurer la sécurité de vos communications. Nous ne pouvons pas lire vos messages ni voir vos appels, et personne d'autre ne 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 du message sur le disque du serveur qui peut être lu par un administrateur. Seul le courrier électronique crypté PGP/GPG ou SMIME serait sûr.
Quelqu'un a ajouté ce qui suit à ma réponse. Je n'en ai pas entendu parler, je ne peux donc pas 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 des e-mails, etc. C'est également multi-plateforme qui est très important. C'est
- pour Android: application Conversation
- pour Linux et Windows: application Gajim
Il peut utiliser le cryptage PGP ou OMEMO - le plug-in peut devoir être installé séparément.
Il existe également une autre méthode, probablement la meilleure dans votre situation.
Cela vous oblige à avoir un site Web avec SSL et sur un site Web et une 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] la clé publique PGP qui ne peut être décryptée automatiquement que sur la messagerie de votre PC.
Demandez-leur plutôt de décrocher le téléphone et de vous appeler. L'utilisation de communications hors bande réduit considérablement la probabilité qu'un utilisateur indiscret accède à vos informations. Cela est dû en partie au fait qu'il n'est pas improbable qu'un attaquant ait compromis votre système de messagerie électronique ou votre système téléphonique, mais la probabilité qu'il ait compromis les deux est faible. si vous pouvez diviser les informations vitales (par exemple, nom d'utilisateur dans l'e-mail, 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 e-mail est prédéfini par l'entreprise, une solution consiste à ne pas avoir de mot de passe (le mot de passe est ensemencé avec une chaîne longue, compliquée, etc. que personne ne connaît).
Vous en demandez ensuite un nouveau (via la fonctionnalité "Mot de passe oublié"), qui vous envoie un lien de réinitialisation vers votre e-mail.
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:
Envoyez à l'utilisateur une utilisation unique, un hyperlien expirant et autorisez l'utilisateur à définir son mot de passe initial à partir de ce lien. Ensuite, vérifiez éventuellement que l'utilisateur a configuré le deuxième facteur. Ensuite, vérifiez éventuellement l'identité de l'utilisateur d'une autre manière (appel vidéo?) Enfin, fournissez au compte de l'utilisateur l'accès dont il a besoin.
Le bon vieux coup de téléphone est une méthode éprouvée.
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échiffrez ce message en ne laissant que le mot de passe chiffré par la clé du destinataire. Vous renvoyez ce message. Ils le décryptent 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.
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.
Recherchez ou configurez un serveur de clés publiques et laissez chacun partager ses clés publiques. Ensuite, chaque fois que vous devez partager quelque chose de sensible à un destinataire spécifique, vous pouvez récupérer 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:
Salut iBug,
Voici vos informations de connexion à Information Security Stack Exchange. Il est chiffré avec votre clé
DEADBEEFtrouvée sur notre serveur de clés d'entreprise.< GPG Encrypted Message >
Vous pouvez utiliser SendPass ( https://sendpass.app )
À mon avis, les deux principaux risques d'envoyer des mots de passe en texte brut sont qu'ils peuvent résider dans des archives, des journaux ou encore dans la boîte aux lettres de l'utilisateur, et le deuxième étant l'interception du mot de passe et le destinataire réel ne le sachant pas (et donc sans en informer l'administrateur).
Pour faire face à ces risques, j'ai créé une application gratuite que vous pouvez utiliser pour envoyer un code unique qui peut être utilisé par le destinataire pour récupérer le mot de passe. J'ai publié SendPass pour aider les autres, en particulier les personnes non techniques, mais il peut également vous être utile.
SendPass vous offre un moyen gratuit, facile 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é.
OAuth est l'alternative pour accéder aux systèmes tiers sans avoir à configurer l'authentification par mot de passe dans lesdits systèmes et élimine le besoin d'échanger des mots de passe. Bien sûr, cela nécessiterait que les systèmes prennent en charge OAuth, ce qui n'est pas toujours le cas.