Keepass2, wie man Schlüssel und DB auf "iPhone" -ähnlichen Geräten voneinander trennt?

Der sicherste Weg, Keepass zu verwenden, besteht darin, die Schlüsseldatei und die Datenbank voneinander zu trennen.

Meine erste Idee war, eine USB- / Flash-Karte mit der Schlüsseldatei wie einen normalen Schlüssel (und DB auf Dropbox) zu verwenden, Apple mag jedoch keine externen Speichergeräte.

So können nur Cloud- oder Internetlösungen verwendet werden. Nach der Authentifizierung durch iOS kann in der Regel jeder auf Dropbox, Google Drive usw. zugreifen, da diese Konten von iOS verwaltet werden (zumindest wenn Sie möchten, dass Ihr Mobiltelefon zumindest ein bisschen einfach ist).

Mein Workflow ist jetzt unsicher, beide Dateien befinden sich in der Dropbox. Die Verwendung eines SFTP-Servers in meinem lokalen Netzwerk würde funktionieren, aber meines Wissens wäre es zu schwierig, um vom Internet darauf zuzugreifen (keine feste IP-Adresse), und ich möchte mein lokales Netzwerk überhaupt nicht für das Internet öffnen.

Nach diesem viel zu langen Intro ist meine praktische Frage: Kennt jemand einen guten sicheren Workflow für keepass2 DB und Schlüsseldateien für alle Desktops und Mobilgeräte meiner Geräte (iPhone / iPad)?

Eine Lösung, bei der ich nicht viele Passwörter benötige, um sich bei Services anzumelden, um meine Passwörter abzurufen.

BEARBEITEN:

Ich habe einige Dokumente von keepass noch einmal gelesen: http://keepass.info/help/base/security.html

Um den 256-Bit-Schlüssel für die Blockchiffren zu generieren, wird der Secure-Hash-Algorithmus SHA-256 verwendet. Dieser Algorithmus komprimiert den vom Benutzer bereitgestellten Benutzerschlüssel (bestehend aus Kennwort und / oder Schlüsseldatei) auf einen Schlüssel mit fester Größe von 256 Bit. Diese Transformation ist einseitig, dh es ist rechnerisch nicht möglich, die Hash-Funktion zu invertieren oder eine zweite Nachricht zu finden, die zu demselben Hash komprimiert wird. Schlüsselableitung: Wenn nur ein Kennwort verwendet wird (dh keine Schlüsseldatei), werden das Kennwort und ein zufälliges 128-Bit-Salt mit SHA-256 zum endgültigen Schlüssel gehasht (beachten Sie jedoch, dass einige Vorverarbeitungen vorhanden sind: Schutz vor Wörterbuchangriffen). Das zufällige Salt verhindert Angriffe, die auf vorberechneten Hashwerten basieren.

Wenn Sie sowohl das Kennwort als auch die Schlüsseldatei verwenden, wird der endgültige Schlüssel wie folgt abgeleitet: SHA-256 (SHA-256 (Kennwort), Inhalt der Schlüsseldatei), dh der Hash des Hauptkennworts wird mit den Schlüsseldateibytes und dem resultierenden Byte verkettet String wird erneut mit SHA-256 gehasht. Wenn die Schlüsseldatei nicht genau 32 Byte (256 Bit) enthält, werden sie ebenfalls mit SHA-256 zu einem 256-Bit-Schlüssel gehasht. Die obige Formel ändert sich dann zu: SHA-256 (SHA-256 (Kennwort), SHA-256 (Schlüsseldatei)).

Wenn ich das richtig verstanden habe, nur das Passwort und die Passwort- + Schlüsseldatei, ergeben sich 256 Bit "Schlüssel / Hash". Die Stärke der DB ist also gleich, solange Sie ein gutes Passwort haben. Die zusätzliche Stärke ergibt sich daraus, dass der Angreifer Ihre Schlüsseldatei benötigt, um die 256 Bit zu vervollständigen.

Angesichts der im Link genannten Gegenmaßnahmen zu Wörterbuchangriffen kann ich außerdem davon ausgehen, dass die zusätzliche Sicherheit aus der Schlüsseldatei bei einem richtigen Kennwort die Unannehmlichkeiten in diesem speziellen Fall nicht überwiegt.