lykaner
Moin,
mir ist aufgefallen, dass ich hier im dt. Forum noch gar nicht mein kleines Programm vorgestellt, an dem ich seit ca. einem halben Jahr arbeite: KeePassC ein KeePassX bzw. KeePass v1 (wärs von Windows kennt...) kompatibler Passwortmanager, d.h. eure Passwörter werden mit AES verschlüsselt gespeichert und sind in Gruppen sortiert. Geschrieben ist es mit Python und curses, d.h. es wird im Terminal komplett mit der Tastatur bedient!
Momentan gibt es zwei Pakete im AUR, einmal das letzte stable-Release und die git-Version. Ich empfehle momentan allen die Git-Version, da ich in letzter Zeit viele Änderungen vorgenommen habe und das letzte Release vier Monate her ist. Die Abhängigkeiten sind minimal, lediglich Python 3.3, PyCrypto (bzw. das mein Modul, dass darauf aufsetzt: kppy) und xsel werden benötigt.
Wär mehr Informationen haben will:
http://nongnu.org/keepassc/ (Screenshots nicht mehr ganz aktuell)
bzw., da ich bald komplett nach GitHub umziehe:
http://raymontag.github.com/keepassc/
Im AUR:
https://aur.archlinux.org/packages/keepassc/
bzw. Git-Version:
https://aur.archlinux.org/packages/keepassc-git/
Have fun!
Kinch
Super! Nutze Keepassx schon ewig und es ist mittlerweile meine einzig verbliebene QT-Applikation die ich gerne loswerden möchte.
Ich werde dein Programm mal austesten.
Grüße
lykaner
Kinch schriebSuper! Nutze Keepassx schon ewig und es ist mittlerweile meine einzig verbliebene QT-Applikation die ich gerne loswerden möchte.
Genau dies war der Grund, warum ich mit KeePassC angefangen habe 😉
Creshal
Wie siehts btw. mit dem Keepass2-Format aus? Viel Aufwand oder Sehr Viel Aufwand™?
lykaner
Den Aufwand kann ich noch nicht so genau einschätzen, ich hab mir den orig. C++-Code noch nicht angeguckt. Da ich aber v1 verstanden habe, wird's wohl nicht so aufwendig. Ich komme aber wohl erst Mitte März dazu, da ich momentan eher wenig Zeit habe (Prüfungsphase, wissenschon...).
lykaner
Just FYI: Ich habe heute eine neue stable veröffentlicht. Ab sofort sollten alle wieder das AUR-Paket keepassc, keepassc-git wird zukünftig die Entwicklerversion darstellen, die auch mal crashen kann, wenn ieine Funktion noch nicht komplett implementiert ist.
Außerdem ist das Projekt jetzt komplett nach github umgezogen. Hier ist die neue Seite:
http://raymontag.github.com/keepassc/ In Zukunft wird es nur noch hier und auf github Support geben, da ich meinen nongnu.org- und gitorious-Account lösche bzw. schon gelöscht habe. So erscheint es mir einfacher. Dementsprechend wird zukünftig der master-branch auf github dem stable-Paket keepassc entsprechen und der development-branch keepassc-git (github unterstützt keine Daten-Uploads, aber so geht's ja auch. Das zwingt mich dann auch, mein git-Repository sauber zu halten 😃 ).
lykaner
lykaner
Ich habe gerade ein winziges Update ins AUR eingespielt. Es gab eine Zeitverzögerung, wenn man KeePassC geschlossen hatte und der Timer für das Löschen des Clipboards noch nicht abgelaufen war.
lykaner
Neues Update 1.5.2 mit Bug-Fixes ist im AUR.
lykaner
Ein weiterer Fix ist im AUR.
lykaner
Eine neue Version (1.6.0) ist raus und im AUR. Das große neue Feature ist, dass man KeePassC nun via Netzwerk benutzen kann. Schaut auf
http://raymontag.github.com/keepassc für eine Einführung. Ansonsten werden ausgelaufene Einträge nun rot markiert und ein neues Hilfemenü gibt's ebenfalls.
Falls jmd. die Möglichkeit KeePassC über das Internet auszuprobieren (sollte auch funktionieren, aber ich habe nicht die Möglichkeiten dazu), wäre es nett, wenn er es mir sagen würde, da ich es nicht selber testen kann. Es sollte beides funktionieren: Entweder gibt man die Domain an oder die ServerIP.
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)