Ein Problem bei dieser Art von Lösung, bei der ein vorhersagbarer Algorithmus verwendet wird, um ein Geheimnis aus einem Hauptkennwort / einer Hauptphrase zu generieren, besteht darin, dass Ihr Hauptkennwort direkt (z. B. Keylogger) oder indirekt (z. B. ein Angreifer mit einem Kennwort von) kompromittiert wird Ihr Angreifer, der über dieses System generiert wurde und einen Brute-Force-Angriff ausführen kann, hat die Sicherheit aller Ihrer Konten effektiv gefährdet, da er die von Ihnen für alle Websites verwendeten Kennwörter problemlos generieren kann.

Kurz gesagt, diese Methode bietet wenig bis gar keine zusätzliche Sicherheit gegenüber einem normalen Kennwortmanager (möglicherweise reduziert sie die Sicherheit je nach Implementierung) und weist mehrere Usability-Probleme auf, die sie unpraktisch machen.

Sicherheit

Nehmen wir Ihr Beispiel für Malware, indem Sie einen Keylogger verwenden, um Ihr Hauptkennwort abzurufen und dann alle Kennwörter in Ihrer Kennwortdatei zu gefährden. Ihr vorgeschlagenes Schema bietet keinen zusätzlichen Schutz gegen diesen Angriff: Wenn Ihr Hauptkennwort über einen Keylogger gestohlen wird, verfügt der Angreifer über alle Ihre Kennwörter für alle Dienste. (Hier müssen Sie nicht einmal eine Datenbank stehlen, sondern nur das Hauptkennwort.)

Eine weitere Bedrohung, die Sie erwähnt haben, waren die Entwickler Ihres Kennwortmanagers, die Ihre Sicherheit gefährdeten, indem sie ihren Kennwortmanager aktualisierten, um Ihr Hauptkennwort oder Ihr entschlüsseltes Kennwort zu stehlen Datenbank. Diese Bedrohung wird auch durch Ihr Schema nicht gemindert, da die Entwickler des Programms, mit dem Sie Ihre Kennwort-Hashes generieren, dasselbe tun könnten. (Ich gehe davon aus, dass Sie kein eigenes Hashing-Tool schreiben. Dies scheint fast so unpraktisch und fehleranfällig zu sein wie das Schreiben Ihres eigenen Passwort-Managers.)

Sie haben auch die Datenschutzprobleme bei Cloud-basierten Passwörtern erwähnt Manager wissen, wann Sie auf Ihre Passwörter zugreifen. Während diese Bedrohung durch Ihr vorgeschlagenes Schema gemindert wird, kann sie auch mit herkömmlichen Passwortmanagern gemindert werden, indem immer eine Kopie der Passwortdatenbank mit jedem lokalen Gerät synchronisiert wird und beim Nachschlagen von Passwörtern auf diese Datei verwiesen wird oder indem Ihre Passwortdatenbank einfach vollständig gespeichert wird offline. KeePass unterstützt beispielsweise beide Methoden.

Schließlich gibt es noch eine zusätzliche Bedrohung, der Sie durch dieses Schema ausgesetzt sind. Es ermöglicht jeder Site, für die Sie sich anmelden, oder jedem Angreifer, der die Kennwortdatenbank für eine solche Site erhält, eine unbegrenzte Anzahl von Offline-Brute-Force-Versuchen gegen Ihr Hauptkennwort durchzuführen. Dies kann durch die Verwendung eines starken Hauptkennworts und eines langsamen Hashing-Algorithmus gemildert werden, ist jedoch immer noch ein erwägenswertes Problem. Sie können es auch abschwächen, indem Sie einen Pfeffer in Ihren Hashing-Algorithmus aufnehmen. Dann verlieren Sie jedoch den Hauptvorteil Ihres vorgeschlagenen Schemas, indem Sie den Benutzer auf eine Datei mit dem Pfeffer zugreifen müssen, um ihre Kennwörter zu erhalten.

Benutzerfreundlichkeit

Wie Sie bereits bemerkt haben, hat dieses Schema den Vorteil, dass der Benutzer keine Kennwortdatenbank nachverfolgen muss. Es gibt jedoch einige Usability-Probleme bei diesem Schema, von denen ich glaube, dass sie diesen Vorteil bei weitem überwiegen.

Das erste ist, dass Ihr Kennwort für einen bestimmten Dienst kompromittiert wird (z. B. hat eine Site ihre Kennwörter im Klartext gespeichert Wenn die Datenbank gestohlen wurde oder das Kennwort während der Übertragung durch einen Mann im mittleren Angriff gestohlen wurde, haben Sie keine einfache Möglichkeit, das Kennwort für diesen Dienst zu ändern, ohne auch die Kennwörter für alle anderen Konten zu ändern (z. B. durch Ändern das Master-Passwort). Sie können dem Hash-Generator einen zusätzlichen Parameter hinzufügen, z. B. eine inkrementierende Nummer, damit Kennwörter geändert werden können. Anschließend müssen Sie diese Nummer jedoch für jeden Dienst speichern, was ziemlich unpraktisch ist.

Ähnlich: Wenn Ihr Hauptkennwort aus irgendeinem Grund kompromittiert wird, macht dieses Schema das Ändern dieses Kennworts ziemlich schwierig, da Sie nicht nur Ihr Kennwort auf jeder Site ändern müssen, auf der Sie ein Konto haben, sondern sich auch em merken müssen > Jede Site, auf der Sie ein Konto haben, um sicherzustellen, dass Sie beim Ändern Ihrer Passwörter keine verpassen - es gibt keine bequeme Auflistung all dieser Sites wie bei einem Passwort-Manager.

Ein weiteres Usability-Problem, das etwas weniger offensichtlich ist, aber aufgrund meiner Erfahrung mit Passwort-Managern glaube ich, dass dieses Schema möglicherweise auftritt, ist, dass es nicht immer offensichtlich ist, wie der "Name" jeder Site lautet, die Sie besuchen. Sie könnten denken, Sie könnten einfach den Domainnamen jeder Site in Ihren Hash-Algorithmus einfügen und diesen als Site-Namen verwenden, aber das ist eigentlich nicht immer der Fall. Betrachten Sie als einfaches Beispiel genau diese Site, Information Security Stack Exchange. Angenommen, Sie verwenden für diese Website ein kennwortbasiertes Login und kein Verbund-Login über einen Dritten wie Google oder Facebook. Was verwenden Sie für den Site-Namen in Ihrem Schema? security.stackexchange.com ? stackexchange.com ? stackoverflow.com ? Alle diese Domänen verwenden dieselbe Anmeldung. Und wenn Sie sich für einen Namen entschieden haben, müssen Sie sich daran erinnern. Andere Websites können dies noch weniger offensichtlich machen, z. B. gamepedia.com, für das Sie sich mit Ihrem Konto "Curse Community" anmelden müssen, das von mehreren Websites dieses Unternehmens gemeinsam genutzt wird.

Und schließlich sind Websites mit restriktiven Kennwortanforderungen möglicherweise das wichtigste Usability-Problem bei diesem Schema. Was ist, wenn für eine Site Ihr Kennwort ein Sonderzeichen enthalten muss, während für eine andere Site nur alphanumerische Zeichen verwendet werden müssen? Sie können Ihrem Hashing-Schema Optionen hinzufügen, um diesen Anforderungen gerecht zu werden. Jetzt müssen Sie sich die Kennwortanforderungen jeder Site merken und merken, wann immer Sie sich anmelden möchten.

TL; DR

Während Ihre vorgeschlagene Methode einige Probleme löst, erstellt sie auch andere und bietet keine zusätzliche Sicherheit.

Sicherheit:

• N / A: Schützt nicht vor Malware
• N / A: Schützt nicht vor böswilligen Entwicklern von Kennwortverwaltungssoftware
• N / A: Bietet keinen Schutz der Privatsphäre dass vorhandene Passwort-Manager nicht
• Con: Setzt das Hauptkennwort Brute-Force-Angriffen von böswilligen Websites und Hackern aus.

Benutzerfreundlichkeit:

• Pro: Frees Der Benutzer muss keine Kennwortdatenbankdatei verwalten.
• Con: Das Ändern von standortspezifischen Kennwörtern erfordert das Speichern zusätzlicher standortspezifischer Informationen.
• Con: Das Ändern des Hauptkennworts ist unpraktisch
• Con: Es ist nicht immer offensichtlich, welcher Site-Name als Eingabe für die Hash-Funktion verwendet werden soll.
• Con: Das Verwalten von Sites mit restriktiven Kennwortanforderungen ist sehr schwierig.

Was Sie denken, wurde bereits einige Male getan.

Hier ein Beispiel: http://plevyak.com/dpg.html

Es wird als deterministischer Kennwortgenerator bezeichnet. Dies bedeutet, dass Kennwörter basierend auf anderen von Ihnen eingegebenen Informationen erstellt werden. Wie Sie bereits sagten, verwenden Sie Ihr Hauptkennwort, einige andere Informationen und den Namen der Site.

Einige Punkte zu der Frage, zu lang für einen Kommentar, einige Dinge wurden bereits separat erwähnt:

• wurde oft durchgeführt, es stehen Tools zur Verfügung
• Von einem durchgesickerten Passwort könnten die anderen Passwörter theoretisch kompromittiert werden, wenn jemand errät, wie und was Sie haben, um die Passwörter zu erhalten, und dann Brute-Force anwendet. Immer noch viel besser als die Wiederverwendung von Passwörtern.
• Wenn das Hauptkennwort (plus Salt- und Hashing-Algorithmen und was auch immer Sie einrichten) kontaminiert ist, kennt der Angreifer nicht nur Ihre aktuellen Passwörter, sondern auch Ihre In Zukunft können Sie
• nicht einfach ein einziges Passwort ändern. Dies scheint mir der größte Nachteil bei der Verwendung zu sein.
• Aufgrund dummer Kennwortregeln können Sie das generierte Kennwort manchmal nicht verwenden. Sie können dies fast immer umgehen, indem Sie mehrere Kennwörter nach unterschiedlichen Regeln generieren (z. B. ein 20-stelliges alphanumerisches und ein 20-stelliges ASCII-druckbares Zeichenkennwort und dann die maximale Länge und Komplexität verwenden, die eine Website unterstützt). Dies ist jedoch ärgerlich weil Sie dann manchmal mehrere Versuche benötigen, um Ihre eigenen Passwörter richtig zu machen.

Alles in allem denke ich, dass es aus praktischen Gründen wahrscheinlich schlechter ist als Passwortdatenbanken, aber mit ähnlicher Sicherheit.

Wenn Sie die Sicherheit von Kennwortmanagern verbessern möchten, empfehlen wir Ihnen, einen hardwarebasierten zu verwenden. Wahrscheinlich existieren diese. Bevor Sie ein traditionelles Notebook bauen oder kaufen, sollten Sie auch die Verwendung eines herkömmlichen Notebooks in Betracht ziehen. Es ist ziemlich sicher gegen jede Art von Hackerangriff ...

Suchen Sie in SQRL nach einem System, das einen "Passwort-Manager" durch etwas ersetzt, das ohne zentrale Datenbank funktioniert und auch die Keylogger besiegen kann. Die Webserver, die Sie besuchen, benötigen bei diesem System keinen geheimen Status über Sie (wie ein Kennwort). Die ID, die jeder Website zur Verfügung gestellt wird, ist für jede Website eindeutig, sodass ein ID-Token von einer Site nicht mit einer anderen funktioniert.

Der beste "Passwort-Manager" wäre ein System, das nicht gespeichert werden muss eine Reihe von Hashes im Internet.