shibumi
Mag zwar ne dumme Frage sein aber "Wie sicher ist dein kepassc" ?
EDIT: Also ich meine solche Sachen wie:" Wie wird der Master Key gespeichert" etc
lykaner
Nun, da gibt es einige Aspekte zu betrachten:
- Das Passwort und der Pfad zu Keyfile sind plain im RAM, als Attribut des Datenbankobjekts; genauso wie auch die Gruppen und Einträge der Datenbank selbst
- Python hat ein Problem (das andere Sprachen auf einer ähnlichen Abstraktionsebene auch haben) und zwar hat man keine Kontrolle darüber, wo Daten im RAM liegen und wie sie verstreut werden. Einfachen Beispiel: Ein String (mehr ist das Password auch nicht) ist _nicht_ veränderbar in Python. Wenn du den String manipuliert wird eine neue Kopie angelegt und die alte liegt immer noch rum, bis iwas anderen drüber geschrieben wird. Die einzige Möglichkeit das zu umgehen könnte sein, ein C-Modul für Python zu schreiben, ich bin mir da aber nicht 100%-sicher und habe mir vorgenommen mich bei Gelegenheit darin einzulesen.
- Ich umgehe dieses Problem in dem ich mit dem Passwort und dem Keyfile nicht rumspiele und durch die Gegend werfe. Außerdem verhindere ich CoreDumps dadurch (das ist ja die eig. Gefahr, wenn das Password plain im RAM liegt), indem der Arbeitsordner fest /var/empty ist, die Dateimanipulation mache ich über absolute Pfadvariable (als root-user könnte man immer noch CoreDumps machen, deshalb weise ich darauf hin, dass man KeePassC nicht als root ausführen sollte). KeePassX und das original KeePass machen das anders: Sie verschlüsseln den Masterkey mit einem zufällig generierten One-Time-Passwort. Das liegt aber auch im RAM und mit etwas Arbeit könnte man aus einem CoreDump auch das Passwort auslesen. Ich halte diese Vorgehensweise daher für SnakeOil, ich lasse mich da aber gerne berichtigen bzw. darüber können wir gerne diskutieren.
- Zuletzt sei zu diesem Punkt gesagt, dass ein Setup, in welchem ein Angreifer den RAM auslesen kann IMHO ganz andere Probleme hat 😉 (das meine ich Ernst, damit will ich nicht von mir ablenken)
Zur Sicherheit des Netzwerkprotokolls:
- Die Datenbank liegt auf dem Server, es gilt was ich schon schrieb
- Der Client bekommt eine Kopie der Datenbank, sie liegt ebenfalls im RAM, genauso wie das Passwort und der Pfad zum Keyfile. Zu keinem Zeitpunkt speichere ich sie auf der Festplatte des Clients.
- Die Kommunikation mit dem Server läuft optional über SSL. Ich habe das wie folgt vorgesehen: Der Server erstellt ein Selbstsigniertes x509-Zertifikat mit einer selbsterstellen CA und gibt dem Client das Root-Zertifikat. Der Client prüft dann mit letzterem gegen das Zertifikat des Servers. Um MITM-Attacken zu erschweren, habe ich außerdem Public-Key-Pinning implementiert, d.h. der Client merkt sich den Fingerprint des Server-Zertifikats und prüft, ob der Fingerprint des vom Server bereitgestellten mit diesem übereinstimmt. Außerdem muss der Common Name ("KeePassC Server" muss dieser lauten) des Zertifikats stimmen, das ist allerdings nur um sicherzugehen, dass der Client nicht z.B. alles an den HTTPS-Port sendet.
- Des Weiteren muss sich der Client mit dem Datenbank-Passwort und/oder dem Keyfile beim Server authentifizieren. Dazu sendet der Client eben das Passwort und den Inhalt des Keyfiles an den Server (nachdem das Zertifikat überprüft wurde, natürlich). Der Server generiert dann daraus den MasterKey und guckt, ob das mit dem den er aus dem bei ihm abgelegten Passwort und/oder Keyfile übereinstimmt.
- Man könnte noch implementieren, dass der Client sich auch mit einem Zertifikat authentifizieren muss, dass könnte ich mal machen, wenn ich Zeit habe
Das wäre alles, was mir so spontan einfällt, wenn's noch fragen gibt, nur zu. (Ich sollte vllt. mal eine vollständige Auflistung zu diesem Punkt auf die Internetseite tun...)
Silmaril
Ich habe keepassc jetzt ein paar Tage ausprobiert. Echt nicht schlecht. Ich persönlich komme aber mit der Qt-Oberfläche besser klar (benutze ja auch KDE). Aber gut zu wissen, dass es auch ein KeePass-kompatibles Programm für die Konsole und vor allem fürs Netzwerk gibt.
lykaner
Kurze Information: Durch einen Bug in meiner Implementation der Entschlüsselung mit Keyfiles (nichts Sicherheitsrelevantes, s.
https://github.com/raymontag/kppy/pull/9 ; in aktueller Version von python-kppy behoben) wurde ich auf einen Bug in KeePassX aufmerksam gemacht. Demzufolge ist es nicht möglich eine Datenbank, die in KeePassX mit einem 64Byte-Keyfile verschlüsselt wurde, in KeePassC zu entschlüsseln. Wurde die Datei hingegen in der Referenzimplementation KeePass 1.26 unter Windows verschlüsselt funktioniert alles.
lykaner
Im development-branch (AUR: keepassc-dev) gibt es nun standard-expiration-dates zur Auswahl beim Erstellen neuer Entries oder beim editieren der Daten.
shibumi
Hey Lykaner ich denke schon länger darüber nach dein Programm zu nutzen. Allerdings stellt sich mir die Frage nach der Sicherheit. Kannst du dazu näheres erläutern wie sicher dein Fork ist? Welche Verschlüsselungsalgorithmen zb zum Einsatz kommen etc?
lykaner
Nun, es ist kompatibel zu KeePassX daher kommen die gleichen Algorithmen zum Einsatz insb. AES zur Verschlüsselung der Datenbank. Ich benutze hierfür das bewährte PyCrypto. Ich hatte immer mal vor Twofish ebenfalls zu implementieren, das wird aber nicht von KeePassX sondern nur von KeePass für Windows unterstützt, aber PyCrypto kann das nicht und ich werde sicher nicht meine eigene Implementation schreiben 😉
Ansonsten gilt das oben gesagte. Hast du sonst andere, spezifischere Fragen?
shibumi
Naja stellt sich jetzt die Frage wie sicher pyCrypto ist..
lykaner
PyCrypto ist als sicher anzusehen: Es arbeitet verlässlich und ist am weitesten verbreitet unter den Crypto-Bibliotheken für Python. Außerdem wird es stetig weiterentwickelt. Man könnte höchstens überlegen zu wechseln, sobald NaCl für Python fertig ist, dass als eine der besten Crypto-Bibliotheken für C/C++ angesehen wird und eine große Community hat. Aber ich verstehe was du meinst, man sollte sowas immer kritisch beäugen. Ansonsten kann ich diesbezüglich nur auf
http://stackoverflow.com/questions/7835974/is-pycrypto-safe-and-reliable-to-use verweisen
lykaner
Das x-scrolling im Editor funktioniert nun endlich auch. Ist im development branch (keepassc-dev)
lykaner
Da einige Leute sich über die Namensgebung des development-packages beschwert haben, lade ich die development-version nun wieder als keepassc-git ins AUR.
Des Weiteren wird nun der Editor, der sonst auch in alles Textfeldern verwendet wird, auch für die Pfadeingabe inkl. Tab-Completion verwendet. Momentan nur im development-branch.
shibumi
Wer benutzt hier eigentlich alles KeePassC oder das normale KeePass? Würde mich mal interessieren. Ich fand eigentlich immer, dass das lokale Speichern von Passwörtern in einer Passwort-Datenbank ziemlich unsicher und unpraktisch ist. Der beste Ort für Passwörter ist doch eigentlich der Kopf.
Beispiel 1:
Person A nutzt KeePass. Hat dort alle seine Passwörter fein in einer Datenbank abgespeichert. Da Person A ganz sicher sein will hat er 32 zeichenlange Passwörter aus Zahlen, Großbuchstaben, Kleinbuchstaben und Sonderzeichen. Nun verreist Person A aber und will sich von wo anders in seinen Email account oder was auch immer einloggen... Geht nicht. Da er seine Passwörter nicht auswendig weiß..
Beispiel 2:
Person A nutzt KeePass. Sein Rechner wird infiziert und ein Krimineller loggt sein MasterPW mit und kopiert sich die Passwort-Datenbank. Volltreffer. Innerhalb von 2 Minuten im absoluten glücksfall alle wichtigen Passwörter ergaunert.
Beispiel 3:
Person A nutzt KeePass. Legt allerdings von seiner Key-Datenbank kein Backup an. Seine Festplatte geht kaputt. Alle Passwörter weg.
Also ich weiß nicht oO irgendwie bin ich noch nicht so überzeugt von der Sache alle seine Passwörter lokal abzuspeichern. Andererseits hat KeePass auch seine Vorteile.
Man kann vieel sichere Passwörter nehmen und für jeden Account ein anderes. Sonst passiert es einem doch relativ oft das man irgendwo anders das gleiche Passwort auch noch verwendet oder es sowieso nicht so sicher ist wie ein Passwort was aussieht wie ein MD5 Hash..
Was meint ihr dazu? Vielleicht überzeugt ihr mich ja noch 🙂
nik
Das ist zwar durchaus richtig, allerdings deuten die Beispiele von dir alle auf Fehler des Benutzers hin, die leicht hätten umgangen werden können.
Beispiel 1: Keepass kann man auch auf dem Smartphone nutzen, und so seine Passwörter mitnehmen. Genauso kann man sich durchaus oft genutzte Passwörter merken. Es zwingt einen ja niemand, alle Passwörter automatisch zu generieren.
Beispiel 2: Wenn der Rechner kompromittiert ist, gelten generell die eingegebenen Passwörter als nicht mehr sicher. Dementsprechend macht es kaum einen unterschied, ob die Passwörter in einem Passwortsafe liegen oder nicht.
Davon abgesehen, greifen die wenigstens per Mailware direkt auf den Rechner zu, sondern fahren automatisierte Angriffe, so dass es unwahrscheinlich ist, dass die komplette Datenbank abhanden kommt. Die Logindaten für interessante Ziele können so oder so automatisiert mitgeschnitten werden.
Beispiel 3: Wer keine Backups macht, verliert.
Allgemein sehe ich den Vorteil von Keepass darin, dass die Nutzer nicht "gezwungen" ist, unsichere Passwörter zu nutzen, die er sich merken kann, oder gar für verschiedene Dienste das gleiche Passwort zu nutzen.
lykaner
FullACK mit nik. Die Hauptintention halt, dass die sichersten Passwörter die sind, die man sich nicht merken kann, weil nicht aussprechbar; selbst für 1337-Speak kann man sich ganz einfach per Skript aus normalen Wörterbücher welche dafür generieren, die gibt's auch längst im Internet. Und IMHO ist ein Passwortmanager, der die Datenbank verschlüsselt, hierfür die beste Lösung, eben aus den zuletzt von euch genannten Gründen und dann natürlich lokal, damit ich Herr über meine Daten bleibe. Ob man jetzt KeePassX, KeePassC oder was ganz anderes wie Gringotts etc. ist halt nach eigenem Gusto.
Dirk
shibumi schriebBeispiel 1:
KeePass gibt es sowohl für Android, als auch für iOS.
shibumi schriebBeispiel 2:
Ja, dumm gelaufen. Kann aber auch mit „ein Passwort für alles“ funktionieren.
shibumi schriebBeispiel 3:
Selbst schuld.
shibumi
nik schriebDas ist zwar durchaus richtig, allerdings deuten die Beispiele von dir alle auf Fehler des Benutzers hin, die leicht hätten umgangen werden können.
Beispiel 1: Keepass kann man auch auf dem Smartphone nutzen, und so seine Passwörter mitnehmen. Genauso kann man sich durchaus oft genutzte Passwörter merken. Es zwingt einen ja niemand, alle Passwörter automatisch zu generieren.
Naja aber wo ist dann der Sinn von KeePass wenn man Passwörter nimmt die man sich sowieso merken kann?
Beispiel 2: Wenn der Rechner kompromittiert ist, gelten generell die eingegebenen Passwörter als nicht mehr sicher. Dementsprechend macht es kaum einen unterschied, ob die Passwörter in einem Passwortsafe liegen oder nicht.
Davon abgesehen, greifen die wenigstens per Mailware direkt auf den Rechner zu, sondern fahren automatisierte Angriffe, so dass es unwahrscheinlich ist, dass die komplette Datenbank abhanden kommt. Die Logindaten für interessante Ziele können so oder so automatisiert mitgeschnitten werden.
mhhh das stimmt wohl
KeePass gibt es sowohl für Android, als auch für iOS.
Naja seine KeePass Datenbank permanent mit sich zu tragen ist aber auch nicht so toll. Man stelle sich mal vor man verliert das Smartphone und jemand anderes findet es. Über Bruteforce ließe sich das bestimmt knacken mit viel Zeit und geduld. Andererseits.. wie hoch ist die Wahrscheinlichkeit dass ein Smartphone-Finder sich auch noch damit auskennt bzw dass man es überhaupt verliert?
lykaner
Ich merke mir nur mein KeePass-Passwort, das ist 30+-Zeichen lang und zufallsgeneriert. Es ist dann weitaus angenehmer eine Datenbank zu haben, in der die restlichen stehen, anstatt sich an die 100 weiteren zufallsgenerierten zu merken 😉 Das führt mich auch zu deinem letzten Punkt: Wenn du ein ordentliches Passwort nimmst und dein Passwort abhanden kommt, geht die Wahrscheinlichkeit gegen Null, dass die Datenbank per Bruteforce geknackt wird; die Zeit die selbst auf großen Clustern, wie sie in Rechenzentren stehen, benötigt wird, um einen AES-Key zu knacken, wird weiterhin in Millionen Jahren gemessen. Solange der Dieb also nicht zufällig ein mathematisches Genie mit Schwerpunkt Kryptographie ist und eine Schwäche in AES gefunden hat, die nicht publiziert ist, hast du also Glück 😉 Blöd sieht es natürlich mit Passwörten aus Wörterbüchern aus, aber wer solch ein schwaches Passwort nimmt, ist selbst Schuld.
shibumi
lykaner schriebIch merke mir nur mein KeePass-Passwort, das ist 30+-Zeichen lang und zufallsgeneriert. Es ist dann weitaus angenehmer eine Datenbank zu haben, in der die restlichen stehen, anstatt sich an die 100 weiteren zufallsgenerierten zu merken 😉 Das führt mich auch zu deinem letzten Punkt: Wenn du ein ordentliches Passwort nimmst und dein Passwort abhanden kommt, geht die Wahrscheinlichkeit gegen Null, dass die Datenbank per Bruteforce geknackt wird; die Zeit die selbst auf großen Clustern, wie sie in Rechenzentren stehen, benötigt wird, um einen AES-Key zu knacken, wird weiterhin in Millionen Jahren gemessen. Solange der Dieb also nicht zufällig ein mathematisches Genie mit Schwerpunkt Kryptographie ist und eine Schwäche in AES gefunden hat, die nicht publiziert ist, hast du also Glück 😉 Blöd sieht es natürlich mit Passwörten aus Wörterbüchern aus, aber wer solch ein schwaches Passwort nimmt, ist selbst Schuld.
Mhh danke für deinen Beitrag. Aber wie merkst du dir ein 30+ zufallsgeneriertes Passwort? XD
lykaner
Gewohnheit 😃 Ne im Ernst, es einfach ausm Kopf aufschreiben könnt ich auch nicht sofort, aber mit ein bisschen Übung ist das Muster, das man tippen muss nach ein-zwei Wochen drin und dann ist es selbst aufm Smartphone kein Problem mehr.
shibumi
Jo ansonsten könnte man ja immerhin das ganze etwas lesbarer gestalten.. man formt halt einen satz auf irgendeiner fremdsprache tauscht bestimmte buchstaben gegen zeichen aus und setzt noch bestimmte sonderzeichen rein - fertig