Das tust du nicht.

Wenn Sie Benutzern beibringen, jemandem ihren Benutzernamen und ihr Kennwort zu geben, schulen Sie sie darin, anfällig für Phishing oder andere Social-Engineering-Angriffe zu sein.

Entwerfen Sie das System stattdessen so, dass ein Administrator diese Einstellungen anzeigen und bearbeiten kann, ohne dass die Anmeldeinformationen des Benutzers erforderlich sind.

Wenn Sie sich in einer Situation befinden, in der Sie wirklich etwas sehen müssen Bitten Sie den Benutzer aus Sicht des Benutzers, ein Kennwort für Sie einzugeben, und lassen Sie sich dann das Problem anzeigen. Dies kann entweder persönlich oder mit einem Remoteverwaltungstool erfolgen.

Wenn Sie in einer Situation sind, in der der Kunde über Anmeldeinformationen verfügt, die Sie in Ihrer Anwendung für die Integration in eine Lösung eines Drittanbieters benötigen, entwickeln Sie Ihre Anwendung in einem Auf diese Weise verfügt ein nicht technischer Benutzer über eine benutzerfreundliche Benutzeroberfläche zum Festlegen dieser Anmeldeinformationen. Sie benötigen dies ohnehin, falls der Kunde sie ändern muss und Sie nicht verfügbar sind.

Der Benutzer muss dies erst eingeben, wenn die Anwendung auf seinen eigenen Servern bereitgestellt wird. Während der Entwicklung sollten Sie ein Testkonto verwenden, um mit den Drittanbietern zu kommunizieren. Sie möchten Ihrem Kunden definitiv keine Kosten verursachen, da Sie einige Tests an den Zahlungsschnittstellen von Drittanbietern durchgeführt haben, die nicht wie erwartet funktioniert haben.

Es gibt zahlreiche "Team-Passwort-Manager", mit denen Teams den Zugriff auf Anmeldeinformationen freigeben, ändern und widerrufen können. Die meisten werden bezahlt (oder sind für kleine Teams kostenlos), aber dies ist wahrscheinlich der beste Weg. Sie bieten in der Regel Verschlüsselung sowie Zugriffskontrolle über den Zugriff auf bestimmte Anmeldeinformationen.

Die einzige praktikable Option, die ich sehe (die noch nicht erwähnt wurde, ungerade), besteht darin, über die Client-Setup-Konten mit den entsprechenden Berechtigungen zu verfügen, die Sie für diese Systeme / Internetdienste verwenden können. Auf diese Weise kümmern sie sich um die Lieferantenbeziehungen und die Zahlung, aber Sie haben Konten mit dem Zugriff, den Sie benötigen.

Wie in der Antwort von Phillip angegeben, fragen Sie einfach nicht nach oder nehmen nicht daran teil beim Teilen von Passwörtern. Es ist einfach rundum schlecht, da Sie sich selbst in die Lage versetzen, beschuldigt zu werden, wenn etwas schief geht, wenn jemand anderes das gemeinsam genutzte Konto verwendet. ("Ich weiß , dass meine Mitarbeiter so etwas niemals tun würden, und Sie sind die einzigen Personen, mit denen wir das Passwort geteilt haben. Es muss also etwas sein, das Sie getan haben! ! ")

Ich fasse die Situation wie folgt zusammen:

• Sie benötigen Zugriff auf einen Drittanbieter-Service mit Konto Ihres Kunden.
• Ein persönliches Treffen ist nicht einfach zu erreichen.
• Eine Lösung, bei der der Client Software installiert oder ein komplexes Verfahren befolgt, ist unerwünscht.

Ich denke, die beste Lösung wäre: Senden Sie ein neues Passwort an SIE

Sie Senden Sie ihnen ein Passwort auf sichere Weise und geben Sie ihnen Anweisungen (per Telefon?), um das Passwort für ihre Konten vorübergehend auf Ihr vorgeschlagenes Passwort festzulegen. - Dann können Sie sich damit auf der Seite anmelden. Und wenn Sie fertig sind, können sie ihr Passwort auf den ursprünglichen Wert zurücksetzen.

Ein einfacher Weg wäre ein einmaliger Link in der E-Mail, der zu einer Seite führt, auf der das Passwort angezeigt wird. Der Client kann darauf klicken und das Passwort kopieren. Und ein Angreifer kann nicht auf denselben Passwort-Link zugreifen. (Natürlich wäre ein gezielter MitM-Angriff mit Änderung des E-Mail-Inhalts weiterhin möglich und könnte durch Signieren der E-Mail gemindert werden.)

Sie können ihnen das temporäre Passwort auch telefonisch mitteilen, sie schreiben es auf und ändern ihr Passwort Kontokennwort vorübergehend auf dasjenige, das Sie ihnen mitteilen.

Dieser Rückwärtsweg hat mehrere Vorteile:

• Ihr Kunde kann die Regel "Teilen Sie niemals Ihr Kennwort"
einhalten
• Sie können eine sichere Methode zur Weitergabe des Kennworts auswählen. Sie müssen Ihrem Client keine sichere Methode beibringen.
• Ihr Client behält die Kontrolle darüber, wie Sie Ihren Zugriff gewähren und widerrufen.

Es gibt buchstäblich unzählige Lösungen für die sichere Übertragung von Daten (z. B. Anmeldeinformationen).

• Wenn der Client die PGP / GPG-Verschlüsselung unterstützt, können Sie öffentliche Schlüssel austauschen und die E-Mails verschlüsseln.
• Es gibt auch Unternehmen, die sich auf SecureMail (ZixCorp) spezialisiert haben oder die Sie erwerben können Ihre eigene (Cisco Ironport).
• Wenn Sie eine Website für die Zusammenarbeit haben (z. B. ein Kundenportal für den Kunden), können diese die Anmeldeinformationen in das Portal hochladen. Zu Ihrer Information Alfresco ist eine Freeware-Anwendung, die dies gut macht.
• Können Sie eine SMS schreiben, auch wenn menschlicher Kontakt nicht in Frage kommt? Vielleicht können sie eine SMS mit dem Passwort senden und den Benutzernamen über einen anderen Kanal angeben.
• Wenn alles andere fehlschlägt, sind Rauchsignale und Schneckenpost immer noch eine Sache, aber die oben genannten Methoden sind die häufigsten Vektoren.

Halten Sie es einfach, aber verwenden Sie nur zwei Kommunikationsformen. Bitten Sie sie beispielsweise in einer E-Mail, in der Anmeldeinformationen angefordert werden, nur mit dem Benutzernamen zu antworten, und senden Sie dann ein temporäres Kennwort an Ihre Nummer. Ändern Sie das temporäre Kennwort so bald wie möglich, nachdem Sie die Anmeldeinformationen erhalten haben, in ein anderes.

Ja, theoretisch könnte jemand die E-Mail sehen und SS7 hacken, um das Passwort zu erhalten, aber wenn er dies kann, bevor Sie das temporäre Passwort ändern können, sind Sie trotzdem pwned.

Sie sollten keine hartcodierten Rückrufe sein, die auf bestimmte Benutzernamen / Passwörter reagieren. Wenn Sie mit Tools von Drittanbietern arbeiten, sollten Sie diese Konten für sie einrichten und über API-Token mit diesen Tools interagieren. Viel besser, wenn Sie das Konto erstellen und am Ende dem Kunden alle Kontoanmeldeinformationen zuweisen.

Seltsam, dass niemand OAuth erwähnt hat, was auf den ersten Blick die perfekte Lösung für das Problem darstellt, wie es nach dem Update umformuliert wurde.