Frage:
Alternative zum Senden eines Passworts per E-Mail?
aMJay
2019-04-03 15:10:38 UTC
view on stackexchange narkive permalink

Vor kurzem habe ich angefangen, als Auftragnehmer für ein Unternehmen zu arbeiten, weshalb ich mich häufig bei verschiedenen B2B-Diensten anmelden muss.

Die Art und Weise, wie ich die Anmeldedaten erhalte, erfolgt normalerweise per E-Mail im Klartext. Mein Bauchgefühl sagt mir, dass das Senden vertraulicher Daten im Klartext keine gute Idee ist. Ich bin mir jedoch nicht sicher, ob es eine Alternative gibt oder ob sie bereits vom Mailingdienst (in diesem Fall Google Mail) geschützt ist.

Ich bin mir der wahrscheinlich offensichtlichsten Gefahr bewusst, die darin besteht, dass mein E-Mail-Konto angemeldet und unbeaufsichtigt bleibt. Ich bin jedoch mehr an einer Art Mann interessiert, der sich in der Mitte befindet, oder an anderen Gefahren.

Der Kern meiner Frage lautet:

Gibt es eine Alternative zum Senden von Passwörtern per E-Mail, und was wären die größten Gefahren bei der Verwendung von E-Mails?

Können Sie das Passwort ändern?
@schroeder technisch kann ich jedoch, dass es andere Leute gibt, die diese Konten möglicherweise in Zukunft verwenden müssen, so dass ich das neue zurückschicken müsste, also denke ich, dass das den Punkt verfehlen würde
@aMJay Benutzerkonten sollten nach Möglichkeit personalisiert werden.Wenn eine andere Person Zugriff auf das System benötigt, sollte diese Person ein eigenes Konto erhalten.
Können sie Ihnen Zugriff auf einen Passwort-Manager gewähren, über den sie diese Anmeldeinformationen mit Ihnen teilen?
@BlueCacti das ist etwas, das ich mit ihnen besprechen müsste, aber ich werde es als mögliche Alternative nehmen
@aMJay Wenn Sie möchten, kann ich es als Antwort hinzufügen.Der Vorteil der Verwendung eines PWM-Managements besteht darin, dass sie die Kontrolle über die Anmeldeinformationen behalten und Ihren Zugriff widerrufen können.Wenn die Creds nur für Webanwendungen verwendet werden, können sie mit LastPass (und wahrscheinlich auch anderen) das Kennwort für Sie freigeben, ohne dass Sie die Klartextversion des Kennworts lesen können
Vault bietet eine einmalige Verbindung.Sie können diesen Link per E-Mail senden. Wenn jemand darauf klickt, werden Sie es bemerken.Dies funktioniert natürlich nur, wenn es schnell erkannt wird und die Passwörter für die Aufgabe eindeutig sind.Sobald Sie ein Login für den Tresor eingerichtet haben, können Sie damit auch Passwörter freigeben.Es gibt keine bequemen GUI- oder PAM / PQ-Managerfunktionen für die Kennwortfreigabe, aber wenn Sie nur sichere Kennwortdownloads benötigen, ist dies in Ordnung.
Teilen Sie das Passwort.E-Mail Teil davon und Text den anderen Teil.
Dies ist das Ergebnis von Leuten, die Anforderungen festlegen oder Implementierungen ohne die erforderlichen Kenntnisse durchführen.Oder sie kennen die Probleme und haben sich entschieden, das Risiko zu akzeptieren.Sie sollten Peter Gutmanns * [Engineering Security] (http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) * lesen.
Dafür ist der Schlüsselaustausch gedacht.Sie können Diffie Hellman über das Telefon verwenden (um aktives MITM zu verhindern).
Der Titel wäre klarer als "Passwort über E-Mail" als "Passwort über Mail".
Siebzehn antworten:
#1
+69
Kent
2019-04-03 17:04:19 UTC
view on stackexchange narkive permalink

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.

Willkommen auf der Seite, Kent!Das Hinzufügen von Inhalten kann manchmal schwierig sein: Sie versuchen, Ihre Erfahrungen zu nutzen, aber dann beschweren sich die Leute, dass es sich wie eine Anzeige anhört.Vielen Dank, dass Sie dabei geblieben sind und Ihre Antwort gemäß den Kommentaren aktualisiert haben!Ich hoffe du bleibst auf der Seite :)
Der Vollständigkeit halber sehe ich [Dashlane] (https://www.dashlane.com), das auch häufig für die Freigabe von Zugriffen mit oder ohne Offenlegung von Passwörtern (mit möglichem Widerruf des Zugangs) verwendet wird.
Ja, das ist die "richtige" Antwort.Bei meinem Arbeitgeber verwenden wir eine intern gehostete Unternehmensverwaltungslösung mit einem Web-Frontend. Wenn wir Kennwörter freigeben müssen, senden wir eine E-Mail mit einem Link zu dem betreffenden Geheimnis.(Grundsätzlich - https: // [ourpasswordmanagentserver.ourdomain.com] /SecretView.aspx?secretid= [######])
Sie können ein Passwort nicht teilen, ohne es preiszugeben.Natürlich können Sie es freigeben, ohne es anzuzeigen, aber die Person, mit der Sie es freigeben, kann das Kennwort immer noch an einer anderen Stelle sehen, sei es auf der Seite, auf der es ausgefüllt ist, indem Sie das Kennwortfeld in ein Textfeld ändern oder es aus dem Netzwerk entfernenmeldet sich in ihrem Browser an, sobald die Anmeldeanforderung gesendet wurde.Jedem Passwort-Manager, der etwas anderes behauptet, sollte nicht vertraut werden.
#2
+64
Philipp
2019-04-03 16:13:57 UTC
view on stackexchange narkive permalink

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.

Ein "Standard", auf den so ziemlich jeder Zugriff hat, ist eine verschlüsselte Zip-Datei.Nicht der stärkste Schutz, aber viel besser als einfacher Text.Senden Sie das Passwort über einen anderen Kanal, Text, Voicemail oder Nachnamen des Betrunkenen, den wir am College kannten.
Oder senden Sie ein Bild von einem Stück Papier mit dem Passwort.Wenn Sie explizit als Ziel ausgewählt werden, spielt dies natürlich keine Rolle. Wenn Sie sich jedoch Sorgen über passives Mining machen, wird die Verarbeitung ausreichend verzögert, sodass Ihr zeitlich begrenztes Kennwort abläuft, bevor es durchgesickert ist.
Möglicherweise möchten Sie beachten, dass OpenPGP auch ein IETF-Standard ist ([RFC4880] (https://tools.ietf.org/html/rfc4880)).
Es kann hilfreich sein, hinzuzufügen, dass das Aktivieren der Zwei-Faktor- / Multi-Faktor-Authentifizierung, sofern verfügbar, das Risiko des Abfangens eines anfänglichen oder kürzlich zurückgesetzten Kennworts verringert.
Wenn das System gesteuert / geändert werden kann, sollte es durch Hinzufügen der Richtlinie "Diese Aktion nur von vertrauenswürdigen IPs zulassen" zum anfänglichen OTP erheblich verbessert werden (Sie beschränken den Angriff auf Ihr lokales Netzwerk).Wie auch immer, stimmen Sie der Verwendung von PGP et al.
Das Verschlüsseln von E-Mails ist eine der schlimmsten Erfahrungen, die Sie machen können.Der gesamte Prozess fühlt sich immer noch direkt aus den 90ern an (besonders lustig, da einige dieser Standards neuer sind).
@Voo Das hängt davon ab.Bei mir haben wir ein Plugin für Microsoft Outlook, das E-Mails verschlüsselt, ohne dass der Benutzer etwas tun muss.Natürlich muss auf dem Receiver auch das Plugin installiert sein.
@Philipp Und dass eine Infrastruktur vorhanden ist, die sicherstellt, dass der Empfänger bereits über Ihren Schlüssel verfügt.Hier beginnt der Spaß.Oh, und Sie müssen natürlich immer noch in der Lage sein, unverschlüsselte E-Mails an die meisten anderen Personen zu senden, also muss es eine Whitelist geben.So weit so gut, aber was ist, wenn Sie eine E-Mail an Personen senden, die auf der "verschlüsselten" Liste stehen, und an andere, die es nicht sind?Und so weiter und so fort.Kein Spaß, aber sicher, dass die Benutzer es nur bemerken, wenn es nicht funktioniert.
@Neil_UK oder eine KeepassDB und Sie geben der Datenbank das Passwort per Telefon oder auf andere Weise.
Haben Sie jemals versucht, eine verschlüsselte ZIP-Datei über Google Mail anzuhängen?Es wird nicht akzeptiert;IOW, * es ist unmöglich *.Ich habe das einmal versucht, IIRC, eine EXE-Datei zu senden, die Google Mail auch nicht zulässt.
@MikeWaters Manchmal können Sie Filter austricksen, indem Sie Dateierweiterungen entfernen und dann im E-Mail-Text den Benutzer auffordern, die richtige Erweiterung nach dem Herunterladen der Datei erneut hinzuzufügen - was Sie im E-Mail-Text angeben würden.
#3
+26
Peteris
2019-04-03 16:20:28 UTC
view on stackexchange narkive permalink

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.

Diese IMO ist der richtige Weg, um Daten zur Authentifizierung zu senden: Verwenden Sie zwei separate Kanäle.Ich möchte jedoch einen wichtigen Hinweis hinzufügen: Sowohl der Absender als auch der Empfänger sollten dann die Daten so schnell wie möglich löschen, indem sie die E-Mail oder die SMS oder die WhatsApp-Nachricht usw. löschen. Außerdem denke ich, dass WhatsApp-Nachrichtensind wahrscheinlich besser als SMS.Sie (und die andere Partei) müssen nur daran denken, die Nachricht zu löschen, sobald das Passwort an einem anderen Ort sicher gespeichert wurde.
@reed Wenn die über zwei Kanäle empfangenen Schlüssel einmalig sind und der Benutzer unmittelbar nach ihrer Verwendung aufgefordert wird, ein vom Benutzer generiertes Kennwort einzugeben, müssen die Nachrichten nicht entfernt werden.
So mache ich es normalerweise.Und ich achte darauf, nichts über den Host zu erwähnen oder mich im passworttragenden Text anzumelden.Beachten Sie, dass dies auch ein guter Zeitpunkt ist, um Benutzer zur Verwendung von Signalen zu ermutigen, damit der Text selbst verschlüsselt wird
Signal ist wahrscheinlich die sicherste Möglichkeit, eine Nachricht an das Telefon einer anderen Person zu senden - vorausgesetzt, auf beiden Seiten ist Signal installiert.
#4
+11
user137369
2019-04-03 19:32:27 UTC
view on stackexchange narkive permalink

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.

Das Erstellen eines eigenen Onetimesecret-Systems ist ziemlich trivial.Ich habe vor ein paar Jahren einen PoC in ungefähr einem Dutzend Zeilen Perl geschrieben.Durch das Speichern eines Geheimnisses (Text) wird eine URL erstellt, die sicher versendet werden kann. Die URL kann genau einmal geöffnet werden, danach wird das Geheimnis überschrieben und dann gelöscht.Wenn Sie versuchen, es erneut zu öffnen, wird eine 404-ähnliche Fehlermeldung angezeigt, die den Besucher darüber informiert, dass, wenn er diese Nachricht beim ersten Besuch der URL sieht, jemand anderes sie zuvor gesehen hat, am häufigsten durch Abfangen der E-Mail mitder Link.
#5
+4
llmora
2019-04-03 16:20:02 UTC
view on stackexchange narkive permalink

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.

#6
+3
AccountantM
2019-04-03 20:40:10 UTC
view on stackexchange narkive permalink

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
  3. 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 :( .
    3. 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 bereits über diese Lösung nachgedacht, aber wie wir alle wissen, ist ich (d. H. Der durchschnittliche Programmierer) in 99,91% der Fälle gut beraten, keine benutzerdefinierten sicherheitsrelevanten Tools zu erstellen.Also habe ich mich immer gefragt: ** Wenn dies wirklich eine gute Idee ist, wo ist das getestete, bewährte Open Source-Tool, das genau das tut? **
@s1lv3r Wie ich in der Antwort erwähnt habe, habe ich es nie versucht. Ich habe nur gesalzene Passwörter gehasht und den Hash gespeichert. Wenn meine Kunden nach dem Passwort fragen, gebe ich ihnen einen Reset-Link.** Die vorgeschlagene Lösung ist jedoch besser als ein einfaches Passwort in E-Mails! **
@s1lv3r überprüft [diese Antwort] (https://security.stackexchange.com/a/206724/149722), er hat es tatsächlich getan.Und [dieser] (https://security.stackexchange.com/a/206709/149722) auch
Dies ist eine vernünftige Methode, um Kennwörter in einem benutzerdefinierten System zu implementieren. Mein Eindruck ist jedoch, dass das OP nach Situationen fragt, in denen die Unternehmen, mit denen sie zusammenarbeiten, Kennwörter für verschiedene von ihnen verwendete Software und Dienste von Drittanbietern generieren.
@XiongChiamiov Ja, das verstehe ich.Anstatt Passwörter zu generieren und diese per E-Mail an ihre Besitzer zu senden, generieren Sie die Passwörter, speichern Sie sie in der Datenbank und senden Sie die Links.
#7
+3
GrumpyCrouton
2019-04-03 21:08:14 UTC
view on stackexchange narkive permalink

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.

enter image description here

Schöne, einfache und freundliche Benutzeroberfläche, das habe ich mit meiner Antwort gemeint. Ich werde Ihren Service mit einem Lesezeichen versehen, um ihn zu nutzen, wenn ich ihn brauche. Danke.
@Accountant Lassen Sie mich wissen, ob Sie an zusätzliche Funktionen denken oder Fehler finden können.Froh, dass Sie es mögen!:) (Es lässt mich wegen des Symbols in deinem Namen nicht direkt zu dir)
Ich schlage vor, Sie erhalten die eigentliche geheime Nachricht und löschen sie, wenn der Benutzer mit der Maus über dieses Feld fährt / klickt (durch eine AJAX-Anfrage), um zu verhindern, dass das Passwort durch automatische Anfragen von E-Mail-Agenten oder WhatsApp, Facebook-Bots * (wenn ich) gelöscht wirdSende den Link an meinen Freund in WhatsApp oder Facebook. Diese Programm-Bots stellen automatisch eine Anfrage, wodurch das Geheimnis gelöscht wird.) *.ansonsten ist es sehr schön
@Accountant Gute Idee, das werde ich auf jeden Fall hinzufügen.
Dies mag für manche Menschen ein nützlicher Dienst sein, aber warum sollten wir Ihnen vertrauen?
@aCVn berechtigte Sorge, aber warum sollten wir unseren Betriebssystemherstellern, Webhosting-Unternehmen und alltäglichen Programmen vertrauen?**RECHT**.Eine kleine Benutzervereinbarung wird ausreichen. Ansonsten vertrauen wir technisch jeder Codezeile, die wir täglich verwenden, oder kennen wir sie überhaupt?Ein weiterer Grund für mich, ihm zu vertrauen, ist, dass dies ein leichter Dienst ist, für den keine Registrierung erforderlich ist. Dadurch weiß er nicht, wer ich bin oder an wen ich das Passwort gesendet habe oder welches Passwort dies ist.Wo kann es verwendet werden?** Er sieht nur Geheimnisse für Benutzer, von denen er nichts mehr weiß als die Benutzeragenten ihrer IPs / Browser. **
@aCVn Einfach, wenn Sie dem Dienst nicht vertrauen, verwenden Sie ihn nicht.Es gibt mehrere andere Dienste, die ähnliche Dinge tun.Ich habe auf der About-Seite genau dargelegt, wie es funktioniert, was es speichert, und das ist alles, was ich wirklich tun kann, um Menschen zu "beweisen", dass sie dem Service vertrauen können.Ich sehe auch nicht, was ich gewinnen könnte, wenn ich darüber lüge, da der Dienst anonym ist.
@aCVn Ich habe ein Bild hinzugefügt, das zeigt, wie alles in der Datenbank gespeichert ist.Ich könnte sogar in Betracht ziehen, den Code auf Github hochzuladen, wenn ich eines Tages aufhöre, faul zu sein
@AccountantM Ich bin mir nicht sicher, ob Sie überhaupt noch an diesem Projekt interessiert sind oder sich überhaupt daran erinnern (ich habe es vergessen, obwohl ich es noch gehostet habe), aber jemand hat meine Antwort hier positiv bewertet, was mich an dieses Projekt erinnerte.Es stellte sich heraus, dass es in den letzten Monaten einige Verwendung gefunden hat, von denen ich nicht einmal wusste.Es hat heute einige Zeit gedauert, es komplett neu zu schreiben.Überprüfen Sie die Änderungen, die ich vorgenommen habe!
@GrumpyCrouton Hallo, ja, ich erinnere mich an Ihr Projekt und es wird in meinen mit Lesezeichen versehenen Websites angezeigt, aber ich habe es noch nicht verwendet.Herzlichen Glückwunsch zu den neuen Änderungen im Erscheinungsbild (sieht besser aus). Ich habe den Netzwerkverkehr noch nicht überprüft, werde ihn aber heute Abend genauer untersuchen.
@AccountantM Super.Ich denke darüber nach, eine Möglichkeit zu implementieren, mit der Personen auf Nachrichten antworten können, die sie gesendet haben (wenn der Absender eine E-Mail eingegeben hat, ohne dem Empfänger die E-Mail des Absenders tatsächlich anzuzeigen), ähnlich wie die Seite Kontakt.Eine andere Idee, die ich hatte, war, den Absendern zu erlauben, ein zusätzliches Passwort festzulegen, das der Empfänger manuell eingeben muss, bevor er das Geheimnis preisgibt.Lass mich wissen was du denkst!
#8
+2
Chloe
2019-04-04 02:20:27 UTC
view on stackexchange narkive permalink

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
  3. 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.

@Over-heads Befinden Sie sich aufgrund einer herabgestimmten / gelöschten Antwort im Antwortverbot?Wenn ja, können Sie sich erinnern, 1) wie viele Antworten haben Sie geschrieben?2) Wie viele von ihnen haben Sie gesehen, dass sie herabgestimmt wurden (die Zahl oben links war negativ)?|Übrigens, wahrscheinlich kannst du in 2 Wochen wieder posten.
@Over-heads Hier sehen Sie die Liste Ihrer gelöschten Antworten.Wie viele Antworten gibt es und wie viele von ihnen haben eine negative Punktzahl?https://security.stackexchange.com/users/recently-deleted-answers/203877
#9
+2
Monica Apologists Get Out
2019-04-04 17:54:07 UTC
view on stackexchange narkive permalink

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.

Ja, ich habe ein paar Mal "ein temporäres Passwort über das Telefon lesen" verwendet, wenn ich mit weniger technisch versierten Leuten auf der anderen Seite zu tun hatte, die Dinge wie GPG nicht zum Laufen bringen konnten.Ärgerlich, aber praktisch.
#10
+2
Perkins
2019-04-04 00:07:15 UTC
view on stackexchange narkive permalink

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.

#11
+2
Douglas Held
2019-04-04 02:03:47 UTC
view on stackexchange narkive permalink

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.

#12
+2
borjab
2019-04-04 01:13:19 UTC
view on stackexchange narkive permalink

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

besser erläutert
Dies wird bereits durch die allgemeinere Antwort des Passwort-Managers abgedeckt.Bitte schalten Sie keine Anzeigen für bestimmte Produkte.
@schroeder Ich hatte den Verweis auf die Lösung entfernt, auch wenn es sich um Open Source handelt.
#13
+1
bremen_matt
2019-04-04 10:31:48 UTC
view on stackexchange narkive permalink

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.

Warum tun Sie dies, wenn Sie nur PGP verwenden können, das eigentlich für solche Dinge vorgesehen ist?
#14
+1
WoJ
2019-04-03 20:33:38 UTC
view on stackexchange narkive permalink

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.

Dies wird in den Kommentaren zur Frage behandelt
#15
  0
n0rd
2019-04-04 09:46:36 UTC
view on stackexchange narkive permalink

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.

Dies beantwortet die Frage nicht
@schroeder, könnten Sie näher darauf eingehen?
Ich meine, wie ist "OAuth" keine Antwort auf "Gibt es eine Alternative zum Senden von Passwörtern per E-Mail ..."?(Mit der Annahme, dass nur "Ja" nicht ausreicht)
Dies ist eine Alternative zu der Notwendigkeit, überhaupt ein Passwort zu senden.Es ist eine Umgestaltung des Problems.Die Implikation ist, dass ein Passwort kommuniziert werden muss.
Alternativen sind genau das, worum es in dieser Frage geht.Es gibt keine Voraussetzung, dass OAuth keine Option ist.Viele B2B-Anwendungen, mit denen ich mich befasst habe, unterstützen es, aber Leute, die es verwenden, ignorieren diese Fähigkeit oft.
Die Apps, mit denen ich gearbeitet habe, sind jedoch definitiv verzerrt, da diese hauptsächlich in Azure gehostet werden und Azure AD unterstützen.
#16
  0
iBug
2019-04-05 20:47:43 UTC
view on stackexchange narkive permalink

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 >  
bereits durch andere Antworten abgedeckt
#17
  0
Toine-L
2019-09-26 22:40:59 UTC
view on stackexchange narkive permalink

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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...