[iOS] KeePassium und lokale Kopie der Passwort-Datenbank

Allgemein
,
1

Nach längerem Zögern habe ich mich nun doch dazu entschlossen, meine KeePassXC-Datenbank auch auf dem iPhone zu nutzen. Irrtümlich ging ich zunächst davon aus, dass sich in KeePassium eine lokale Kopie der Datenbank vermeiden ließe – dem scheint jedoch nicht so zu sein.

Hintergrund meines bisherigen Zögerns war der Sicherheitsgrundsatz, die Datenbankdatei und das KeyFile strikt getrennt zu speichern. Das KeyFile fungiert als zweiter Faktor zur Entschlüsselung der auf meinem eigenen Nextcloud-Server abgelegten KeePass-Datenbank.

Dieses Konzept wurde ursprünglich entwickelt, um bei einem möglichen Diebstahl der Datenbank (durch Kompromittierung des Nextcloud-Servers) Brute-Force-Angriffe zu erschweren. Diese Anforderung ist weiterhin erfüllt. Die Tatsache, dass der Nextcloud-Client auch auf meinen Laptops und Desktops eine lokale Kopie speichert, habe ich bewusst in Kauf genommen. Die Geräte verfügen über verschlüsselte Festplatten, und das Diebstahlrisiko ist in diesem Kontext gering.

Bei einem Mobiltelefon sehe ich das anders – es ist deutlich exponierter gegenüber Verlust oder Diebstahl. Daher meine anfängliche Zurückhaltung.

Nun meine konkrete Frage: Wie schätzt ihr das Risiko ein, wenn sowohl Datenbank als auch KeyFile auf demselben iOS-Gerät gespeichert werden – in diesem Fall direkt in KeePassium? Das KeyFile liegt nicht separat im iOS-Dateisystem, sondern ist nur innerhalb der App zugänglich. KeePassium ist zusätzlich durch eine starke PIN gesichert, kann aber über Face ID entsperrt werden.

Mein Bedrohungsmodell umfasst physischer Zugriff auf das Gerät nach Verlust oder Diebstahl durch eher allgemeine, nicht gezielte Akteure. Konkret:

  • Gelegenheitsangreifer (z. B. Finder, Neugierige)
  • Motivierte Einzeltäter mit technischer Kompetenz
  • Organisierte, aber nicht gezielt interessierte Gruppen (Cyberkriminelle ohne konkrete Zielausrichtung)

Staatliche oder hochpotente Akteure mit gezieltem Interesse schließe ich ausdrücklich aus.

Nach BSI-Kriterien würde ich einen hohen Schutzbedarf ansetzen.

Gibt es auf iOS Alternativen oder ergänzende Maßnahmen, die das Sicherheitsniveau in diesem Setup verbessern könnten, ohne dass ich mein gesamtes KeePass-Ökosystem umstellen muss? Oder ist dieses Setup – mit Blick auf das genannte Bedrohungsszenario – vertretbar? Gibt es sicherheitsrelevante Details, die auf den ersten Blick nicht offensichtlich sind?

2

Wenn es um weitere Härtung geht, lässt sich „FaceID verwenden“ auch ausschalten. Mit der Option „Datenbanken schützen“ lässt sich bereits bei einmaliger Falsch-Eingabe der PIN erreichen, dass die Datenbank geschlossen und das Masterpasswort angefordert wird.

Das Offline-Caching von Datenbank und Keyfile lässt sich nicht vermeiden, das ist richtig. So unzuverlässig, wie Nextcloud über die Files App manchmal synchronisiert wird, finde ich diesen Cache für die Nutzung aber essenziell. Mit den eben genannten Maßnahmen kommt mir Keepassium ausreichend sicher vor.

Im Gegensatz zu Desktopsystemen waren Smartphones (allen voran die von Apple) Vorreiter, was Festplattenverschlüsselung angeht. Klar können mobile Geräte verloren gehen, doch sind sie in vielem (Sandboxing etc.) einfach sicherer als Desktopsysteme, bei denen die Sicherheit (wie beim E-Mail-Protokoll, um nur ein Beispiel zu nennen) nicht von Beginn an mitgedacht war und erst später nachgerüstet werden musste.

3

Erstens würde ich Dir auch raten - wie @nick schrieb - die FaceID Nutzung für Keepassium auszuschalten.
In den Optionen:

  • Appsperre aktivieren: ja
  • FaceID verwenden: nein
  • Datenbanken schützen: ja
  • Automatisches Öffnen der vorherigen Datenbank: nein

Da das Handy grundsätzlich schon über FaceID geschützt wird, führt eine Zwangs-PIN-Eingabe zu einem zweiten Faktor, was besser ist.

Außerdem würde ich in Deiner Situation nicht die „Haupt-DB“ auf das Handy verlagern, sondern eine separate Keepass-DB anlegen, die speziell für mobil gedacht ist.
Dorthin dann selektiv das kopieren, was nötig ist und dabei die „schwerwiegenden“ Sachen weglassen. Ich würde da z.B. im Leben keine Finanz-Zugangsdaten auf das Mobiltelefon schieben.

Das ist zwar ein bisschen lästig, weil man einen Fork der DB-Inhalte hat, aber wenn die nicht mega-dynamisch sind, ist das leicht auszuhalten.

Klassischer Tradeoff Bequemlichkeit versus Sicherheit.

4

Ja, das hatte ich auch schon auf dem Zettel. Ich habe noch einmal überlegt und die Wahrscheinlichkeit, dass ich den Passwort-Manager überhaupt brauche, als eher gering eingestuft. Ich werde das Ganze jetzt erst einmal eine Weile beobachten und die Sache in ein paar Monaten neu bewerten. Bis dahin stelle ich Face ID auf jeden Fall ab. Die wichtigsten Zugänge habe ich ohnehin bereits mit Passkeys auf einem Yubikey abgespeichert. Ich werde schauen, ob ich das Entsperren der KeePassium-Datenbank auch mit dem Yubikey verknüpfen kann. Dann wäre Brute Force ohne den Yubikey vermutlich auch kein Thema mehr. KeePassium wird ja ohnehin als inhärent sicher eingestuft. Demnach scheint der UI-Zugang die kritischste Komponente zu sein.

Bei den Zugängen zu meinen Bankkonten bin ich ohnehin schon auf diese blöden Banking-Apps festgenagelt. Das sind auch so Blackboxen, bei denen man nur hoffen kann. Aber ich mache echt viel damit und hatte bislang noch keine Probleme. Das muss man auch dazu sagen. Mich hat an dem Konzept eher gestört, dass ich bei Verlust des Mobiltelefons praktisch nicht mehr handlungsfähig bin. Dieses Problem habe ich aber jetzt gelöst, indem ich ein altes iPhone als Zweitgerät eingerichtet habe.

Dann wäre da noch PayPal. Darauf kann ich unmöglich verzichten, auch unterwegs nicht. Was sich höchstens auslagern ließe, wären die ganzen Zugänge zu Onlineshops. Socken, Blumen oder Honig muss ich nicht sofort kaufen. Aber die interessieren auch nicht wirklich irgendjemanden. Da ist der Anbieter selbst häufig die Schwachstelle.

Was aber in die Kategorie „hoch schützenswert” gehört und selten mobil gebraucht wird, sind die ganzen Zertifikate (S/MIME, Elster usw.) sowie die Recoverykeys für Kryptowallets oder E2EE-verschlüsselte Datentresore, App-Passwörter usw. Diese könnte ich tatsächlich mal in einen eigenen Tresor packen, der auch nicht unbedingt über die Nextcloud synchronisiert werden müsste. Allerdings ist diese Synchronisation Teil meiner Backup-Strategie. Das muss ich mir mal genauer anschauen.

Danke für eure Anregungen und Tipps.

5

Es gibt es auch die Methode des Passwort Pepperings, bei der man Passwörter nicht ganz speichert und bei einer Passworteingabe noch manuell ein paar Zeichen eingibt. Selbst wenn die Passwortdatenbank gecrackt ist, kann man erstmal mit den Paaswörtern nichts anfangen.
Dazu hatte ich mal ein Thema hier im Forum erstellt.

6

Geht mir auch so. Offline- und lokale Offsite-Backups (Bankschließfach) habe ich ebenfalls, aber der Datenstand meiner synchronisierten Geräte ist aktueller.

Was mir noch aufgefallen ist und mehr für Strongbox als für KeePassium spricht: Letzteres legt beim Keyfile-Import im lokalen Dateisystem einen Ordner „KeePassium“ ein, wo als einziger Inhalt die KEYX-Datei hingepackt wird. Alles offen zugänglich in der Files-App. Strongbox legt dort kein Verzeichnis an und speichert die Schlüsseldatei intern.

Stimmt - wenn man auf dem Weg erstmal drin ist, kann sowohl bei KeePassium als auch bei Strongbox die KDBX-Datei aus dem internen Cache auf einen beliebigen Pfad exportiert werden.

Wie @Galaga oben erklärt hat, kann man den UI-Zugang aber gut absichern.

7

Ups, stimmt! Ich habe gerade nachgeschaut. Ich dachte, KeePassium importiert das Keyfile auch in einen sicheren Ablageort innerhalb der App. Das ist ein No-Go.

Danke für den Hinweis, das will ich so nicht stehen lassen. Das ist mir ein Kompromiss zu viel.

8

Ja, das ist so, aber ich sehe noch einen Unterschied zwischen einer Banking App, die ja vernünftige Schutzmechanismen hat, wie meist eine eigene PIN, die mit einem Handy geklaut wird (was ich als gestohlen melden kann) im Zustand, dass die App „aktiviert“ ist und dem offenlegen der vollen Zugangsdaten, PINs etc. für einen Dieb. Denn in letzterem Fall, kann er ja alles ändern und neu aufsetzen, was meist nur mit der App ohne Kenntnis der Klartextzugangsdaten mindestens schwieriger ist.

Daher, Banking Apps ja, aber die Zugangsklartextdaten aufs Handy nein.

Im Übrigen gibt es wirklich noch zwei Mechanismen:
a) Du kannst die Kepassium-DB in einen Cryptomator Container stecken.
b) Du kannst die Keepassium-DB zusätzlich mit einem Yubikey verrammeln: https://support.keepassium.com/kb/yubikey/
Sehr empfehlenswert IMHO.

Das bringt mich auch zu dem Tip, die Seeds für TOTP-Zugänge nur auf einem Yubikey direkt abzuspeichern und den iOS Yubico Authenticator zu nutzen.
Das hat den immensen Vorteil, dass die Seeds für die TOTP Fälle rein auf dem Yubikey bleiben (nicht etwa auf dem Handy und dort klaubar und eventuell auslesbar sind). Im Yubikey sind die Seeds nutzbar, aber eben nicht mehr von aussen auslesbar. Die Authenticator Software „enthält“ so gar nix und wenn das Handy damit geklaut wird, ist dieser Teil egal.
Ich kenne keinen anderen Authenticator, der das so zulässt. Im Gegenteil, oft können und wollen die die seeds in ihre Clouds kopieren bzw. es gibt einen Mechanismus, um das Zeugs zu „sichern“ / kopieren.

Wegen der oben diskutierten Exportoptionen würde ich in der Keepassium-DB auch nie TOTP-Sachen hinterlegen (Ausnahmen für Belanglosigkeiten wie harmlose Foren etc).

9

Wann soll das genau passieren? Ich sehe bei mir nur ein leeres Keepassium-Verzeichnis, wenn ich Keepassium geöffnet habe. Und die suche nach „keyx“ führt zu keinem Ergebnis.

10

Bei mir ist das schon so. In der Dateien-App habe ich ein Verzeichnis KeePassium, welches das Key-File beinhaltet.

Das wäre eine gute Lösung, wenn ich das mit dem Key-File doch noch gelöst bekomme.

Im Gegensatz zum Google Authenticator zeigt meine Authenticator-App die Seeds bzw. den QR-Code nachträglich auch nicht mehr an. Das hat mich erst zu dem Workflow gebracht, dass ich TOTP-Zugänge zunächst im KeePass abspeichere. Dort kann ich den QR-Code problemlos aufrufen und den TOTP auf meinen Mobiltelefonen anlegen.

11

Hm. Vielleicht sehe ich nix, weil meine Keepassium-DB in Cryptomator steckt?

12

Wie bekommst du die KeePass-DB in die Cryptomator-App auf dem Mobiltelefon? Ich gebe die WebDAV-URL in KeePassium ein und öffne die Datenbank dann dort. Ich sehe die Datenbank auf dem Mobiltelefon jedoch nicht. Nur das KeyFile. Hast du die Datenbank schon im zentralen Cloudspeicher in einem Cryptomator-Tresor abgelegt und öffnest sie auf dem Mobiltelefon quasi lokal zunächst in der Cryptomator-App?

13

Cryptomator greift per Webdav auf eine Cryptomator-Vault zu, die Nextcloud verfügbar macht.
Solange der Cryptomator-Tresor entsperrt ist auf iOS, sind dessen Inhalte in einer eigenen Sektion in der Dateien-App zu finden, also auch die Keepassium-DB.
Die DB dann ganz einfach in Keepassium öffnen.

14

@Cyberduck

Wie wurde es am Ende gelöst?

@Galaga
Wenn alles in der Cloud in Cryptomator-Containern steckt, landet das KeyFile dann nicht troztdem in der Files-App, so wie von dir oben weiter beschrieben? Oder habe ich jetzt irgendwas übersehen?

15

Bei Keepassium ist das so. Bei Strongbox nicht, denn dort wird das Keyfile intern in der App hinterlegt und ist für das Dateisystem nicht zugänglich.

16

Natürlich zeigt die Files App auch E2EE Inhalte von Cryptomator an, solange Du den Tresor offen hast (das ist ja das gewollte Feature).

Das ist dann aber logischerweise kein Problem mehr.

17

Da wird es dann aber um die KDBX-Datei gehen. Die KEYX-Datei soll ja sinnvollerweise nur lokal auf den Clients vorgehalten werden. Lokale Verzeichnisse kann man m.W. unter iOS/iPadOS nicht mit Cryptomator verschlüsseln.

18

@nick
Doch, das ist kein Problem. Ein Tresor kann auch lokal liegen.

@Galaga
Es klang so, als würde KeePassium immer lokal eine Kopie ablegen, die allgemein erreichbar ist. Daher meine Nachfrage.