Kurze Vorstellung KeePassXC, ist ein Fork von KeePassX, gefällt mir aber persönlich wesentlich besser. Einer der Gründe ist, das ich die DB mit einem Yubikey entsperren kann. Dieser muss auf einem Slot hmac unterstützen. Da ich keinen Slot freihatte, habe ich in den Staaten zwei Stück in der Bucht bestellt. Die lagen wochenlang beim Zoll herum, nachher durfte ich 8,48€ nachzahlen. Aber was soll's, immer noch billiger.
Aufpassen, bei diesen handelt es sich um die erste Generation, die kein U2F können! Für meinen Anwendungszweck aber völlig ausreichend.
Ok, dann ran ans ausprobieren.
Wir brauchen für den Yubikey ein Tool, damit wir ihn beschreiben können. Dazu gibt es das Tool Yubikey Personalzation. Auf meinem Notebook läuft aktuell ein Debian 9 Stretch, dort kann man das ganz einfach mit der Paketverwaltung installieren.
Das Tool starten und auf "Challenge Response" klicken. "Configuration Slot2" auswählen.Den 2. Slot wählen wir um die Originalfunktion des Yubikey's auf dem ersten Slot nicht zu benutzen. Der 2. Slot ist standardmäßig nicht belegt.
Dann auf "Generate" klicken, damit wird der Code erzeugt. Danach auf "Write Configuration" klicken und der Yubikey wird programmiert. Fertig!
Um nun den Yubikey zum Entsperren der DB benutzen zu können, müssen wir das Masterpasswort ändern. Dazu rufen wir den entsprechenden Dialog auf und stellen dort auf Challenge Response um. Das Ganze speichern wir.
Danach kann man KeePassXC mit dem Yubikey entsperren, dazu das Programm starten, die DB auswählen, den Haken bei "Challenge-Response" setzen und auf OK klicken. Der Yubikey blinkt kurz und nun einmal die Taste berühren und die DB ist entsperrt. Sehr schön, kein komplexes PW mehr merken ;)
Was machen bei Verlust des Yubikey's?
Man sollte sich den Key notieren und an einem sicheren Ort aufbewahren, oder man erstellt direkt einen 2. Yubikey den man dann in einem Tresor sicher verwahrt. So ist man gegen Verlust perfekt geschützt.
Update
Vorsicht! Es gibt da wohl ein paar kleine Probleme mit der YubiKey Integration. Im schlechtesten Fall ist die DB platt. Ich arbeite aber zu Testzwecken sowieso nur mit einer Kopie im Moment. Die korrigierte Version funktioniert einwandfrei, die muss man sich aber selber kompilieren. Mit dem nächsten Update 2.2.1 sollten die Änderungen drin sein, bis dahin auf den Yubi besser verzichten oder Version selber kompilieren. Pull #880
HMAC-SHA1
HMAC-SHA1: SHA-1 wird nicht mehr als kollisionsresistent angesehen. Gegen die Verwendung in Konstruktionen, die keine Kollisionsresistenz benötigen (zum Beispiel als Grundlage für einen HMAC oder als Komponente eines Pseudozufallsgenerators) spricht aber nach gegenwärtigem Kenntnisstand sicherheitstechnisch nichts. Es wird empfohlen, auch in diesen Anwendungen als grundsätzliche Sicherungsmaßnahme eine Hashfunktion der SHA-2-Familie oder der SHA-3-Familie einzusetzen. Prinzipiell ist eine Verwendung von SHA-1 in der HMAC-Konstruktion oder in anderen kryptographischen Mechanismen mit
vergleichbaren kryptographischen Anforderungen an die genutzte Hashfunktion (zum Beispiel im Rahmen eines Pseudozufallsgenerators oder als Teil der Mask Generation Function in RSA-OAEP) voraussichtlich bis 2018 konform zu der vorliegenden Technischen Richtlinie.
Quellen:
HMAC https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
KeePassX https://www.keepassx.org/
KeePassXC https://keepassxc.org