Frage:
Was sind die Nachteile von zustandslosen Passwortgeneratoren?
Cookiecutter
2019-07-30 00:13:01 UTC
view on stackexchange narkive permalink

Hat jemand praktische Erfahrung mit zustandslosen Passwortgeneratoren (Managern) wie Getpass?

Es scheint, als würde es den größten Teil der Arbeit von Cloud-Passwortmanagern erledigen, lehnt sich aber an mehr zur Sicherheitsseite, da es keine Server mit Passwörtern gibt, in die man eindringen kann.

Es gibt viele Passwortmanager, die lokalen Speicher verwenden.Sie können diese mithilfe eines Cloud-Dienstes Ihrer Wahl (Dropbox, Box, iCloud, Drive, OneDrive usw.) oder gar nicht synchronisieren.Es liegt an dir
"neigt mehr zur Sicherheitsseite" - das ist keine faire Einschätzung.Sie alle lehnen sich an die Sicherheitsseite an - diese Art von Tool verfügt über eine Funktion, die eine Art von Risiko mindert.
Wenn es nicht vom Zustand abhängt, wovon hängt es ab?Enthält das eine Sicherheitslücke?
Ich benutze Keepass.Einer der schönen Vorteile ist, dass meine Passwörter nicht einfach gespeichert werden.Ich kann viele andere Daten zu einem bestimmten Konto speichern, einschließlich "Anhänge".Offensichtlich kann ein zustandsloser Passwort-Manager nur für Passwörter verwendet werden, was für mich eine ziemlich große Einschränkung darstellt
@Alexander Dropbox hat kürzlich seinen kostenlosen Plan geändert, um ihn auf 3 Geräte zu beschränken. Früher war er perfekt für die Synchronisierung von Keepass.iCloud ist nur Apple, Google Drive ist meh, OneDrive basiert auf Microsoft.
@JMK gibt es auch mega.nz (Der Besitzer wurde in der Vergangenheit vom FBI verbrannt und hat die Lektion gelernt. Es ist jetzt ein paranoider Dienst, der sich auf die Privatsphäre der Benutzerdaten konzentriert: Sie möchten nicht wissen, was Sie auf ihren Daten speichernService, damit sie nicht für das Hosting verantwortlich gemacht werden. Wenn ihr Webcrawler einen privaten Schlüssel findet, löschen sie die zugehörigen Daten automatisch, ohne sie zu untersuchen.)
Wenn Sie Cloud-Diensten nicht vertrauen, können Sie eine lokale Kennwortdatenbank (z. B. von KeePass) zwischen Ihren Geräten mithilfe eines Synchronisierungsprogramms wie Syncthing oder Resilio Sync synchronisieren.
@JMK Ich schaffe es, auf genau 3 Geräten zu bleiben und meine KeePass-Datei über Dropbox zu synchronisieren.Aber es gibt noch einen weiteren Nachteil: Der Android-Client lädt geänderte Dateien nicht automatisch hoch.Es gibt Clients von Drittanbietern, die dies tun.Bis sie kaputt gehen.
Sechs antworten:
Benoit Esnard
2019-07-30 00:24:47 UTC
view on stackexchange narkive permalink

Ich habe jahrelang einen zustandslosen Passwortgenerator verwendet, und ich denke, es gibt viele Nachteile:

  • Wenn Ihr Hauptpasswort kompromittiert ist, sind alle Ihre Passwörter. Im Vergleich dazu erfordern Standard-Passwortmanager, dass der Angreifer sowohl den Hauptschlüssel kompromittiert als auch Zugriff auf den Passwortspeicher erhält.
  • Wenn eine Website über eine Passwortrichtlinie verfügt, können Sie dies tun Es ist nicht möglich, ein Kennwort zu generieren, das dies berücksichtigt.
  • Wenn eines der Kennwörter aus irgendeinem Grund aktualisiert werden muss, müssen Sie diesen Status irgendwo beibehalten. Sie müssen beispielsweise daran denken, ein Kennwort für "StackExchange2" anstelle von "StackExchange" zu generieren.
  • Wenn Sie bereits einige Kennwörter haben, die Sie (aus verschiedenen Gründen) nicht ändern können, einen statischen Kennwortgenerator wird Ihnen nicht helfen.

Aus all diesen Gründen sollten Sie auf jeden Fall Standard-Passwort-Manager verwenden.

Vielen Dank!Sie haben also zu einem Standard-Passwort-Manager gewechselt?Es scheint mir, dass alle außer Ihrem letzten Punkt gelöst werden können, indem diese Daten an eine Website-Variable gebunden werden
Der größte Vorteil des zustandslosen Passwort-Managers besteht darin, dass Sie keine zusätzliche Datei aufbewahren müssen.Wenn Sie ohnehin eine zusätzliche Datei für all diese ortsspezifischen Variablen verwalten müssen, ist die Verwendung des zustandslosen Kennwortmanagers nicht mehr sinnvoll.
@LieRyan in der Tat.Wenn Sie eine dieser Optionen verwenden, müssen Sie alle Computer und Geräte manuell synchronisieren, indem Sie Dateien verschieben.Im besten Fall umständlich, im schlimmsten Fall ein ernstes Sicherheitsproblem und möglicherweise unmöglich (angesichts der Einschränkungen in sicheren Umgebungen bei der Einführung externer Dateien).
Der Lat Con könnte der schlimmste von allen sein.Könnte gut sein, dieses oben zu sortieren und es stärker hervorzuheben, da die Leute einige wirklich schreckliche Passwörter verwenden, auch für Passwortmanager, und während ein Passwortmanager selbst kompromittiert werden müsste (ohne die Passwortdatenbank ist das Master-Passwort nutzlos).Hier wäre ein Kompromiss des Schlüssels katastrophal, und der Schlüssel kann von jedem Websitebesitzer brutal erzwungen werden, wenn er dies wünscht (und wenn er eine korrekte Annahme über Ihre Passwort-Hashing-Einstellungen macht, die nach Kerckhoffs Prinzip nicht geheim sind).
@Luc aber der letzte Nachteil ist nicht so groß, weil in den meisten Fällen die verschlüsselten Passwörter irgendwo online gespeichert werden.Und was auch immer das ist, es ist entweder nur das Hauptkennwort selbst oder durch ein zweites Kennwort gesichert - das der Benutzer zusammen mit dem Hauptkennwort speichern muss (also letztendlich nur ein längeres Hauptkennwort, das gestohlen wirdermöglicht den Zugriff auf alle Passwörter)
Ich rolle meinen eigenen zustandslosen Passwort-Manager (https://vks.ai/ppm) und hatte keine Probleme.Nur die Tatsache, dass mein Master-Passwort jemals kompromittiert würde und die Leute technisch versiert genug sind, um es zu missbrauchen.Aber das ist ein Risiko, das ich eingehen möchte.Adressierung der Punkte: Ich hatte bisher noch nie ein Problem, bei dem meine Methode nicht der Kennwortrichtlinie entsprach (und ich verwende sie seit einigen Jahren).Das Coole an StackExchange und dann an StackExchange2 ist, dass Sie sich normalerweise an die Nummer erinnern.Aber wenn Sie dies nicht tun, können Sie es innerhalb von 3 Versuchen leicht brutal erzwingen (der höchste Wert, den ich erreicht habe, ist 5).
@PascalVKooten möchten Sie vielleicht in Betracht ziehen, sich an eine zu halten, die ordnungsgemäß überwacht wurde. Mit Ihrer aktuellen Implementierung können Regenbogentabellen pro Standort eingerichtet werden, um das Hauptkennwort zu knacken
@Qwerty01 Das Knacken wäre zu langsam oder zu teuer - das ist die Idee einer langsamen Hashing-Funktion wie Scrypt und eines langen Master-Passworts.Dadurch ist es sinnlos, einen Regenbogenangriff zu versuchen.
@PascalVKooten Der Sinn einer Regenbogentabelle besteht darin, einmal teure Berechnungen durchzuführen. Das Einzige, was andere derzeit davon abhält, ist, dass Ihre Implementierung nicht weit genug verbreitet ist, um sie rentabel zu machen.
@Qwerty01 Sie verwenden Regenbogentabellen nur, wenn Sie die Berechnungen wiederverwenden können, was hier nicht der Fall ist.Beachten Sie jedoch, dass die Benutzer nicht versuchen werden, Regenbogentabellen für langsame Hashing-Funktionen zu erstellen, da dies einfach nicht erschwinglich wäre.Ja, die Idee klingt großartig ... die Berechnungen wiederzuverwenden ... aber langsame Hashing-Funktionen sind einfach zu teuer, um dies zu tun (es sei denn, Sie nehmen sehr kurze Master-Passwörter an).
@PascalVKooten Sie können es _ mit Ihrer Implementierung wiederverwenden ... das Salz, das Sie verwenden, ist der Site-Name, so dass jeder andere, der diese Site verwendet, das gleiche Salt hat.
@Qwerty01 Ja, aber das Salz ist in der Tat kein Geheimnis.Aus Sicherheitsgründen wird das Hauptkennwort vollständig verwendet.Nehmen wir also an, Sie kennen meinen Site-Namen (und alle anderen verwenden ihn auch). Sie müssen immer noch so viele teure Berechnungen durchführen, dass es sich nicht lohnt.
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (https://chat.stackexchange.com/rooms/96816/discussion-between-qwerty01-and-pascalvkooten).
Betreff: Punkt 3, LessPass (ein weiterer zustandsloser Kennwortmanager) unterstützt Optionen, die gehasht und als Teil der Generierung verwendet werden.Eine solche Option ist eine Zahl, die Sie erhöhen können.Sie lösen das Problem, dass Sie sich erinnern müssen, indem Sie eine Datenbank mit Benutzernamen / Site / Optionen führen können. Die Kennwortgenerierung selbst ist jedoch zustandslos und die Datenbank ist nur eine Annehmlichkeit
* "Standard-Passwort-Manager müssen sowohl die verschlüsselten Passwörter als auch den Hauptschlüssel kompromittieren." * - Ich verstehe das nicht.Sicherlich muss nur der Hauptschlüssel kompromittiert werden (plus möglicherweise ein MFA), da der Benutzer nur den Hauptschlüssel (+ MFA) eingeben muss, um auf die verschlüsselten Passwörter zuzugreifen.Andernfalls klingt es so, als müssten die Benutzer bei den von Ihnen verwendeten Standardkennwortmanagern alle Kennwörter speichern, um auf ihre Kennwörter zugreifen zu können.Oder haben Sie gemeint, dass der Angreifer sowohl den Hauptschlüssel kompromittieren als auch Zugriff auf die Datenbank erhalten muss?
@8bittree: Wenn ich Ihnen meinen Hauptschlüssel mitteilen würde, könnten Sie nichts tun, es sei denn, Sie haben bereits Zugriff auf meine verschlüsselte Kennwortdatenbank: Sie können nichts entschlüsseln, was Sie nicht haben.Deshalb sind beide notwendig!
@BenoitEsnard Die Verwirrung hier ist wahrscheinlich darüber, was einen "Standard" -Passwortmanager ausmacht.Es könnte besser sein, expliziter zu sein, z."Dateibasierter Passwort-Manager", um sich von einem "Cloud-basierten Passwort-Manager" wie 1Password zu unterscheiden, bei dem Sie remote auf die Datenbank zugreifen.
@BenoitEsnard Das macht mehr Sinn.Ich schlug eine Änderung vor, die meiner Meinung nach den Wortlaut klarer macht.
@BenoitEsnard, aber die meisten Benutzer kopieren die Datei nicht jedes Mal von Hand auf alle Geräte, die sie verwenden, wenn sie sich für eine neue Seite registrieren.Sie speichern die Datei höchstwahrscheinlich irgendwo online, wo Sie mit Ihrem Master-Passwort darauf zugreifen können.Es muss also nur eines kompromittiert werden, oder Sie haben große Probleme beim Übertragen von Dateien über USB.
Sjoerd
2019-07-30 13:04:40 UTC
view on stackexchange narkive permalink

Hier sind zwei weniger häufig erwähnte Probleme.

  • Es ist schwierig, die Website zu bestimmen. Sie möchten ein anderes Passwort für a.github.io und b.github.io verwenden, aber Sie möchten dasselbe Passwort für microsoft.com und live.com oder wikipedia.org und wikimedia.org.
  • Wenn Sie etwas ändern, werden Passwörter beschädigt. Sobald Sie Ihren Passwort-Manager freigegeben haben und die Benutzer ihn verwenden, können Sie nichts mehr daran ändern oder Benutzer können sich nicht mehr anmelden. Die Art und Weise, wie Domains behandelt werden, muss gleich bleiben, auch wenn Domains den Besitzer wechseln. Die Art und Weise, wie Passwörter gehasht werden, muss gleich bleiben, auch wenn im Algorithmus eine Sicherheitsanfälligkeit entdeckt wird.

Siehe auch mein Blog-Beitrag dazu.

Wenn Sie eine optionale neue Version veröffentlichen, müssen Benutzer ihre Kennwörter auf allen Seiten einmal ändern, um die neue Version zu verwenden.Es würde keinen Spaß machen, könnte aber gemacht werden.- Ich würde wahrscheinlich das Gleiche tun, wenn mein Master-Passwort mit einem dateibasierten Passwort-Manager kompromittiert würde (da die Datei normalerweise irgendwo online verfügbar ist).
Kolappan N
2019-07-30 08:47:55 UTC
view on stackexchange narkive permalink

1. Kennwortmanager bieten zusätzliche Optionen

Ein wesentlicher Unterschied zwischen der Verwendung eines zustandslosen Kennwortmanagers und eines Kennwortmanagers besteht darin, dass Kennwortmanager zusätzliche Daten wie

  • Sicherheit speichern können Fragen
  • Kredit- / Debitkartennummern
  • ID-Kartennummern
  • Kryptografische Schlüssel
  • WiFi-Passwörter
  • API-Schlüssel , etc ...

2. Vorhandene Kennwörter können nicht berücksichtigt werden.

Kennwortmanager können vorhandene Kennwörter aufnehmen. Ein zustandsloser Kennwortmanager zwingt Sie jedoch dazu, Kennwörter für alle vorhandenen Websites zu ändern.

Dies ist sehr wichtig, wenn Sie Kennwörter für ein Konto speichern möchten, für das Sie nicht berechtigt sind, das Kennwort zu ändern. Dies kann ein freigegebenes Office-Postfach, ein Serverkennwort usw. sein.

3. Deterministische Kennwortgeneratoren können keine unterschiedlichen Kennwortrichtlinien berücksichtigen.

Einige Websites benötigen obligatorische Symbole mit Kennwörtern, auf einigen Websites sind jedoch keine Symbole in Kennwörtern zulässig. Einige Websites wie Payback unterstützen nur numerische PINs.

Benutzer müssen entweder das generierte Kennwort anpassen oder Einstellungen ändern. In beiden Fällen müssen sie die Optimierung oder die Einstellungen im Speicher behalten, was nicht gut ist.

Für # 3 müssen Sie auch aufzeichnen, wie die Kennwortrichtlinie beim Erstellen des Kennworts lautete.Ich habe mindestens ein Konto, in dem mein Passwort gegen die neue Passwortrichtlinie verstößt, aber das alte ist immer noch gut.
Daniel Darabos
2019-07-30 20:16:23 UTC
view on stackexchange narkive permalink

Neben den bereits erwähnten besteht ein weiteres Problem darin, dass Sie Ihr Hauptkennwort nicht ändern können . Um zu einem neuen Hauptkennwort zu wechseln, müssen Sie Ihr Kennwort auf allen Websites ändern, auf denen Sie den Generator verwendet haben.

MechMK1
2019-07-30 00:45:01 UTC
view on stackexchange narkive permalink

Das Problem ist, dass dadurch nicht so viel sinnvolle Sicherheit hinzugefügt wird.

Anstatt Ihr Passwort direkt zu verwenden, verwenden Sie anstelle Ihres Passworts eine öffentlich verfügbare Funktion. Verwenden wir das Beispiel auf ihrer Website für eine Demonstration:

Login: andromeda
Website: milkyway.com
Geheimes Schlüsselwort: 2,52 m Lichtjahre entfernt

Erzeugt ein Passwort: 3q_q(MFWaMGeao+[CX

Sie können 3q_q (MFWaMGeao + [CX code) sagen > ist Ihr Passwort, aber es ist wirklich nicht. Es ist tatsächlich 2,52 m Lichtjahre entfernt , was nicht sehr entropisch ist. Ist es besser, als nur 2,52 m Lichtjahre entfernt code zu verwenden >? Ja, aber nicht so viel.

Verwenden Sie stattdessen einen Offline-Passwort-Manager und generieren Sie ein tatsächlich zufälliges Passwort. Es ist ungefähr so ​​viel Arbeit für Sie und gibt Ihnen viel mehr echte Sicherheit.

Um fair zu sein, "2,52 m Lichtjahre entfernt" allein ist nicht Ihr Passwort.Es ist "2,52 m Lichtjahre entfernt" plus das Wissen, dass Sie Getpass verwenden.Zugegeben, diese zweite Komponente ist ziemlich einfach zu erzwingen, da sie nur ein kleiner Multiplikator der ersteren ist (da es nur eine Handvoll populärer Algorithmen zur Passwortgenerierung gibt
@Alexander https: // en.wikipedia.org / wiki / Kerckhoffs% 27s_principle
-1 "Es gibt Ihnen keine zusätzliche Sicherheit" ist nicht wahr.Die Sicherheitseigenschaften ähneln dem allgemeinen clientseitigen Hashing (was die gesamte Software sowieso tun sollte) und sind sogar etwas stärker.Es ist keine perfekte Lösung, aber auch nicht nutzlos.
Es gibt Ihnen zusätzliche Sicherheit, vorausgesetzt, Ihr Master-Passwort * ist * sehr entropisch.Ein zustandsloser Passwort-Manager verhindert die (allzu häufige) Situation, dass eine Website, auf der Ihr Passwort im Klartext gespeichert ist, kompromittiert wird und dasselbe Passwort verwendet wird, um sich bei anderen Websites anzumelden, die Sie häufig verwenden (ja, die Wiederverwendung von Passwörtern ist schlecht, aber eineEin gewöhnlicher Mensch kann sich nicht mehr als 2 oder 3 Passwörter mit hoher Entropie merken.
@Luc Ich würde wetten, dass die durch die Verwendung von getpass gewonnene Sicherheit erheblich geringer ist als die Verwendung eines tatsächlich zufälligen Passworts.
@James_pic Gegen die Wiederverwendung von Passwörtern ** ist der ganze Punkt ** bei der Verwendung eines Passwort-Managers.
@MechMK1 ja, und solange das Hauptkennwort genügend Entropie aufweist, wirkt ein zustandsloser Kennwortmanager immer noch der Wiederverwendung von Kennwörtern entgegen.
@James_pic Ja und nein.Wenn Sie davon ausgehen, dass ein Passwort / eine Passphrase stark genug ist, um nicht geknackt zu werden, können Sie dieses Passwort genauso gut für alles verwenden und nicht zu viel verlieren.Ja, Sie sind in Gefahr, dass Websites Klartext-Passwörter verwenden, aber diese sterben sehr schnell aus.Selbst die schlimmsten Straftäter verwenden jetzt mindestens MD5.
@MechMK1 "* Ich würde wetten, dass die durch die Verwendung von getpass gewonnene Sicherheit erheblich geringer ist als die Verwendung eines tatsächlich zufälligen Passworts. *" Dies ist keine Wette, da haben Sie einfach Recht.Zufall ist eindeutig besser als abgeleitet.Trotzdem ist der Teil Ihrer Antwort "Es gibt Ihnen keine zusätzliche Sicherheit" nicht korrekt oder zumindest nuancierter.Wenn Sie das Klartext-Passwort verwenden, können Sie es nicht wiederverwenden.Durch das Senden eines gesalzenen Hashs (wobei der Site-Name das Salt ist) haben Sie für jede Site ein eindeutiges Anmeldetoken.Besser als das Passwort wiederzuverwenden, also definitiv keine zusätzliche Sicherheit.
Das ist mein Grund für die Ablehnung. Ich denke, es ist so falsch, dass es schädlich sein kann.Jemand möchte möglicherweise keinen Kennwortmanager verwenden (aus Gründen, die über den Rahmen dieses Kommentars hinausgehen), ist jedoch möglicherweise mit einem zustandslosen pwdgenerator in Ordnung.Sie könnten sie entmutigen und ihnen im Grunde sagen, dass sie stattdessen Klartexte verwenden sollen.Es ist also nicht persönlich, und wenn die Antwort geändert würde, um dies widerzuspiegeln (vorausgesetzt, Sie sehen die Logik meines Punktes), würde ich auch die Abstimmung ändern (vorausgesetzt, ich habe die Bearbeitung gesehen).
@Luc Ich habe den Wortlaut geändert, um dies widerzuspiegeln.Ich gab an, dass es nicht so viel Sicherheit hinzufügt, aber immer noch besser ist, als ein Passwort mit niedriger Entropie zu verwenden.
Ben
2019-07-31 22:01:44 UTC
view on stackexchange narkive permalink

Eine weitere, die ich nicht explizit erwähnt habe (zum Zeitpunkt des Schreibens machen alle vorhandenen Antworten auch gute Punkte):

Wenn ein Angreifer eines Ihrer generierten Passwörter erhält, kann er es jetzt versuchen Knacken Sie Ihr Hauptkennwort und erhalten Sie Zugriff auf alle Ihre Konten.

Es ist relativ einfach, ein geringwertiges Kennwort zu erhalten, sei es durch Phishing Klartext-Passwortlecks (selbst Google ist anscheinend nicht dagegen immun), Keylogging auf einem öffentlichen Computer, offenes WLAN auf Websites, die kein https verwenden usw. Der springende Punkt bei der Verwendung eines Passwort-Managers ist, dass die schlechte Sicherheit einer Website keinen Vorteil bieten sollte Sie auf einer anderen Site angreifen.

Sicher, ein ausreichend starkes Hauptkennwort kann verhindern, dass dies ein Problem darstellt. Ein "traditioneller" Passwort-Manager hat diesen Angriffsvektor jedoch überhaupt nicht.

+1 Dies ist der einzige Nachteil, der wirklich wichtig ist.Alle anderen sind bloße Unannehmlichkeiten.
Grundsätzlich stimme ich zu, aber ** wenn ** das Hauptkennwort ausreichend stark ist und der Kennwortmanager eine gute Einwegfunktion verwendet (idealerweise eine Kennwort-Hashing-Funktion wie Scrypt oder so), sollte es nicht einfach / brute sein-Macht.Dies ist jedoch die gleiche Diskussion darüber, warum wir normalerweise Passwort-Hashing auf Servern durchführen.Der einzige Unterschied besteht darin, dass Sie die Faktoren kontrollieren / kennen, die dazu beitragen, und (theoretisch) abschätzen können, ob ein Brute-Force-Angriff erfolgreich wäre.


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