Frage:
Wie kann ich meinen Chef davon überzeugen, dass das Speichern von Passwörtern von Drittanbietern im Klartext eine schlechte Idee ist?
Selkie
2018-02-23 22:51:54 UTC
view on stackexchange narkive permalink

Die Dinge vage halten - Ich arbeite in einem Unternehmen, das Compliance-Probleme für unsere Kunden behandelt. Sehr oft bedeutet dies, dass wir uns für verschiedene Entitäten bei ihren verschiedenen Konten anmelden müssen. Wir speichern ihren Benutzernamen und ihr Passwort, um ihnen das Erinnern und den Zugriff zu erleichtern und um uns bei ihrem Konto anmelden zu können.

Der Benutzername und die Kennwörter scheinen im Klartext gespeichert zu sein, wenn man den vollständigen und totalen Sicherheitsalptraum ignoriert, Anmeldungen für eine Minute gemeinsam zu nutzen. Hurra.

Wie kann ich meinen Chef und die höheren Schichten davon überzeugen, dass A) dies eine schreckliche Idee ist, B) eine bessere Methode / Art, diese zu speichern

Warum sollten Sie sich beim Benutzerkonto anmelden müssen?Was möchten Sie erreichen, indem Sie sich beim Benutzerkonto anmelden?
Füllen Sie die Vorbereitungsarbeiten / das Formular für sie aus.Ich habe auch dagegen gekämpft ...
Wenn es nicht in der Ebene gespeichert ist (für einen Benutzer ohne Passwort), ist es nicht so schlimm.verschlüsselter Speicher kann transparent sein, und vielleicht haben Sie das auch.Meiner Meinung nach sollten Sie immer noch eine On-Demand-Authentifizierung haben, um auf solche Informationen in einem verwendeten System zugreifen zu können.
Unser System verfügt über ein geprüftes Identitätswechselsystem, sodass Sie sich als eine andere Person anmelden können, während klar ist, wer die Aktion tatsächlich ausgeführt hat, auch wenn sie auf den Namen einer anderen Person lautet (wir verwenden diese hauptsächlich, um Fehler zu erkennen, bei denen genau deren Daten angezeigt werden müssen).Könnte dies für Ihr Unternehmen funktionieren?
Ja, wenn es sich um interne Systeme handelt, sollten Sie als Administrator Aktionen als anderer Benutzer ausführen können.Viele Menschen verwenden überall dasselbe Passwort und erwarten, dass niemand es im Klartext sehen kann.Hash und Salt deine Passwörter.
Es ist sicherlich etwas Ironisches an einem Unternehmen, das Compliance-Services anbietet, die den Ball so krass fallen lassen.
Können Sie uns einen Hinweis geben, um welche Art von System es sich handelt (d. H. Was Ihre Kunden ausführen, wo sich Ihre Mitarbeiter mit den Anmeldeinformationen der Kunden anmelden)?Ist es beispielsweise Windows oder ein anderes Closed-Source-System mit eingeschränkten Konfigurationsmöglichkeiten?Shell-Anmeldung bei einem Unix / Linux-System, bei dem Sie schlüsselbasierte ssh-Anmeldungen ohne Kennwort verwenden sollten und I & A möglicherweise mit PAM konfigurieren können?Eine Webanwendung?Wie stark können Sie die Sicherheitsfunktionen dieses Systems anpassen?
Es ist eine Webseite, auf die wir gehen und uns anmelden.
"Tun wir in Bezug auf die Sicherheit etwas schrecklich Falsches?"Ja.Ohne den Fragetext zu lesen, lautet die Antwort auf die im Titel gestellte Frage, wenn wir in den letzten 20 Jahren oder so etwas gelernt haben, mit ziemlicher Sicherheit Ja, für jeden Wert von "wir", der eine Organisation istin der Computerindustrie.: P.
Ich verstehe nicht, was so schrecklich daran ist, Passwörter im Klartext zu speichern.Vergleichen Sie das Speichern von Kennwörtern im Klartext auf einem nicht vernetzten Computer, der in einem Tresor gespeichert ist, mit dem Speichern von Kennwörtern, die auf einer öffentlichen Webseite verschlüsselt sind, mit der Passphrase, die bequem auf derselben Seite gespeichert ist.Welches ist schlimmer?Die schlechte Praxis ist, was auch immer dazu führt, dass Sie das Klartext-Passwort benötigen, nicht dass Sie Passwörter im Klartext speichern.
@emory Welchen Punkt versuchen Sie zu machen?Das Speichern eines verschlüsselten Passworts ist offensichtlich besser als Klartext.Sicher, mit Ihrem erfundenen Beispiel ist das Speichern im Klartext besser, aber ziemlich irrelevant.
@Confuzing-Verschlüsselung ist kein magischer Feenstaub.Wenn das Unternehmen des OP einfach die Liste der Passwörter von Drittanbietern verschlüsselt, ist dies immer noch eine schlechte Idee.
Bitten Sie Ihren Chef, eine Nur-Text-Datei mit dem Kontocode und dem Kennwort für sein Bankkonto zu erstellen, und teilen Sie ihm dann mit, dass Sie dieses Kennwort auf dem freigegebenen Laufwerk des Unternehmens speichern werden.Wenn er nicht der Meinung ist, dass dies eine schlechte Sache ist, versteht er sie wirklich nicht, da jemand auf der Liste der E-Mails / Passwörter, die Sie im Klartext haben, genau die gleiche E-Mail / das gleiche Passwort für IHR Bankkonto hat.
@RichardTingle: Um Ihre Frage zu beantworten: Nein, wir können kein Identitätswechselsystem verwenden. Wir melden uns mit Benutzername und Kennwörtern bei einem völlig anderen System an. (Tatsächlich melden wir uns bei etwa 200 verschiedenen Systemen an. Wir versuchen, nicht zu viel preiszugeben.)
Zehn antworten:
user196499
2018-02-24 00:26:45 UTC
view on stackexchange narkive permalink

Warum ist es eine schreckliche Idee?

Durch das Aufzeichnen der Anmeldeinformationen anderer übernimmt das Unternehmen eine Haftung . Da das Unternehmen jetzt für Böswilligkeit verantwortlich ist, die bei Verwendung dieser Anmeldeinformationen auftreten kann, sollte das Unternehmen Maßnahmen ergreifen, um das Risiko zu minimieren. Darüber hinaus müssen Unternehmen, die mit Ihnen interagieren, die Verantwortung übernehmen, Ihnen zu vertrauen. Dies kann das Geschäft beeinträchtigen, wenn ein Vorfall öffentlich wird (wie von symcbean erwähnt).

Speichern von Passwörtern im Klartext (wie Sie wissen) bietet keinen Schutz gegen dieses Risiko.

Was ist eine bessere Lösung?

Wie Sie in einem Kommentar erwähnt haben, benötigen Sie so etwas wie einen Passwort-Manager . In der Tat ist ein Passwortmanager.

Da bei der Kryptografie viel Fehler auftreten kann, empfehle ich die Verwendung eines etablierten Passwortmanagers. Sie können unzählige Vergleiche online finden, aber am Ende haben Sie die Wahl zwischen Vergleichen, die auf einer GUI basieren (wie 1Kennwort, LastPass, Keepass usw.), oder solchen, die auf einer CLI für den automatisierten Zugriff basieren (wie Pass oder über die LastPass-Kli)

Wir verwenden derzeit unsere eigene Software, um all diese zu speichern und zu verfolgen. Gibt es einen etablierten Passwort-Manager, auf den ich das Management hinweisen könnte (und lassen Sie die Entwickler die eigentliche Arbeit an dem Problem erledigen?).
Ich würde entweder 1password (https://1password.com) oder LastPass (https://lastpass.com) empfehlen.Beide haben eine GUI und eine CLI für den automatisierten Zugriff.
Ich würde die Optionen in eine webbasierte GUI und eine lokale dateibasierte GUI aufteilen.Sind die CLIs datei- oder webbasiert?Oder gibt es sie auch in beiden Varianten?
@Selkie Ich habe einen Plug für [Thycotic Secret Server] (https://thycotic.com/products/secret-server/) eingesteckt.Es gibt (oder gab) eine kostenlose Version, die ich jahrelang bei verschiedenen Arbeitgebern verwendet habe, und der aktuelle Arbeitgeber hat kürzlich ein Upgrade auf eine kostenpflichtige Lizenz durchgeführt.Skaliert gut, vor Ort, einfach zu bedienen und zu verwalten.
Ich würde keinen Passwort-Manager für solche Zwecke empfehlen.Wenn der Computer kompromittiert ist, sind auch die Kennwörter gefährdet - es spielt keine Rolle, welcher Manager verwendet wird, wenn ein gezielter Angriff erfolgt (was in dieser Situation der wahrscheinlichste Fall zu sein scheint).
@Naim - was würden Sie für solche Anwendungen noch empfehlen?Ich würde sagen, dass diese Verwendung eine sehr schlechte Praxis ist und sie es überhaupt nicht tun sollten (Kundenpasswörter verwenden, um sich als sie anzumelden), aber wenn sie es auf diese Weise tun müssen, wenn nicht ein Passwortmanager, was dann??Handgeschriebene Passwörter?Wenn ein Computer gefährdet ist, ist jedes auf diesem Computer verwendete Kennwort gefährdet.
Mit einem Kennwortmanager können weiterhin einzelne Benutzer, die Zugriff auf den Kennwortmanager haben, die Kennwörter anzeigen.Stattdessen sollte das System vollständig automatisiert, die Passwörter verschlüsselt gespeichert und entschlüsselt und vom automatisierten System übergeben werden, wenn sie benötigt werden, ohne dass jemand sie tatsächlich anzeigen kann.Cloud-basierte Passwort-Manager eröffnen Ihnen außerdem eine ganze Menge zusätzlicher Haftung, indem Sie diese Passwörter außerhalb Ihres Unternehmens lassen, selbst wenn sie verschlüsselt sind.Wenn Sie einen Passwort-Manager verwenden möchten, verwenden Sie mindestens einen lokalen wie KeePass.
@SeanBurton Es gibt Enterprise-Passwort-Manager wie den, den ich angeschlossen habe, die über diese Funktionen verfügen und einem persönlichen Passwort-Tresor wie KeePass oder whathaveyou (für Mehrbenutzeranwendungen und Unternehmensfunktionen) weit überlegen sind.
@HopelessN00b Ich bin sicher, dass diese in Ordnung sind, um die Passwörter Ihres eigenen Mitarbeiters zu speichern, aber wenn Sie die Passwörter eines anderen speichern, wäre ich sehr vorsichtig, wenn Sie diese ohne vorherige Genehmigung an Dritte weitergeben oder zumindest an Ihren Anwälten vorbeiführen würden ...
@SeanBurton Auch hier handelt es sich um ein On-Prem-Server-Setup, überhaupt keine Cloud.(und es ist nicht der einzige) Punkt ist, es gibt eine ganze Klasse von Produkten für die Verwaltung von Unternehmenspasswörtern, die möglicherweise die Anforderungen des OP erfüllen.(Obwohl ehrlich gesagt fast alles ein Schritt in die richtige Richtung ist, wenn man bedenkt, was sie jetzt tun.)
Fairerweise war mein Hauptanliegen, keine Cloud-basierten Off-Premises (Lastpass usw.) zu verwenden. Wenn sie lokal sind, klingen sie nach einer guten Option.
symcbean
2018-02-23 23:10:32 UTC
view on stackexchange narkive permalink

Ja, Sie machen etwas schrecklich Falsches. Dass sich Ihr Arbeitgeber auf Compliance zu spezialisieren scheint, macht es noch viel schlimmer. Das Geschäft des Unternehmens basiert auf einem Ruf für hervorragende Compliance, den Sie aktiv missachten.

Leider ist es auf allen Ebenen eines Unternehmens schwierig, Ihre Vorgesetzten davon zu überzeugen, dass das, was sie derzeit tun, eine schlechte Idee ist. Wenn ich Sie wäre, würde ich vorschlagen, dass sie überlegen, wie ihre Kunden reagieren würden, wenn:

  • ihnen mitgeteilt wird, dass Sie ihre Anmeldeinformationen im Klartext speichern (vermutlich ohne Freigabe- / Überwachungskontrollen für die Nutzung)
  • Sie lesen in der Zeitung, dass ein anderer Kunde aufgrund dieser Praxis kompromittiert wurde.

Was wäre ein besserer Ansatz? ..wirklich möchten Sie den richtigen Ansatz, der Vertraulichkeit, Integrität, Verfügbarkeit und Budget in Einklang bringt. Es gibt kommerzielle und Open-Source-Produkte, die dabei helfen würden, aber es würde viel mehr Untersuchung und Analyse erfordern, als für dieses Forum angemessen ist.

Fair genug - ich habe mich gefragt, ob es so etwas wie "Ja, verschlüsseln Sie die Passwörter mit X und dann die Möglichkeit, die Passwörter in die Zwischenablage zu verschieben, ohne sie zu sehen" gibt, ähnlich einem Passwort-Manager.
Nun, aber könnten Sie einen möglichen besseren Ansatz aufzeigen?
Wenn Sie SQL Server zur Datenspeicherung verwenden, können Sie die Spaltenverschlüsselungsfunktion der Datenbank verwenden.Ich kann mich nicht erinnern, ab welcher Version die Datenverschlüsselung zum SQL Server hinzugefügt wurde, aber das ist möglicherweise das, wonach Sie suchen.
Übrigens haben wir eine Lösung für diese Fälle implementiert.Ein Benutzer kann seine Kontorolle für einen bestimmten Zeitraum an einen anderen Benutzer delegieren.Wenn Sie sehen möchten, was der Benutzer sieht, bitten Sie den Benutzer, sein Konto an Sie zu delegieren.Sie melden sich mit Ihren eigenen Anmeldeinformationen an, und das System ermöglicht es Ihnen, sich als Sie selbst oder der andere Benutzer anzumelden.Wenn Sie den anderen Benutzer auswählen, verfügt Ihre Sitzung mit Ausnahme einiger Seiten über alle Berechtigungen des anderen Benutzers.Mit dieser Funktion benötigen Sie keinen Zugriff auf Kennwörter anderer Benutzer, sodass Sie die Kennwörter ordnungsgemäß hashen und sich von Nur-Text-Kennwörtern entfernen können
"Verwenden eines SQL-Servers" oder eines anderen Datenbankverwaltungssystems löst das Problem der Zugriffskontrolle und Überwachung nicht.Das Einfügen von Verschlüsselung in die Mischung führt zu Komplikationen.
Es gibt mehrere Open-Source-Produkte, die geeignet sein könnten - Passbolt, Teampass, Vaultier.Es gibt auch kommerzielle Lösungen wie Cyberark
CJ Dennis
2018-02-24 08:23:42 UTC
view on stackexchange narkive permalink

Sie möchten die Kennwörter des Benutzers überhaupt nicht speichern, auch nicht in KeePass oder ähnlichem.

  • Die Informationen sind standardmäßig ausgeblendet, können aber dennoch problemlos angezeigt werden
  • Passwörter können leicht weitergegeben werden, wodurch die Verantwortlichkeit verloren geht. Woher wissen Sie, dass es der Benutzer war und nicht jemand anderes, der sein Konto verwendet?
  • Wenn ein Passwort aktualisiert wird (z. B. wird ein fehlerhafter Agent entdeckt und Sie Um einen weiteren Zugriff zu verhindern, muss es überall dort aktualisiert werden, wo es verwendet wird.

Dies sind einige Optionen, die nach Szenarien unterteilt sind:

  1. Wenn die von Ihnen verwendeten Systeme Ihre eigenen sind und aktiv gewartet werden, können Sie eine Benutzer-Spoofing-Funktion anfordern. Jede Person mit Administratorzugriff meldet sich mit ihrem eigenen Administratorkonto an, das zu einem beliebigen Benutzerkonto wechseln kann, ohne dass das Kennwort bekannt sein muss. Auf diese Weise haben Sie eine bessere Prüfung. Sie können sehen, dass nicht der echte Benutzer die Aktionen ausführt, sondern der bestimmte Administrator, der den Benutzer fälscht. Dies schützt sowohl Sie als auch den Benutzer, da keiner den anderen der Bosheit beschuldigen kann, es sei denn, es kann nachgewiesen werden, dass der Benutzer das Administratorkennwort oder der Administrator das Kennwort des Benutzers hatte und sein Konto direkt verwendete.

    • Sie kennen nur Ihr eigenes Passwort und können das Passwort eines anderen Benutzers nicht erkennen, selbst wenn es bedroht ist (ein gutes Hashing-Schema dauert durchschnittlich Hunderte von Jahren, um pro Passwort zu brechen).
    • Sie sind es Nur für Ihre eigenen Aktionen verantwortlich, nicht für alle anderen.
    • Wenn das Kennwort eines Benutzers aktualisiert wird, hat dies keine Auswirkungen auf Sie, da sich dadurch nicht ändert, wie Sie auf sein Konto zugreifen.
  2. Wenn die Systeme extern sind, dh von Drittanbietern, können Sie versuchen, dieselbe Art von Benutzer-Spoofing-Funktion auszuhandeln, wobei zu berücksichtigen ist, dass dies möglicherweise eine sehr niedrige oder gar keine Priorität hat Bei einigen Unternehmen kann dies beispielsweise nie oder nur sehr langsam geschehen (denken Sie an Jahre).

  3. Wenn die Systeme nicht mehr gewartet werden, haben Sie kein Glück. Sie können sie aufgrund des Risikos nicht mehr verwenden oder Kennwörter weiterhin lokal speichern und das Risiko akzeptieren.

  4. ol>

    Denken Sie daran, es geht nicht um if stark> ein Verstoß wird auftreten, aber wenn ein Verstoß eintreten wird.

Dein letzter Satz sollte wirklich der erste sein.
JimmyJames
2018-02-24 04:12:40 UTC
view on stackexchange narkive permalink

Ja, mehrere Dinge. Das Speichern von Passwörtern im Klartext ist offensichtlich eine schlechte Idee. Das Verschlüsseln ist besser, aber normalerweise werden Passwörter überhaupt nicht gespeichert. Stattdessen wird ein irreversibler Hash gespeichert.

Das größere Problem hierbei ist jedoch, dass die Verwendung eines Benutzerkennworts zum Ausfüllen von Formularen bedeutet, dass nicht bekannt ist, wer was mit diesen Kennwörtern gemacht hat. Angenommen, einer der Benutzer in Ihrem Kundenstamm macht etwas falsch, sogar illegal. Sie behaupten, es muss jemand in Ihrer Organisation gewesen sein. Können Sie beweisen, dass es nicht war? Die Benutzer wissen, dass Sie Zugriff auf die Kennwörter haben, oder?

Und wie in den anderen Antworten erwähnt, ist es viel wahrscheinlicher, dass Dritte diese Anmeldeinformationen abrufen und verwenden können. In diesem Fall ist Ihre Organisation möglicherweise erneut das Ziel der Schuld.

Wenn ich Sie wäre, würde ich jedem, dem Sie zuhören können, die Risiken erklären. Wenn ich das richtig verstehe, gelten diese Anmeldeinformationen für Systeme von Drittanbietern. Im Idealfall verfügen Sie über Konten auf den Systemen, die für Ihre internen Benutzer bestimmt sind. Wenn Sie dies nicht tun können, sollten Sie versuchen, eine Implementierung zu verwenden, die verhindert, dass Personen in Ihrer Organisation die Kennwörter und Protokolle sehen können, wenn sie auf jedes System zugreifen.

Bergi
2018-02-24 03:54:26 UTC
view on stackexchange narkive permalink

Wenn Sie sich bei einem anderen fremden Konto anmelden müssen, benötigen Sie dessen Benutzernamen und Passwort. Daran führt kein Weg vorbei. Sie können 1 sup> nicht hashen oder verschlüsseln, Sie benötigen die einfachen Werte.

Das ist natürlich ein Albtraum, da die Benutzer Ihnen ihre Anmeldeinformationen mitteilen müssen. Sie vertrauen darauf, dass Sie sie nicht missbrauchen. Angenommen, Sie missbrauchen sie nicht absichtlich (wie den Verkauf auf dem Schwarzmarkt als Teil Ihres Geschäftsmodells), müssen Sie Leckagen verhindern. Dazu gehört, dass Datenverletzungen in Ihrer Infrastruktur oder bei Datenbankadministratoren darauf zugreifen können. Die beste Vorgehensweise hier wäre also, sie überhaupt nicht zu speichern . Die Aufgabe Ihres Unternehmens besteht darin, dem Benutzer beim Ausfüllen von Formularen zu helfen und keinen Passwort-Manager-Service bereitzustellen. " den Benutzern das Erinnern zu erleichtern" ist nicht Ihre Aufgabe.

Eine Lösung könnte darin bestehen, eine Browsererweiterung zu schreiben, die Ihre Benutzer installieren können. Sie melden sich selbst auf ihrem Computer bei diesem ausländischen Konto an, und Ihr Plugin erledigt dort seine Arbeit. Ihr Server kommt nicht einmal mit den Anmeldeinformationen in Kontakt. (Natürlich muss der Benutzer der Erweiterung weiterhin vertrauen, um sie nicht auszuspionieren.)

Wenn dies keine Option ist und die Arbeit, einschließlich der Anmeldung, auf Ihrem Server ausgeführt werden muss, sollten Sie dies dennoch tun Speichern Sie die Benutzeranmeldeinformationen nicht. Leiten Sie sie einfach an den fremden Anmeldedienst weiter und speichern Sie das Sitzungstoken, das mit der API verwendet werden soll, nur so lange in Ihrer Datenbank, wie Sie es benötigen. Wenn die Datenbank verletzt wird, kann der Angreifer möglicherweise die Sitzungen entführen (schlimmer noch), erhält jedoch kein Klartextkennwort. Lassen Sie den Benutzer die Anmeldeinformationen erneut angeben, wenn sich Ihr Server mehrmals anmelden muss.

1: Natürlich sollten Sie immer vertrauliche Daten verschlüsseln, wenn Sie sie irgendwo speichern, aber Letztendlich muss sich der Schlüssel dazu irgendwo auf Ihrem Server befinden, auf den möglicherweise auch ein mutmaßlicher Angreifer Zugriff hat. sub>

Ich bin damit einverstanden, dass Sie sie nicht hashen können, aber ich sehe keinen Grund, warum Sie sie nicht verschlüsseln können.
@JonBentley Ich meinte "verschlüsseln, damit Sie es nicht selbst entschlüsseln können".Wenn Sie verschlüsselte Daten und den Entschlüsselungsschlüssel nahe beieinander halten, hilft dies nicht viel.Siehe auch die Fußnote.Wie kann ich das besser formulieren?
Wie kann man das nicht umgehen?Es kann ein System geben, das den Anmeldevorgang vollständig umgeht, indem mehrere Sicherheitsmaßnahmen angewendet werden, z. B.: (I) eine benutzerdefinierte URL für die Anmeldung, (ii) Bestätigungs-E-Mail, die an vertrauenswürdige E-Mail-Konten gesendet wird, (iii) die Notwendigkeit eines Hauptkennworts.Auf diese Weise können Support-Mitglieder zur Unterstützung auf die Kundenkonten zugreifen.
@hakermania: Können Sie Ihren Verweis auf ein "Master-Passwort" näher erläutern?ISTM, dass das Speichern eines Hauptkennworts genauso schlecht ist wie das Speichern einer Reihe einzelner Kennwörter, und das Ändern eines Systems zum * Akzeptieren * eines Hauptkennworts macht das System weniger sicher.
@Scott ja ich stimme dir zu.Ich sage nicht, dass es für alle Konten ein Hauptkennwort geben sollte!Ich sage nur, dass es in Kombination mit meinen anderen 2 Punkten verwendet werden kann, um eine sichere Implementierung zu haben
@hakermania Ich verstehe, dass das OP-Unternehmen Zugriff auf die Konten seiner Kunden auf ausländischen Systemen benötigt.Angenommen, diese fremden Systeme unterstützen den Zugriff durch Dritte nicht, müssen die Benutzeranmeldeinformationen bei der normalen Anmeldung verwendet werden.(Wenn es eine API für den Zugriff durch Dritte gibt, sollte diese natürlich verwendet werden.)Ich verstehe nicht, was Sie unter "benutzerdefinierte URL + vertrauenswürdige E-Mail + Hauptkennwort" verstehen.
@Bergi Sie haben Recht, ich habe die Frage falsch verstanden und dachte, OP spreche über Kunden ihrer Website
Das Hauptkennwort muss nicht gespeichert werden.Es kann immer wieder eingegeben werden, wenn jemand auf die Passwörter zugreifen möchte.Zumindest kann es in einer separaten Form gespeichert werden.So könnten beispielsweise die Passwörter auf einem Server gespeichert werden, während das Master-Passwort auf einem USB-Stick gespeichert ist.Nicht kinderleicht, aber mindestens eine weitere Fehlerquelle.
"Aber letztendlich muss sich der Schlüssel dazu irgendwo auf Ihrem Server befinden" - ich glaube nicht, dass dies ganz richtig ist.Eine Art Hardware-Sicherheitstoken (wie ein Yubikey, aber etwas anderes könnte besser sein) könnte den Entschlüsselungsschlüssel haben und abhängig von den Einschränkungen eine viel bessere Sicherheit bieten.
@Accumulation wer steuert den USB-Stick-Schlüssel (nimm mich an) und wer braucht die Passwörter (nimm dich an)?Was ist, wenn Sie über die Wochenenden arbeiten müssen, aber ich will nicht.Werde ich am Ende nur den Schlüssel am Server stecken lassen (kein wirklicher Vorteil, wenn ich ihn auf einen entfernbaren Stick stecke)?oder erstelle ich eine entschlüsselte Kopie für Sie (kein wirklicher Vorteil der Verschlüsselung)?oder gebe ich Ihnen einen USB-Stick (mehrere Schlüssel bedeuten, dass einer leichter verloren geht)?Wenn ein einzelner Berechtigungsnachweis 64 KB kostet, sollte ein 64-GB-Stick 8.000.000 Benutzer aufnehmen. Warum nicht einfach alle auf den Stick und nicht auf den Server legen?
@IanD.Scott das yubikey ist cool, aber ich sehe nicht, wie es das Problem des OP helfen würde.Eigentlich würde es das Geschäft des OP brechen.zB bin ich ein Benutzer.Ich habe OP dummerweise meine Benutzernamen- / Passwort-Anmeldeinformationen gegeben, damit OP einige Formulare für mich ausfüllen kann.Später melde ich mich bei yubikey an.Wenn OP nun versucht, sich in mein Konto einzuloggen, um Formulare auszufüllen, fordert es OP für den Yubikey heraus.
@emory Der Yubikey kann verschiedene Dinge tun;einschließlich gpg.Verschlüsseln Sie Passwörter mit gpg ('pass' erledigt dies) und haben Sie den Entschlüsselungsschlüssel auf einem yubikey.
Einige Websites verwenden Cookies, um zu verhindern, dass der Benutzer zu oft aufgefordert wird, sein Kennwort einzugeben.Ich frage mich, ob das Erhalten eines Anmeldecookies vom Kunden nach dem Anmelden dem OP-Unternehmen tatsächlich Zugriff auf die Website gewähren kann, ohne das Passwort des Kunden kennen zu müssen.
@LucaCiti Ja, das ist das * Sitzungstoken *, über das ich gesprochen habe.Aus Sicht der Benutzerfreundlichkeit können Sie einen Benutzer jedoch nicht auffordern, die devtools zu öffnen und einen Cookie-Wert nachzuschlagen.
Tom
2018-02-26 14:01:27 UTC
view on stackexchange narkive permalink

Manager sprechen die Geschäftssprache und nicht die Technologie.

Schätzen Sie das Risiko ein, dem Ihr Unternehmen mit diesen Praktiken ausgesetzt ist, ausgedrückt in Währung (USD, EUR, was auch immer) Ist angemessen). Dafür gibt es verschiedene Methoden. Ein guter Ansatz besteht darin, sowohl ein realistisches als auch ein Worst-Case-Szenario abzuschätzen. Wenn Sie einem Manager mitteilen, dass eine Wahrscheinlichkeit von 10% pro Jahr für einen Sicherheitsvorfall besteht, der das Unternehmen bis zu 5 Millionen Schaden kosten könnte, sollte dies sein Ohr bekommen.

Zusätzlich zu potenziellen Schäden aus Vertragsansprüchen gegen Sie durch Bei Ihren Kundenunternehmen sollten Sie sich auch mit zivil- und strafrechtlichen Verantwortlichkeiten befassen, die durch grobe Fahrlässigkeit verursacht wurden. Die Möglichkeit, ins Gefängnis zu gehen, ist eine andere Sache, die die Aufmerksamkeit des Managers auf sich zieht.

Wenn in Ihrem Unternehmen ein Risikomanagement vorhanden ist, sollten Sie sich mit den Mitarbeitern von dort über Methoden und Schätzungen abstimmen seriöser.


Die minimale Vorsichtsmaßnahme besteht darin, einen Passwort-Manager oder ein anderes System zu verwenden, das a) die verschlüsselten Passwörter speichert und b) nur das Passwort entschlüsselt erforderlich, wenn erforderlich.

Idealerweise würden Sie zu einer zertifikatbasierten Methode wechseln, dies hängt jedoch auch von Ihren Clients ab und liegt nicht vollständig in Ihrer Kontrolle.

Sie sollten dies auch tun Verfügen Sie über eine Kennwortbehandlungsrichtlinie , die dokumentiert, wie Kennwörter behandelt werden, und die Strafen für Verstöße enthält. Ausgangsfilter können eine E-Mail-Katastrophe verhindern.

Es ist leicht zu erklären, dass ein Risiko besteht, dass die Folgen schwerwiegend sein können und dass dieses Risiko leicht gemindert werden kann.Eine genaue Bewertung (10% pro Jahr) ist jedoch viel schwieriger.Die Antwort könnte lauten: * Wir machen das seit 5 Jahren und immer noch kein Problem, daher macht Ihre Bewertung keinen Sinn *.
Eine ** Schätzung ** der Wahrscheinlichkeit ist eine absolute Notwendigkeit, um das Risiko abzuschätzen.Natürlich ist es eine Schätzung, aber Sie sollten in der Lage sein, zumindest einen Bereich anzugeben.Wenn es Ihnen hilft, können Sie es umkehren und nicht% pro Jahr, sondern MTBF angeben - alle wie viele Jahre erwarten Sie dies?
Zweitens ist das "bisher ist nichts Schlimmes passiert" ein häufiger Irrtum.Es ist genau der Gedanke, den die Menschen am Tag vor der Explosion in Tchernobyl hatten.Wenn erwartet wird, dass alle 5 Jahre etwas passiert und Sie 5 Jahre ohne es hatten, ist es Zeit, nervös zu werden, weil Sie überfällig sind.Die richtige Antwort ist jedoch, dass Sie diese Daten verwenden können, um Ihre Schätzung zu überarbeiten.
Wenn es einen Verstoß gibt, wird der OP-Chef in dieser Reihenfolge (1) nichts davon wissen, (2) seine Auswirkungen minimieren, (3) Kreditüberwachung kaufen, (4) Insolvenz anmelden.Es besteht eine 90% ige Wahrscheinlichkeit, dass es nicht über Stufe 1 hinausgeht. Es ist äußerst unwahrscheinlich, dass es über Stufe 2 hinausgeht. Im schlimmsten Fall, Stufe 4, werden die Auftraggeber nicht wesentlich betroffen sein.
Ich denke, wenn Sie einen Business Case erstellen möchten, müssten Sie eine Schätzung des Größenmarkts abgeben, die sich einfach weigert, Ihnen ihre Anmeldeinformationen zu geben (z. B. ich).Das Unternehmen von OP wirft einfach das Marktsegment weg, das keine Sicherheitsidioten sind.Dies würde jedoch eine vollständige Überarbeitung des Prozesses erfordern.
Criggie
2018-02-24 05:32:47 UTC
view on stackexchange narkive permalink

Ja, das Speichern von Klartextkennwörtern ist dumm. Wir hatten sogar einen Mitarbeiter, der versehentlich alle "gespeicherten" Passwörter bei einem Copy-Paste-Unfall per E-Mail an eine interne Verteilerliste schickte. Glücklicherweise waren keine Kunden auf der Liste.

Daher haben wir Teampass verwendet, das sehr gut als zentralisierte Datenbank mit Kennwortinformationen funktioniert.

Es ermöglicht auch Gruppen mit unterschiedlichen Zugriffsebenen und jeder Benutzer kann seine eigenen privaten Kennwörter speichern, die niemand sonst lesen kann.

Es handelt sich um eine Einrichtung eines einzelnen Kennwortmanagers, bei dem jeder eine Kopie der Kennwörter lokal aufbewahrt. Wenn also das Kennwort für einen Dienst aktualisiert wird, sieht jeder dieses Update.

Der Verlauf wird ebenfalls beibehalten, sodass Sie die vorherigen Kennwörter für Dienst X abrufen können (möglicherweise wurde ein Host nicht aktualisiert, und Sie müssen dies tun zurück in die Zeit)

https://teampass.net/

AnoE
2018-02-25 16:54:43 UTC
view on stackexchange narkive permalink

Ein anderer Winkel mit Ausnahme des Offensichtlichen (den Sie bereits kennen, wie Sie in der Frage zeigen - das Speichern unverschlüsselter Passwörter ist schlecht):

Das Nicht-Teilen / Vergeben von Passwörtern ist oder sollte einer der ersten sein Aufzählungspunkt in einer Sicherheitsrichtlinie. Keine vernünftige Bank, kein Online-Dienst oder irgendein Unternehmen wird jemals nach einem Passwort fragen. Dies ist aus guten Gründen in jedem Benutzer verankert.

Wenn ich Ihr Kunde wäre und Ihr Arbeitgeber mich nach einem Passwort fragen würde, würde ich es Ihnen a) nicht geben und b) zu meinem laufen Management ziemlich schnell. Ich würde sehr versuchen sicherzustellen, dass wir nicht länger Ihr Kunde sind.

Ich gebe mein Passwort nicht einmal an meine eigenen Support-Mitarbeiter weiter (in dem unwahrscheinlichen Fall, dass ich mich für sie anmelden muss während einer Support-Sitzung werde ich dies selbst tun). Ich habe Sicherheitsüberprüfungen (für Systeme und / oder Anwendungen) erhalten und nie wurde ein tatsächliches Benutzerkonto an die Sicherheitsfirma übergeben. Wenn sie sich anmelden müssen, erhalten sie ihre eigenen temporären Konten. Ich hatte Kunden, die versuchten, mir ihr Passwort mitzuteilen, und ich stelle ziemlich sicher, dass sie sofort unterbrochen werden und sie es selbst eingeben.

TL; DR: Sie können Ihrem Management diese Antwort gerne zeigen - ich würde es tun Seien Sie ein Kunde, der für Sie verloren ist.

Es ist [nichts Falsches daran, Passwörter aufzuschreiben] (https://www.schneier.com/blog/archives/2005/06/write_down_your.html), wenn Sie sie an einem sicheren Ort aufbewahren.
@Bergi, gut, OP sagte, dass sie es an einem unsicheren, unverschlüsselten Ort tun.Aber ich habe zwei Wörter entfernt, um klar zu machen, dass es in meiner Antwort überhaupt nicht darum geht, sondern um den Aspekt des "Identitätsaustauschs".Und ich halte fest an dem Vorschlag fest, dass es nicht in Ordnung ist, Passwörter herauszugeben, die mit echten Identitäten verknüpft sind, unabhängig davon, wo die PWs dann gespeichert werden.
Simba
2018-02-26 19:32:01 UTC
view on stackexchange narkive permalink

Die beste Antwort ist, die Anmeldeinformationen Ihres Kunden überhaupt nicht zu haben oder zu verwenden. Das Anfordern von Kunden bei ihnen ist ein massives Sicherheits-Nein-Nein und sollte für jeden bei Ihren Kunden, der über Sicherheitskenntnisse verfügt, rote Fahnen setzen.

Tatsächlich würde ich Sagen Sie, dass Sie damit wahrscheinlich Ihr Geschäft bereits bei potenziellen Kunden verlieren, die irgendeine Art von Sicherheitsrichtlinie haben. Mein eigener Arbeitgeber hat eine strikte Passwortrichtlinie und es wird wahrscheinlich als Kündigungsgrund angesehen, wenn ich eines unserer Passwörter mit Ihnen teile.

Ein weiterer wirklich wichtiger Faktor, den niemand sonst angesprochen hat, ist die Rechenschaftspflicht . Durch das Teilen eines Passworts mit Ihnen hat sich der Kunde potenziellen Problemen geöffnet, falls das Konto jemals missbraucht wird. Möglicherweise ist ein betrügerischer Mitarbeiter im Unternehmen schuld, aber wenn das Passwort geteilt wurde, eröffnet sich eine Möglichkeit plausibler Verleugnung. Sie können Sie verdächtigen und die Untersuchung erheblich erschweren.

Sie müssen sich jedoch an dieser Remote-Site anmelden, um zu sehen, was sie tun, damit Sie ihre Konformität überprüfen können Sie umgehen das, ohne ihre Passwörter zu haben?

Hier gibt es eine Reihe von Optionen. Sie alle erfordern mehr Arbeit als jetzt, aber das müssen Sie akzeptieren.

  1. Finden Sie heraus, ob die Remote-Site Account-Spoofing oder Mehrbenutzer anbietet Konten. In diesem Fall sollte es Ihnen möglich sein, auf dieselben Informationen zuzugreifen, ohne dieselben Anmeldeinformationen verwenden zu müssen. Entweder der Site-Anbieter oder der Client sollten einen zusätzlichen Satz von Anmeldeinformationen nur für Sie einrichten, um Zugriff auf die Daten des Clients auf der Site zu erhalten. Diese Anmeldung unterscheidet sich von der Hauptanmeldung des Clients, und das Kennwort für die Anmeldung liegt allein bei Ihnen, sodass keine Speicherprobleme auftreten. Idealerweise hätte dieses Konto für Sie die schreibgeschützten Berechtigungen reduziert, um das Risiko der Rechenschaftspflicht für Sie selbst zu minimieren.

  2. Besprechen Sie mit dem Anbieter des Remote-Standorts, ob er Ihnen eine Offline-Kopie der relevanten Daten zur Verfügung stellen kann. Dies kann in Form eines Datenbank-Dumps oder einer API oder einer Protokolldatei erfolgen. Was auch immer es ist, es würde nicht bedeuten, dass Sie sich tatsächlich beim Kundenkonto anmelden müssen. Sie können einfach die neueste Kopie der Daten von der Website anfordern und sie überprüfen, um herauszufinden, was Sie wissen möchten. Dies müsste natürlich mit dem Kunden vereinbart werden. Wenn der Site-Anbieter diese Einrichtungen nicht zur Verfügung hat, werden Ihnen möglicherweise die Kosten für deren Erstellung in Rechnung gestellt. Sie erhalten jedoch vollen Zugriff auf das, was Sie benötigen, während Sie isoliert bleiben Sie müssen sich nicht bei der eigentlichen Site anmelden.

  3. ol>
"Rechenschaftspflicht" wird durch die am besten gewählte Antwort abgedeckt
"Verlorene Kunden" wird auch durch eine andere Antwort abgedeckt
Ihr Vorschlag Nr. 1 ist nicht üblich, und da es scheinbar viele Entitäten gibt, ist er keine skalierbare Lösung.Abhängig vom Inhalt der Daten ist Ihr Vorschlag Nr. 2 möglicherweise schlechter als die Kenntnis des Passworts.
@schroeder - # 2 wäre nur schlimmer, wenn alle Beteiligten inkompetent wären.Es sollte höchstens genau die Daten liefern, die beim Anmelden sichtbar sind.nicht mehr und vorzugsweise weniger, um nur das abzudecken, was tatsächlich benötigt wird.Wenn der Anbieter Ihnen einen Speicherauszug der gesamten Datenbank sendet, ist das ein größeres Problem, aber man würde hoffen, dass der Anbieter es besser weiß als dies zu tun, und das Unternehmen des OP würde es besser wissen, als danach zu fragen.
Auch bezüglich "* es scheint viele Entitäten zu geben *" ... tatsächlich habe ich den Kommentar des OP gelesen, um zu bedeuten, dass nur eine Entität eines Dritten beteiligt war;er sagte * "Es ist eine Webseite, auf die wir gehen und uns anmelden" *.Wenn es beim Lesen einzigartig ist, sollten diese Lösungen perfekt funktionieren.Auch wenn es sich um eine kleine Anzahl von Websites handelt, sollte dies machbar sein.Ja, es lässt sich nicht gut skalieren, wenn es eine große Anzahl von Websites und unterschiedliche Websites für jeden Client gibt, aber so wird es nicht gelesen.
"Wir müssen uns bei ihren verschiedenen Konten für verschiedene Entitäten anmelden" Der Kommentar, auf den Sie sich beziehen, bezieht sich auf den Systemtyp, was bedeutet, dass die Verwendung des Singulars in Ordnung ist, um auf einen * Systemtyp * zu verweisen.Ich glaube nicht, dass Sie den Inhalt des Hauptpostens durch den Kommentar ersetzen können.
HTLee
2018-02-26 20:06:24 UTC
view on stackexchange narkive permalink

Die FTC hat Unternehmen wegen solcher schlechten Praktiken verfolgt ( siehe Abschnitte 3 & 4) und sie finanziell und öffentlich beschimpft.

Die FTC hat auch die Schutzregel, die einige Hinweise gibt (einige hochrangige technische, aber hauptsächlich verfahrenstechnische Praktiken). Obwohl es sich um Finanzorganisationen handelt, ist ihre Definition ziemlich weit gefasst - auf jeden Fall ein guter Ausgangspunkt.

Ihr erster Link gilt nicht für die Situation des OP, wenn die Passwörter sicher gespeichert und übertragen werden
Ihr zweiter Link scheint ebenfalls nicht zuzutreffen
Der erste Link wurde aktualisiert, sodass er ein umfassenderes Problem der sicheren Speicherung (d. H. Keinen Klartext) umfasst.Der zweite Link bezieht sich auf die Speicherung vertraulicher Informationen (von denen wir annehmen können, dass sie Kontoinformationen enthalten), die geschützt werden sollten.cc @schroeder
Ich habe diese Abschnitte gelesen und sie gelten immer noch nicht.Sie strecken sich, um etwas Passendes zu machen.Ich kann diese Anforderungen durch die Verwendung der vollständigen Festplattenverschlüsselung erfüllen.Ja, das OP befindet sich in einer schlechten Situation. Diese Links sind jedoch nicht nützlich, um bessere Maßnahmen zu ergreifen.
Neben den Punkten von schroeder gilt dies nur, wenn sich das OP in den USA befindet.Etwas, von dem ich nicht glaube, dass wir wissen.


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 3.0-Lizenz, unter der er vertrieben wird.
Loading...