Ich verwende normalerweise einen Passwort-Manager, um Passwörter zu speichern und freizugeben. Es gibt viele Passwortmanager, die über diese Funktion verfügen.

Ein Passwort wird von einem Konto zum anderen geteilt, wobei die Benachrichtigung über die Freigabe per E-Mail an die andere Person gesendet wird, die wählen kann, ob sie akzeptiert, ablehnt oder oder ignorieren Sie einfach die Freigabe. Die Kommunikation des Kennworts ist sicher, während die Benachrichtigung über die Freigabe über weniger sichere Kanäle wie E-Mail erfolgt und somit die Stärke jeder Methode nutzt, ohne die Sicherheit zu beeinträchtigen. Einige Produkte ermöglichen die Freigabe des Passworts, ohne das Passwort dem Empfänger mitzuteilen. In diesem Fall ist das Widerrufen des Passworts möglich.

Ich empfehle dringend, für alle Ihre Passwörter einen Passwort-Manager zu verwenden. Einige kommerzielle sind LastPass, 1Password oder Dashlane, aber es besteht auch die Möglichkeit, einen selbst zu hosten, wenn Sie niemandem vertrauen möchten. Eine schnelle Google-Suche nach "Passwort-Manager" sollte Sie auf den richtigen Weg bringen.

Es ist üblich, dem Benutzer ein anfängliches Passwort per E-Mail zu senden, das nur für eine sehr kurze Zeit gültig ist und sofort beim ersten Anmelden geändert werden muss.

Dies ist auch nicht perfekt. Ein Angreifer mit Lesezugriff auf die E-Mail-Adresse des Benutzers kann dieses ursprüngliche Kennwort vor dem Benutzer abfangen und in seinem Namen verwenden. Der Benutzer würde es bemerken, sobald er versucht, sein ursprüngliches Passwort zu verwenden. Sie würden den Administrator benachrichtigen, dass das Passwort falsch ist, der Administrator würde den illegitimen Zugriff untersuchen und bemerken. Der Angreifer hatte jedoch bereits einige Zeit, um auf das Konto zuzugreifen, sodass möglicherweise bereits Schäden auftreten. Aber es ist immer noch besser als ein dauerhaft gültiges Passwort zu senden.

Außerdem muss das System dies unterstützen. Es ist also keine universell anwendbare Praxis.

Wenn Sie Ihrem E-Mail-Anbieter nicht vertrauen, dass er Ihre E-Mails geheim hält (Sie verwenden Google Mail, einen durch Data Mining finanzierten E-Mail-Dienst den Inhalt Ihrer E-Mail und die Monetarisierung der Ergebnisse), dann ist die E-Mail-Verschlüsselung eine Option. Es gibt das gute alte PGP, das modernere PEP, den IETF-Standard S / MIME sowie einige nicht standardisierte proprietäre Lösungen. Das ist das Schöne an Standards: Es gibt so viele zur Auswahl! Eines haben sie alle gemeinsam: Sie verstehen sich einfach nicht. Es kann ein lästiger Kampf sein, Ihre Geschäftspartner dazu zu bringen, ihre E-Mails in einem Schema zu verschlüsseln, das Sie verstehen.

Zwei Faktoren

Vielleicht ist es nicht buchstäblich für Ihre Situation geeignet, aber eine vernünftige Möglichkeit, vertrauliche Daten über Kanäle zu senden, die nicht ganz sicher sind, besteht darin, sicherzustellen, dass zwei separate Faktoren für den Zugriff auf diese Daten erforderlich sind und dass sie über verschiedene Kanäle gesendet werden. Ich habe beispielsweise Ansätze gesehen, bei denen die Daten in einer verschlüsselten Zip-Datei per E-Mail gesendet werden und das Kennwort für diese Daten per SMS gesendet wird. Auf diese Weise kann weder jemand, der diese E-Mail hat, noch jemand, der Zugriff auf Ihr Telefon hat, auf die vertraulichen Informationen zugreifen.

In ähnlicher Weise könnte es eine bessere Vorgehensweise sein, wenn Sie die Verbindungsinformationen per E-Mail senden und das Passwort kann über das Telefon gesagt werden (insbesondere wenn es sich um eine Passphrase handelt) - aber diese Wahl liegt hauptsächlich bei der Organisation, die die Daten sendet (wer ist angeblich der Stakeholder, der diese Daten zur Vertraulichkeit benötigt ), nicht an jemanden, der es gerade erhält.

Wenn Sie ihm vertrauen, gibt es onetimesecret ( ist Open Source) genau für diesen Zweck.

Wenn Sie sensible Personen senden Informationen wie Passwörter und private Links per E-Mail oder Chat, es gibt Kopien dieser Informationen an vielen Orten gespeichert. Wenn Sie stattdessen einen einmaligen Link verwenden, bleiben die Informationen für eine einzelne Anzeige erhalten, was bedeutet, dass sie später nicht mehr von einer anderen Person gelesen werden können. Auf diese Weise können Sie vertrauliche Informationen auf sichere Weise senden und wissen, dass sie nur von einer Person gesehen werden. Stellen Sie sich das wie eine selbstzerstörende Nachricht vor.

E-Mail ist aufgrund seiner inhärent unverschlüsselten Natur kein guter Mechanismus für die Freigabe von Klartextkennwörtern.

Wenn Kennwörter auf diese Weise freigegeben werden, sollte der Dienst sicherstellen, dass das Kennwort bei der ersten Anmeldung geändert wird, um die Anzahl zu verringern Belichtung (und damit Sie erkennen können, ob jemand das gestohlene Passwort verwendet hat) ist keine perfekte Option, da es dennoch jemandem ermöglicht, das Zeitfenster für den Zugriff auf die Website zu nutzen, aber es ist besser, als nicht zu wissen, dass jemand anderes das Passwort hat

Da dies für Sie angesichts Ihrer Antwort auf den Kommentar von schroeder keine Option zu sein scheint, würde ich vorschlagen, dass Sie sich einen Mechanismus ansehen, der die Verschlüsselung des Passworts auf dem gesamten Weg zwischen Ihrem Kunden und Ihnen garantiert - entweder durch End-to-End-Verschlüsselung des E-Mail-Inhalts oder Verwendung einer authentifizierten und verschlüsselten Freigabeseite, auf der die Klartextkennwörter verschlüsselt werden können. Denken Sie auch daran, wenn Sie sich mit anderen Personen (Ihrem Kunden, Ihren anderen Teammitgliedern), die Ihr Kennwort kennen, wirklich wohl fühlen. Dies hängt von den Sicherheitsanforderungen der Anwendung ab, auf die Sie zugreifen.

Das Hauptrisiko besteht hier sei es, der außer dir das Passwort kennt. In Ihrem Fall wäre dies mindestens:

• Die Person in Ihrer Kundenorganisation, die das Kennwort generiert und per E-Mail an Sie gesendet hat.
• Jeder, der eine E-Mail verwaltet Infrastruktur zwischen Ihrem Kunden und Ihnen
• Jeder mit Netzwerkzugriff in einem der E-Mail-Pfade zwischen Ihrem Kunden und Ihnen
• Die anderen Teammitglieder, die mit demselben Konto und Passwort arbeiten (abgeleitet aus Ihrer Antwort auf den Kommentar von schroeder)
• Jeder, der möglicherweise Zugriff auf Ihre Mailbox hat (z. B. Ihr Kommentar zum unbeaufsichtigten Verlassen Ihres E-Mail-Clients)

Wenn das einzige Ziel des Kennworts darin besteht, den unbefugten Zugriff auf die B2B-Dienste zu vermeiden, und Sie mit anderen Personen vertraut sind, die Ihr Kennwort kennen, können Sie die Verschlüsselung für die Kennwortverteilung prüfen. Während viele SMTP-Server eine Verschlüsselung für die Datenübertragung zwischen Mailserver-Hops implementieren, gibt es keine Verschlüsselungsgarantie. Außerdem werden E-Mails von Natur aus nicht verschlüsselt, sodass das Kennwort zumindest während der Verarbeitung bei jedem der SMTP-Hops (Mail Transfer) im Klartext gespeichert wird.

Dies bedeutet, dass Sie sich die End-to-End-Verschlüsselung ansehen müssen, um sicherzustellen, dass das Kennwort niemandem zur Verfügung steht, der herumschnüffelt, wie z. B. PGP, S / MIME oder eine andere proprietäre Technologie für die asymmetrische Verschlüsselung. Diese würden die Vertraulichkeit des Passworts während der Übertragung gewährleisten, und Sie können weiterhin E-Mail für die Verteilung verwenden - mit dem Kompromiss zwischen schwierigen Einrichtungs- und Betriebskosten.

Sie könnten Kompromisse eingehen und so etwas wie ein verschlüsseltes Passwort verwenden ZIP-Datei oder Office-Dokument mit einem vordefinierten Verschlüsselungskennwort, das über einen sicheren Kanal (z. B. einen Telefonanruf) freigegeben wird, wodurch sowohl der Betriebsaufwand als auch der Schutz des Kennworts verringert werden. In ähnlicher Weise hätte eine in der Cloud gehostete Datei mit den Passwörtern, die mit einem sicher gemeinsam genutzten Geheimnis geschützt ist, dieselben Vor- und Nachteile.

Ich verstehe nicht, warum Sie ihnen die Passwörter senden?

Die Clients legen ihr bevorzugtes Passwort fest, Sie hashen es, speichern den Hash, und niemand außer dem Client / seinem Passwort-Manager-Programm weiß es das ursprüngliche Passwort (nicht einmal Sie), und wenn sie es vergessen, senden Sie ihnen einen Reset-Link.

Wenn Sie ihm jedoch wirklich das Passwort senden müssen, empfehle ich Ihnen, ihm einen Link zu dynamisch generiert zu senden Webseite, auf der sein Passwort angezeigt wird (nur einmal).

Sie müssen so etwas vorübergehend in Ihrer Datenbank speichern.

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

und senden Sie ihm eine E-Mail, dass Sie nur die emailTocken offenlegen, nicht das Passwort

  Hallo, Client Folgen Sie diesem Link, um Ihre zu sehen Passwort https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543 

Auf dem Webserver, wenn jemand diesen Link anfordert, gehen Sie wie folgt vor:

1. Wählen Sie das Passwort aus das hat den emailTocken bereitgestellt
2. löscht seinen Datensatz aus der Datenbank
ol>

Jetzt sieht der erste, der diesen Link anfordert, so etwas wie

  Hallo, Client, Ihr Passwort lautet yeheb8cvddt5.) HINWEIS: Wir werden dieses Passwort von unseren Servern löschen. Sie müssen sich also daran erinnern / es speichern.  

Wenn jemand später denselben Link anfordert, wird er etwas sehen wie

  Dieses Passwort ist leider nicht vorhanden oder wurde bereits angezeigt!  

Vorteile dieses Ansatzes gegenüber dem Senden des Kennworts per E-Mail:

1. Das Kennwort wird nur einmal für den ersten Betrachter angezeigt, nicht für diejenigen, die die E-Mail später sehen .
2. Wenn jemand anderes das Passwort zuerst angezeigt hat (ein Mann in der Mitte), kann der legitime Benutzer es nicht sehen und bittet um Hilfe, wodurch wir wissen, dass es das Passwort gibt Es ist etwas Falsches passiert, besser als jemand anderes es sieht, und wir wissen es nicht einmal. Ich hoffe, Ihr E-Mail-Agentenprogramm fordert dies aus irgendeinem Grund nicht automatisch an :( .
ol>

Nachteile dieses Ansatzes gegenüber dem Senden des Passworts per E-Mail:

1. erfordert Webserver
2. mehr Arbeit als nur das einfache Versenden des Poassword per E-Mail Ich habe Ihnen bereits gesagt, dass niemand außer dem Client das Kennwort kennen sollte, und ich habe diesen Ansatz nie ausprobiert, aber es ist zumindest besser, als das Kennwort im Klartext in einer E-Mail anzuzeigen, die sich für eine Weile auf vielen Computern / Servern befinden kann.

Ich habe ein kleines Projekt erstellt, das ich "Secure Messaging Service" nenne und mit dem Sie eine Nachricht eingeben und einen Link zum Anzeigen dieser Nachricht generieren können. Sobald die Nachricht angezeigt wird, wird sie aus der Datenbank entfernt. Es unterstützt sogar das Senden einer E-Mail, wenn die Nachricht gelesen wurde!

Geben Sie eine Nachricht ein und drücken Sie "Senden". Unser Server generiert eine GUID basierend auf uuidgenerator.net, einer zufälligen 8-stelligen Passphrase auf passwordwolf.com (das nicht in unserer Datenbank gespeichert ist) und verschlüsselt Ihre Nachricht mit AES-256-CBC. Sie erhalten dann einen Link, der die GUID und die Passphrase enthält, um die Nachricht anzuzeigen (oder an jemanden zu senden, um die Nachricht anzuzeigen). Sobald der Link verwendet wird, ist die Nachricht nicht mehr in unserer Datenbank vorhanden. P. >

Sie haben jetzt die Möglichkeit, dass unser Service Ihnen eine E-Mail sendet, wenn Ihre Nachricht vom Empfänger gelesen wird. Wenn Sie Ihre E-Mail angeben, verschlüsseln wir sie, bevor wir sie mit derselben Verschlüsselungsmethode wie Ihre geheime Nachricht, einschließlich derselben Passphrase, in unsere Datenbank einfügen. Diese Passphrase wird nicht auf unserem Server gespeichert, sondern als Teil des Links zum Anzeigen der Nachricht angegeben.

Da alles, was an unseren Server gesendet wird, mit AES-256-CBC verschlüsselt ist und die Passphrase nur in vorhanden ist Der bereitgestellte Link bedeutet, dass nur Sie und derjenige, an den Sie den Link senden, die Nachricht anzeigen können. Wenn jemand anderes es sehen wollte, muss er es brutal erzwingen. Fünfzig Supercomputer, die eine Milliarde (1018) AES-Schlüssel pro Sekunde prüfen könnten (falls ein solches Gerät jemals hergestellt werden könnte), würden theoretisch etwa 3 × 1051 Jahre benötigen, um den 256-Bit-Schlüsselraum zu erschöpfen. Wir haben unser Bestes getan, um diese Nachrichten nur für die Person mit dem Link sichtbar zu machen, auch wenn diese Person über Datenbankzugriff verfügt. Wir übernehmen jedoch keine Garantie und sind nicht verantwortlich für Schäden, die durch die Nutzung dieses Dienstes verursacht werden. P. >

Der Secure Messaging Service bietet auch API-Unterstützung. Dies bedeutet, dass Sie möglicherweise automatisch eine E-Mail generieren und an Benutzer senden können, die sich mit einem Link registrieren, um ihr Kennwort anzuzeigen.

So werden die Daten angezeigt Wie Sie sehen, gibt es in der Datenbank keine Möglichkeit, den Inhalt der Nachricht anhand der Informationen in der Tabelle wiederherzustellen, da eine spezielle Passphrase erforderlich ist, die nur an den Link angehängt wird, den Sie beim Erstellen erhalten die Nachricht und wird nicht in der Datenbank gespeichert.

Ich würde vorschlagen, Signal zum Senden und Empfangen von Passwörtern zu verwenden. Es ist eine durchgängig verschlüsselte Chat-App.

Signalmeldungen und Anrufe werden immer durchgehend verschlüsselt und sorgfältig entwickelt, um Ihre Kommunikation sicher zu halten. Wir können Ihre Nachrichten nicht lesen oder Ihre Anrufe sehen, und niemand anderes kann dies.

Keine E-Mail ist nicht sicher, denn selbst wenn Sie SSL auf Ihren Mailservern verwenden, gibt es Aufzeichnungen darüber die Nachricht auf der Festplatte des Servers, die von einem Administrator gelesen werden kann. Nur mit PGP / GPG oder SMIME verschlüsselte E-Mails wären sicher.

Jemand hat meiner Antwort Folgendes hinzugefügt. Ich habe noch nichts davon gehört und kann es daher nicht empfehlen.

Zusätzlich zu Signal kann eine andere verschlüsselte Option zum Austausch von Nachrichten verwendet werden, bei der Ihre ID nicht durch Klicken auf Links oder Bereitstellen bestätigt werden muss E-Mail usw. Es ist auch Multi-Plattform, was sehr wichtig ist. Es ist

1. für Android: Konversations-App
2. für Linux und Windows: Gajim-App
ol>

Es kann entweder PGP- oder OMEMO-Verschlüsselung verwenden - Das Plug-In muss möglicherweise separat installiert werden.

Es gibt auch eine andere Methode, wahrscheinlich die beste in Ihrer Situation.

Sie müssen eine Website mit SSL und auf einer Website haben und eingebettete Box. Jemand kann eine Nachricht in dieses Feld schreiben. Beim Senden sollte die Nachricht mit dem öffentlichen PGP-Schlüssel [d. H.] Verschlüsselt werden, der nur in Ihrer PC-E-Mail automatisch entschlüsselt werden kann.

Bitten Sie sie, stattdessen den Hörer abzunehmen und Sie anzurufen. Durch die Verwendung der Out-of-Band-Kommunikation wird die Wahrscheinlichkeit, dass ein Lauscher Zugriff auf Ihre Informationen erhält, erheblich verringert. Dies liegt zum Teil daran, dass es nicht unwahrscheinlich ist, dass ein Angreifer Ihr E-Mail-System oder Ihr Telefonsystem kompromittiert hat, aber die Wahrscheinlichkeit, dass beide kompromittiert wurden, ist gering. Wenn Sie die wichtigen Informationen (z. B. Benutzername in E-Mail, Passwort per Telefon usw.) aufteilen können, wird es für den Angreifer nur schwieriger, im Vergleich zu der Zunahme des Arbeitsaufwands, den Sie benötigen.

Zunächst einmal ist dies eine schlechte Situation. Es hört sich so an, als würden Sie Benutzerkonten freigeben. Manchmal gibt es keine gute Alternative dazu, aber es sollte nicht mit besonders sensiblen Elementen verwendet werden, da es viel schwieriger wird, die Verwendung der Ressource zu überwachen, wenn sich mehrere Personen unter demselben Namen anmelden.

If Es ist wirklich notwendig, dass mehrere Personen dieselben Konten verwenden. Dann sollten die Anmeldeinformationen persönlich übermittelt werden.

Das ist wahrscheinlich nicht praktikabel. Daher ist es Ihre nächstbeste Option, sie per Festnetztelefon zu senden. (Zumindest in den meisten Ländern.) Festnetzanschlüsse sind relativ schwer abzufangen, und in den meisten Ländern ist es der Telefongesellschaft untersagt, ohne gerichtliche Anordnung zuzuhören. Regierungsspionageagenturen hören vielleicht zu, aber wenn sie Ihre Passwörter wollen, werden sie Sie nur schlagen, bis Sie sie trotzdem übergeben.

Etwa die gleiche Sicherheitsstufe sind verschlüsselte E-Mails über GPG oder ähnliches. Für Dritte ist es einfacher, die Daten abzufangen und zu speichern, für sie jedoch schwieriger, sie zu lesen, bis sie genug Zeit haben, um den Schlüssel zu knacken. Stellen Sie sicher, dass Sie das Passwort alle paar Jahre ändern und dass Sie nicht jedes Mal den gleichen Serienbrief verwenden, da dies das Knacken erleichtert.

Wenn Sie sie damit nicht an Bord bringen können, dann a Buchcode ist Ihre nächstbeste Wette. Muss ein Buch sein, das jeder hat und das er sowieso ständig benutzt, also könnte das etwas schwierig sein. Typisches Format ist so etwas wie Seitenzahl-Paragraphnummer-Wortnummer. Stellen Sie die Passwörter auf vier oder fünf Wörter ein und es wird gut funktionieren. Oder buchstabieren Sie es bei Bedarf mit dem ersten Buchstaben jedes angegebenen Wortes.

Wenn ein Buchcode nicht funktioniert, reicht eine einfache Ersetzung oder Transpositionsverschlüsselung, wie sie für die Kryptogramme in der Zeitung verwendet wird, aus, um alle außer den zu vermeiden, solange das Passwort keine Wörter oder wortähnlichen Strukturen enthält entschlossenste Angreifer. Das Passwort muss jedoch aus zufälligen Zeichen bestehen. Andernfalls wird die statistische Analyse zu kurz und Sie müssen den Verschlüsselungsschlüssel weiterhin über einen sicheren Kanal bereitstellen. Offensichtlich verschlüsseln Sie mit dieser Methode nur das Passwort, um Ihre Angriffsfläche einzuschränken, und erwähnen vorzugsweise überhaupt nicht die Tatsache, dass Sie es im Rest der E-Mail verschlüsselt haben. Alle Diskussionen darüber, dass das Passwort verschlüsselt ist und wie es über einen sicheren Kanal erfolgen muss.

Richtig, es ist unsicher, ein Passwort in einer E-Mail zu senden.

Ein sicheres Protokoll für das Erstkonto lautet:

Senden Sie dem Benutzer eine einmalige Verwendung, wobei der Hyperlink abläuft, und lassen Sie den Benutzer zu Überprüfen Sie dann optional, ob der Benutzer den zweiten Faktor eingerichtet hat. Überprüfen Sie dann optional die Identität des Benutzers auf andere Weise (Videoanruf?). Stellen Sie schließlich dem Benutzerkonto den erforderlichen Zugriff zur Verfügung.

Es gibt einen typischen Anwendungsfall für verteilte Entwicklungsteams, in denen SysOps und TeamMembers Anmeldeinformationen für eine Ressource (Datenbank, Dienst, Server) erstellen und diese an das Team kommunizieren müssen. WENN Sie dem Team ein neues Mitglied hinzufügen:

• Sie können das Passwort nicht einfach hashen.
• Sie können das Passwort nicht einfach zurücksetzen, da es sonst für den Rest des Teams nicht mehr funktioniert.

Wir verwenden einen verteilten Passwort-Manager. Auf diese Weise können wir ein neues Passwort hinzufügen und es für Einzelpersonen oder Gruppen freigeben. Sie erhalten eine E-Mail wie "BOFH-1 hat das Passwort 'JenkinAdmin' geteilt". Sie müssen sich anmelden, um das echte Passwort zu sehen, das über https übertragen wird.

Ein zentrales Tool kann in einigen Szenarien ein Overkill sein, da es Sie zu einer Installation und Konfiguration zwingt. Es ist großartig, wenn alle Ihre Abteilungen es verwenden, um es zu aktualisieren. Nur eine Person muss die Anmeldeinformationen im Kennwortmanager aktualisieren. Wir verwenden ein Open-Source-Tool, aber bestimmte Programme werden in Softwareempfehlungen

Der gute alte Anruf ist eine bewährte Methode.

Abgesehen davon ist ein SSH-Handshake eine gute Methode ...

Sowohl Sie als auch der Empfänger generieren ein SSH-Schlüssel. Sie generieren ein Passwort und verschlüsseln das Passwort mit Ihrem Schlüssel. Sie senden ein verschlüsseltes Passwort an den Client. Sie fügen Ihrer Nachricht mit ihrem Schlüssel eine zusätzliche Verschlüsselung hinzu. Dann senden sie Ihnen die doppelt verschlüsselte Nachricht zurück. Sie entschlüsseln diese Nachricht und lassen nur das Kennwort, das mit dem Schlüssel des Empfängers verschlüsselt ist. Sie senden diese Nachricht zurück. Sie entschlüsseln es mit ihrem Passwort, um das Passwort zu erhalten. Auf diese Weise berühren unverschlüsselte Daten niemals das Web.

Wenn Ihre E-Mail von der Firma voreingestellt ist, besteht eine Lösung darin, überhaupt kein Passwort zu haben (das Passwort wird mit einer langen, komplizierten usw. Zeichenfolge versehen, die niemand kennt).

Sie fordern dann an eine neue (obwohl die Funktion "Passwort vergessen"), die Ihnen einen Link zum Zurücksetzen auf Ihre E-Mail sendet.

OAuth ist die Alternative für den Zugriff auf Systeme von Drittanbietern, ohne dass eine Kennwortauthentifizierung in diesen Systemen eingerichtet werden muss, und macht den Austausch von Kennwörtern überflüssig. Dazu müssten die Systeme natürlich OAuth unterstützen, was nicht immer der Fall ist.

Das erste, was mir in den Sinn kommt, ist die asymmetrische Verschlüsselung (z. B. GPG). Dies kann besonders nützlich sein, ohne die Dinge zu komplizieren.

Suchen oder Einrichten eines öffentlichen Schlüsselservers und Ermöglichen, dass jeder seine öffentlichen Schlüssel freigibt. Wenn Sie dann etwas Sensibles für einen bestimmten Empfänger freigeben müssen, können Sie seinen Schlüssel abrufen und den Inhalt verschlüsseln. Niemand anderes als der Empfänger kennt den ursprünglichen Inhalt.

Eine Beispiel-E-Mail würde lauten:

Hallo iBug,

Hier ist Ihr Anmeldeinformationen für Informationssicherheits-Stapelaustausch. Es ist mit Ihrem Schlüssel DEADBEEF verschlüsselt, der sich auf unserem Unternehmensschlüsselserver befindet.

  < GPG-verschlüsselte Nachricht >  

Sie könnten SendPass ( https://sendpass.app) verwenden.

Meiner Meinung nach bestehen die beiden größten Risiken beim Senden von Klartext-Passwörtern darin, dass sie sich möglicherweise in befinden Archive, Protokolle oder noch im Postfach des Benutzers, und das zweite ist das Abfangen des Kennworts und des tatsächlichen Empfängers, der dies nicht weiß (und daher den Administrator nicht benachrichtigt).

Um diesen Risiken zu begegnen, habe ich eine kostenlose Anwendung erstellt, mit der Sie einen einmaligen Code senden können, mit dem der Empfänger das Kennwort abrufen kann. Ich habe SendPass veröffentlicht, um anderen zu helfen, insbesondere nicht-technischen Personen, aber es kann auch für Sie von Nutzen sein.

SendPass bietet Ihnen eine kostenlose, einfache und sichere Möglichkeit, Passwörter zu teilen. SendPass generiert einen eindeutigen, einmaligen Code, den Sie an Ihren Empfänger senden können. Der Code kann nur einmal verwendet werden. Danach wird das Passwort sofort gelöscht.