Bei Verwendung von nur einem Gerät müsste diese Schlüsseldatei auf jeden Fall in einem externen Backup gesichert sein, andernfalls würde ich Zugriff auf die Datenbank des Passwortmanagers bei einem Datenverlust verlieren, korrekt?
Setzte ich dieses Verfahren ein, so muss es einheitlich auf allen Geräten eingesetzt werden. Unterschiedliche 2FA-Verfahren können nicht gemischt oder parallel eingesetzt werden, richtig?
Liegt die Datenbank auf Nextcloud (NC) und möchte man dort über entsprechende NC-Apps auf die Datenbank zugreifen, scheidet dieses Verfahren aus, weil die Schlüsseldatei nicht in der Cloud abgelegt werden darf. Das würde ganze Verfahren ja aushebel, wenn ich das richtig verstanden habe.
ich nehme an, es geht um KeePassXc.
Die Schlüsseldatei ist kein „echter“ 2. Faktor, sondern macht das Passwort komplexer.
Liegt die Datenbank in der Cloud so wird die Schlüsseldatei nur lokal auf dem/den Gerät(en) gespeichert. Ein Backup der Schlüsseldatei auf einem externen Datenträger ist sinnvoll, weil die Datenbank sonst bei Verlust der Schlüsseldatei unbrauchbar wird.
Im Speziellen bezog sich die Frage nicht auf KeePassXc. Sie war eher allgemein gehalten. Aktuell nutze KeyPass2Android aufgrund der damaligen Empfehlung von mobilsicher.
Mit NC Apps kannst Du die Datenbank sowieso nicht öffnen, dafür brauchst Du die Passwortmanager-App. Der NC-Client ermöglicht der PW-Manager-App auf *.kdbx zuzugreifen und das unabhängig davon ob zur Verschlüsselung ein Keyfile eingesetzt wurde oder nicht.
Beispiel: Du nutzt 1 Rechner und 1 Smartphone und verfügst über Nextcloud (selbstgehostet oder über einen Anbieter, völlig egal), dort liegt deine *.kdbx Datenbank. Auf den Endgeräten (PC, Handy) ist der Nextcloud-Client installiert. Der Client nutzt auf den Endgeräten einen lokalen Ordner, der mit dem NextCloud-Server synchronisiert wird. Wenn Du jetzt am PC in den Einstellungen der Datenbank der Verschlüsselung eine Schlüsseldatei hinzufügst, erkennt der NC-Client, daß die Datenbank verändert wurde und synchronisiert die Datenbank mit dem Server und dem Handy. Jetzt musst Du natürlich die Schlüsseldatei auch auf das Handy kopieren, weil Du sonst die Datenbank nicht öffnen kannst. Für Nextcloud selber ist die Schlüsseldatei ohne jeden Belang. Nur eben nie die Schlüsseldatei zusammen mit der Datenbank in der Cloud speichern, das wäre wie die PIN auf die Kreditkarte schreiben.
btw wenn Du die Datenbank schon in der Cloud gespeichert hattest und nachträglich eine Schlüsseldatei definierst schützt diese, genau genommen, nur die Passwörter die nach diesem Zeitpunkt erstellt werden. Es könnte ja bereits jemand eine Kopie der Datenbank angefertigt haben und die sich darin befindlichen Passwörter sind dann „nur“ mit Deinem hoffentlich starken Passwort geschützt. Du musst also alle alten Passwörter neu setzen wenn Du nachträglich per Keyfile verschlüsseln willst. Das gilt auch bei Änderung des Master-Passwortes.
Falls ich das Ganze falsch interpretiert haben sollte, erkläre bitte warum sich ein Zugriff über NC ausschliessen soll.
Ich habe mal testhalber eine passwort- und keyfilegeschützte Dummy.kdbx mit einem Dummy-Eintrag erstellt und die keeweb App installiert. Der Öffnendialog von keeweb greift auf das lokale Dateiverzeichnis zu, somit sind lokale keyfiles kein Problem und die Datenbank lässt sich auch öffnen wenn das keyfile nicht in der Cloud liegt.
ABER:
Hast Du Dich mal über keeweb informiert?
Zitat aus der readme.md auf Github:
Status
The app is quite stable now. Basic stuff, as well as more advanced operations, should be rather reliable.
Looking for a new maintainer, see #2022
Keeweb scheint mir ein, mehr oder minder unausgereiftes Produkt einer „one-man-show“ zu sein. Der „one-man“ sucht einen Nachfolger und in dem Projekt hat sich seit Jahren nichts bewegt.
Damit würde ich meine tatsächliche Passwortdatenbank niemals öffen.
Sagen wir mal so.
Ich bin nicht besonders panisch. Ich nutze kein Smartphone, keine Cloud, für Bankgeschäfte einen Tan-Generator, an meinen Laptop kommt auch niemand dran.
Allerdings ist meine /home und die Datenpartitionen (noch) nicht verschlüsselt.
Die einzige Gefahr ist daher eine Attacke über das Internet. Ok E-Mail, aber da bin ich sehr vorsichtig.
Ich wollte nur sicher gehen, dass meine Passwörter durch KeepassXC mit einem Diceware-Passwort sicher genug ist.
Eine zusätzliche Schlüsseldatei riecht mir nach zu viel Aufwand, da ich dann jedes mal einen Stick einstecken muss.
Wenn die Datenbank nur lokal vorliegt kann man imho auf ein Key-File verzichten. Wobei ich, mit einer in der Cloud gespeicherten Datenbank, das Key-File einfach auf die Endgeräte packen würde.
Die Festplattenverschlüsselung schützt den Rechner ja auch „nur“ gegen Fremdzugriffe z.B. mittels Bootstick. Wenn Du das ausschliessen kannst, dann brauchst Du auch nicht unbedingt zu verschlüsseln.
Wenn sich jemand Zugriff auf Dein System verschaffen kann, so braucht er ja nur zu warten, bis Du ihm die Passwortdatenbank öffnest. Alle Angriffsszenarien auf KeePassXC die ich recherchieren konnte basieren auf einem kompromittierten System mit geöffneter Datenbank oder einem schwachen Passwort.
Bei einer Standard-Diceware Passphrase aus einer Liste mit 7776 Wörtern würde ich persönlich 8 Wörter als ausreichend sicher erachten.
Bin ein großer Freund von Diceware (statt der meist empfohlenen Akronym-Methode), doch verwende ich XC auf zwei Mobilgeräten und einer Handvoll Notebooks, so dass mir die Schlüsseldatei sinnvoll erschien. Neben einem Cloud-Backup (im Cryptomator-Vault) und einem auf externer Platte (mit Duplicati) habe ich von der Schlüsseldatei im XML-Format auch einen Ausdruck im Bankschließfach. Muss endlich mal testen, ob ein Restore tatsächlich funktioniert, wenn ich den Ausdruck abtippe oder einscanne
Scherz beiseite: Jeder zusätzliche Faktor verbessert die Sicherheit, stellt aber gleichzeitig einen möglichen Point of Failure dar, mit dem man sich selbst aussperren kann.
Ich nehme an, Du beziehst dich auf diesen Beitrag im Blog: https://www.kuketz-blog.de/sicheres-passwort-waehlen-der-zufall-entscheidet/
Das war Anfang 2017. Wie Mike ja dort selbst berechnet hat, hat eine Diceware Passphrase mit 6 Wörtern knapp unter 80 bit Entropie, was für mich, ganz subjektiv betrachtet, heute zu wenig ist.
Auf der anderen Seite wird die Verschlüsselung von KeepassXC mit der Schlüsselableitungsfunktion Argon2 auch leistungsstarke Cracking-Hardware signifikant ausbremsen.
Was mir nur nicht klar ist.
Was hat die Wörterliste damit zu tun?
Zumal da nur Kleinbuchstaben genutzt werden.
Die Sicherheit erlangt man doch quasi nur durch die Länge. Dann ist es auch egal, wie viele Wörter die Liste hat. Dann nimmt man einfach 8, 9, 10… Wörter aus der kurzen Liste, bis man eine gewisse Anzahl von Buchstaben hat.
Denn so weit ich das verstanden habe kommt es ja nicht auf die Wörter an, sondern auf die Zufälligkeit der Buchstaben- bzw. Zeichenfolge?
Warum ist ein selbst erfundenes mit allen Kategorien (Groß-Klein,Sonder,Zahlen=94) mit weniger Zeichen (mind. 12?) dann eher knackbar?
Ein starkes Passwort kann „kürzer und komplex“ oder „lang und weniger komplex“ sein. Doch wie lang und wie komplex sollte es mindestens sein? Folgende Beispiele geben Orientierung:
Ein Passwort ist sicher, wenn es beispielsweise
20 bis 25 Zeichen lang ist und zwei Zeichenarten genutzt werden (beispielsweise eine Folge von Wörtern). Es ist dann lang und weniger komplex.
8 bis 12 Zeichen lang ist und vier Zeichenarten genutzt werden. Es ist dann kürzer und komplex.
8 Zeichen lang ist, drei Zeichenarten genutzt werden und es zusätzlich durch eine Mehr-Faktor-Authentisierung abgesichert ist (beispielsweise durch einen Fingerabdruck, eine Bestätigung per App oder eine PIN). Dies ist generell empfehlenswert.
So oder so. Spätestens wenn die Quantencomputer Alltag sind, und/oder die Rechnerleistungen noch schneller werden, müssen wir uns vermutlich eh etwas einfallen lassen.
Z. B. neue Zeichenarten, oder eine komplett andere Passworttechnik, die ohne Hardwareunterstützung gar nicht mehr geht? Weil man sich das dann nicht mehr merken kann, oder 5 Minuten tippen muss für das Passwort
Full ack. Manche ganz auf Sicherheit Bedachte empfehlen ja gleich 64 Zeichen. Kein Problem im Passwortmanager, aber wehe man muss das mal händisch eintippen…
Ich beziehe mich nur auf Passphrasen für KeepassXC oder LUKS (Anspruch: sicher und leicht zu merken). Bei den Diceware Wortlisten (7776 Wörter) entspricht ein Wort einem Zeichen und bringt 12,97 bit Entropie. Wenn ich also 100 bit Entropie anstrebe brauche ich 100/12,97=7,71, also 8 Wörter. Ich verwende deshalb eine Liste mit 239650 Wörtern bzw. Zeichen, damit komme ich auf 17,87 bit Entropie pro Zeichen und muss mir nur noch 100/17,87=5,56, also 6 Wörter merken. Das ist der Grund warum ich diese Liste verwende.
Du hast natürlich vollkommen recht, daß sich die Entropie des Passworts immer über die Länge anpassen lässt unabhängig vom Zeichensatz.
Die Anzahl der Wörter ist die massgebliche Größe, die Anzahl der verwendeten Buchstaben spielt bei der Berechnung der Entropie von Passphrasen keine Rolle.
Die 94 druckbaren ASCII Zeichen erzeugen eine Entropie von log₂94=6.555 bit pro Zeichen.
12x6,555 bit=78,66 bit Entropie. 12 Zeichen druckbares ASCII sind also ungefähr so sicher wie 6 Wörter Diceware.
Selbst erfunden sollte es aber nicht sein, sondern zufällig generiert. $us1$0mm3r99 z.B. wäre ein schlechtes Passwort.
Danke.
Ich verstehe es zwar nicht so wirklich, aber ok.
Danke für den Link, ist aber leider in Englisch.
Ich habe die Wiki über Entropie gelesen, mit Mathe habe ich es aber nicht so.
Das ist hauptsächlich eine Frage des kryptographischen Verfahrens, nicht des Passworts. Bei symmetrische Kryptographie wie bei AES bringen Quantencomputer kaum etwas, asymmetrische Verfahren wie PGP, TLS & co. dagegen werden vermutlich sehr schnell unsicher.
Ist dann das als veraltet geltende AES-128 genau so ‚post-quantum-sicher‘ wie AES-256? Meine geliebte FOSS-Notizverwaltung Joplin ist gerade auf AES-128 zurückgefallen, weil es mit dem unlängst implementierten 256 auf einigen Plattformen Probleme mit der Performance gab. Solche Fragen mit direktem Bezug zum Vor-Poster darf man hoffentlich noch loswerden, ohne dass das nach den neuen Regeln als off-topic markiert wird
Bei AES-128 läuft jetzt schon eine längere Diskussion ob die Schlüssellänge mittelfristig noch als sicher einzustufen ist, post-quantum dürfte das so oder so keine Empfehlung mehr sein.
