📖 Dokumentation
Willkommen zur technischen Dokumentation von iKeePass. Hier findest du alle Informationen zur Nutzung und den unterstützten Formaten.
📚 Dokumentations-Uebersicht
| Thema | Beschreibung |
|---|---|
| 📱 iOS App Features | Alle Funktionen der iPhone & iPad App |
| 🖥️ macOS App Features | Alle Funktionen der Mac App |
| ⌨️ AutoType | Automatisches Eintippen von Anmeldedaten (macOS) |
| 🔑 AutoFill | Automatisches Ausfuellen von Passwoertern (iOS/iPadOS) |
| 📱 AutoFill Anleitung | Schritt-fuer-Schritt: Einrichten, Testen, Multi-Provider |
| 🌐 Chrome Erweiterung | AutoFill direkt im Browser (macOS) |
| ☁️ Cloud-Speicherung | Datenbank in der Cloud speichern (iOS) |
| 📥 Import aus der Passwörter-App | Übernahme per Credential Exchange, verschlüsselt und ohne Exportdatei |
| 🤖 MCP-Server | iKeePass aus Claude Code und anderen MCP-Clients bedienen (macOS) |
| 📜 Versionshistorie | Alle Versionen seit 2009 |
🔐 Unterstützte Formate
KDBX 3.x ✅ Vollständig unterstützt
| Komponente | Status |
|---|---|
| Verschlüsselung | AES-256-CBC |
| KDF | AES-KDF |
| Kompression | GZIP |
| Passwort | ✅ Unterstützt |
| Keyfile | ✅ Unterstützt |
KDBX 4.x ✅ Unterstützt
| Komponente | Status |
|---|---|
| Verschlüsselung | AES-256-CBC, ChaCha20 |
| KDF | AES-KDF, Argon2d, Argon2id |
| Kompression | GZIP |
| HMAC-Authentifizierung | ✅ Unterstützt |
🔒 Sicherheitsarchitektur
Verschlüsselungs-Pipeline
Key Derivation Functions
AES-KDF
- Standard KDF für KDBX 3.x
- Konfigurierbare Rundenzahl
- Typisch: 6.000 - 60.000 Runden
Argon2d
- Memory-hard KDF
- Resistent gegen GPU/ASIC Angriffe
- Parameter: Memory, Iterations, Parallelism
Argon2id
- Hybrid aus Argon2d und Argon2i
- Beste Balance aus Sicherheit und Performance
- Empfohlen für neue Datenbanken
☁️ Cloud-Speicherung (iOS)
iKeePass iOS nutzt den nativen iOS-Dateien-Dialog, um deine Datenbank in verschiedenen Cloud-Diensten zu speichern:
| Cloud-Dienst | Status |
|---|---|
| Apple iCloud Drive | ✅ Nativ integriert |
| Nextcloud | ✅ Unterstuetzt |
| Google Drive | ✅ Unterstuetzt |
| Microsoft OneDrive | ✅ Unterstuetzt |
| Dropbox | ✅ Unterstuetzt |
So funktioniert’s
- Installiere die Cloud-App (z.B. Nextcloud, Google Drive)
- Aktiviere den Dienst in der iOS “Dateien”-App
- Waehle beim Speichern/Oeffnen in iKeePass den Cloud-Speicherort
Vollstaendige Anleitung zur Cloud-Speicherung
📱 Plattform-Spezifisches
macOS (iKeePass)
| Komponente | Technologie |
|---|---|
| Language | Swift 6.0 |
| UI Framework | SwiftUI |
| Min. OS | macOS 14.0 (Sonoma) |
| State | @Observable |
| Layout | NavigationSplitView |
iOS (iKeePassIOS)
| Komponente | Technologie |
|---|---|
| Language | Swift 5.9 |
| UI Framework | SwiftUI |
| Min. OS | iOS 17.0 |
| State | @Observable |
| Navigation | TabView + NavigationStack |
| Biometrie | LocalAuthentication |
🔧 KeePass-Kompatibilität
iKeePass ist vollständig kompatibel mit:
- ✅ KeePass 2.x (Windows)
- ✅ KeePassXC (Cross-Platform)
- ✅ KeePassium (iOS/macOS)
- ✅ KeePass2Android (Android)
- ✅ MacPass (macOS)
Getestete Datenbanken
| Format | Version | Status |
|---|---|---|
| KDBX | 3.1 | ✅ Vollständig |
| KDBX | 4.0 | ✅ Vollständig |
| KDBX | 4.1 | ✅ Vollständig |
| KDB | 1.x | ⏳ Geplant |
📊 Features im Detail
Security Dashboard
Das integrierte Dashboard analysiert deine Passwörter:
| Analyse | Beschreibung |
|---|---|
| Security Score | Gesamtbewertung 0-100% |
| Schwache Passwörter | Kurz, einfach, keine Sonderzeichen |
| Doppelte Passwörter | Gleiche Passwörter mehrfach verwendet |
| Alte Passwörter | Nicht geändert seit >90 Tagen |
⏱️ Einmalpasswörter (OTP)
iKeePass erzeugt Einmalcodes selbst — eine zusätzliche Authenticator-App ist nicht nötig. Der Code steht direkt neben dem Passwort, zu dem er gehört.
Was unterstützt wird
| Eigenschaft | Werte |
|---|---|
| Verfahren | TOTP (zeitbasiert, RFC 6238) · HOTP (zählerbasiert, RFC 4226) |
| Algorithmen | SHA1 (Standard) · SHA256 · SHA512 |
| Stellen | 6 (Standard), 7 oder 8 |
| Intervall | 30 Sekunden (Standard), frei wählbar |
| Eingabe | otpauth://-Adresse aus dem QR-Code, oder Geheimnis von Hand |
SHA1 ist nicht etwa unsicher gewählt, sondern der Standard, den Google Authenticator und die meisten Dienste erwarten — das HMAC-Verfahren ist hier von den bekannten SHA1-Schwächen nicht betroffen.
Wo die Daten liegen
Die Parameter stehen als benutzerdefinierte Felder im Eintrag selbst, nicht in einer Nebendatei:
Damit wandern die Codes mit der Datenbank — ein Gerätewechsel überträgt sie ohne Neueinrichtung, und ein Backup der .kdbx sichert sie mit.
In der App
- Eigener OTP-Bereich mit allen Codes auf einen Blick, je mit Ringzähler
- Detailansicht hinter dem „…"-Knopf: Aussteller, Typ, Stellen, Intervall, Algorithmus — das Geheimnis nur auf ausdrücklichen Knopfdruck
- Ein-Klick-Kopieren des laufenden Codes
{TOTP}-Platzhalter in AutoType (macOS), damit der Code gleich mit eingetippt wird- Widget auf dem iPhone-Home-Bildschirm — die App legt vorberechnete Codes ab, kein Geheimnis verlässt sie
🔐 Die Kehrseite: Liegen Passwort und zweiter Faktor in derselben Datei, schützt der zweite Faktor nicht mehr gegen jemanden, der diese Datei samt Masterpasswort hat. Er schützt weiterhin gegen alles andere — geleakte Passwörter, Phishing, Wiederverwendung. Wer die Trennung braucht, führt eine zweite Datenbank nur für OTP-Einträge.
🔐 PassKeys
🚧 In Entwicklung. Die Datenhaltung steht, der eigene PassKeys-Bereich ist in den veröffentlichten Versionen noch ausgeblendet. Dieser Abschnitt beschreibt den Stand der Umsetzung.
PassKeys (FIDO2/WebAuthn) ersetzen das Passwort durch ein Schlüsselpaar: Der Dienst kennt nur den öffentlichen Teil, der private bleibt beim Nutzer. Phishing läuft damit ins Leere, denn ein PassKey funktioniert nur auf der Domain, für die er angelegt wurde.
Was iKeePass speichert
| Feld | Inhalt |
|---|---|
| Credential ID | Kennung des Schlüssels (Base64-URL) |
| RP ID / RP Name | Domain und Anzeigename des Dienstes, z. B. github.com / GitHub |
| User Name / Display Name | Konto beim Dienst |
| Public Key | Öffentlicher Schlüssel im COSE-Format |
| Algorithmus | ES256 (Standard), RS256, PS256 |
| Transports | internal, usb, nfc, ble |
| Sign Count | Zähler zur Klon-Erkennung |
| AAGUID | Kennung des Authenticators |
| Backup Eligible / State | Ob der Schlüssel synchronisierbar ist und es bereits ist |
Wie bei OTP liegt alles in benutzerdefinierten Feldern des Eintrags — die PassKeys wandern mit der .kdbx.
Was schon geht
- Anlegen, Suchen und Verwalten von PassKey-Einträgen
- Suche nach Domain und nach Credential ID
- Dublettenerkennung über die Credential ID
- Prüfung der Konfiguration auf fehlende oder unstimmige Felder
- Kennzahlen über alle PassKeys der Datenbank
- Fortschreiben des Sign Count zur Klon-Erkennung
Was noch fehlt
Das Anmelden mit einem PassKey aus iKeePass heraus — also die Rolle als vollwertiger Authenticator gegenüber dem Browser. Bis dahin ist der Bereich im Release ausgeblendet; im Entwicklungs-Build ist er sichtbar.
ℹ️ Unterschied zu OTP: Ein OTP-Code ergänzt das Passwort, ein PassKey ersetzt es. Beide Verfahren stehen in iKeePass nebeneinander und schließen sich nicht aus.
📥 Import aus der Apple-Passwörter-App
Bestandsdaten aus der Apple-Passwörter-App wandern über Credential Exchange nach iKeePass — den Standard, den Apple und die FIDO-Allianz (als FIDO CXP) genau dafür geschaffen haben.
⚠️ Voraussetzung: iOS 26 bzw. macOS 26 oder neuer. Die Schnittstelle gibt es auf älteren Systemen nicht.
Warum das besser ist als ein CSV-Export
Der übliche Weg zwischen Passwort-Managern ist eine CSV- oder XML-Datei: Sie liegt unverschlüsselt auf der Platte, landet im Papierkorb, in der Zeitmaschine, im Spotlight-Index. Credential Exchange umgeht das vollständig.
Die Zielapp erhält lediglich eine NSUserActivity mit einem Zugriffs-Token. Die eigentlichen Daten holt sie damit direkt beim System ab.
Was übernommen wird
Nicht nur Passwörter — alle Arten, die Apple ausliefert, bekommen in iKeePass einen passenden Eintragstyp samt Symbol:
| Art | In iKeePass |
|---|---|
| 🔑 Passwörter | Eintrag mit Titel, Benutzer, Passwort, URL |
| ⏱️ Bestätigungscodes | OTP-Felder im Eintrag — die Codes laufen sofort weiter |
| 🔐 Passkeys | Passkey-Felder im Eintrag |
| 📶 WLAN | Eigener Eintrag mit WLAN-Symbol |
| 💳 Zahlungskarten | Eigener Eintrag |
| 🖥️ SSH-Schlüssel | Eigener Eintrag |
| 🔧 API-Schlüssel | Eigener Eintrag |
| 🪪 Identitäten | Eigener Eintrag |
| 📝 Notizen | Eintrag mit Notiztext |
| 📋 Zusatzfelder | Als benutzerdefinierte Felder |
Der Ablauf
| Schritt | Was passiert |
|---|---|
| Vorschau | Jeder Eintrag wird aufgelistet, bevor irgendetwas geschrieben wird |
| Dublettenprüfung | Bereits vorhandene Einträge werden erkannt und übersprungen (abschaltbar) |
| Ordner übernehmen | Sammlungen der Passwörter-App werden als Ordner angelegt (abschaltbar) |
| Zielordner | Frei wählbar; der Import landet gebündelt an einer Stelle |
| Zusammenfassung | Importiert, übersprungene Dubletten, nicht unterstützte Einträge, angelegte Ordner |
| Rücknahme | Solange nicht gespeichert wurde, lässt sich der komplette Import zurücknehmen |
Herkunft bleibt erkennbar
Jeder importierte Eintrag bekommt ein Feld iKeePass Import mit Quelle und Zeitpunkt; in Liste, Kachel und Detailansicht erscheint dazu ein 📥. So ist später nachvollziehbar, was aus welchem Umzug stammt — und die Dublettenprüfung ignoriert dieses Feld beim Vergleich.
Technisch
| Baustein | Umsetzung |
|---|---|
| Schnittstelle | ASCredentialImportManager (AuthenticationServices) |
| Auslöser | NSUserActivity vom Typ ASCredentialExchangeActivity |
| Übergabe | Zugriffs-Token statt Daten; die App holt sie beim System ab |
| Formatversion | 1.0 |
| Voraussetzung in der App | AutoFill-Erweiterung, die SupportsCredentialExchange meldet |
👉 Schritt-für-Schritt-Anleitungen für iPhone, iPad und Mac stehen in der FAQ.
🤖 MCP-Server (KI-Assistenten)
Die macOS-App bringt einen MCP-Server mit: iKeePass lässt sich aus Claude Code und anderen Clients bedienen, die das Model Context Protocol sprechen. Ein Assistent kann damit die Datenbank durchsuchen, Sicherheitsanalysen fahren, Einträge anlegen und — nach ausdrücklicher Bestätigung — einzelne Geheimnisse abrufen.
🔐 Standardmäßig ausgeschaltet. Der Zugang muss in den Einstellungen bewusst eingeschaltet werden. Ohne entsperrte Datenbank passiert ohnehin nichts.
Warum das nicht so gefährlich ist, wie es klingt
Der wichtigste Entwurfsgedanke: 20 der 34 Werkzeuge kommen ohne jeden Geheimniszugriff aus. Ein vollständiger Sicherheits-Audit — schwache Passwörter, Dubletten, ablaufende Einträge, HIBP-Abgleich — läuft ohne einen einzigen Bestätigungsdialog.
Fünf Sperren vor jedem Zugriff
Die Verbindung läuft über einen lokalen Unix-Socket, nicht über das Netzwerk. Die Gegenstelle wird zusätzlich geprüft, damit nicht ein beliebiger Prozess die Verbindung übernimmt.
Vier Freigabestufen
| Stufe | Umfang | Was verlangt wird |
|---|---|---|
| S0 | Status, Passwortgenerator, Richtlinien | nichts — keine Freigabe nötig |
| S1 | Metadaten, Ordner, Kennzahlen | Touch ID oder Masterpasswort |
| S2 | Geheimnisse (Passwort, Feld, TOTP-Code) | S1 und ein Bestätigungsdialog je Aufruf |
| S3 | Schreibende Vorgänge | S1 und ein Bestätigungsdialog je Vorgang |
Das Doppelbudget
Eine Freigabe ist zweifach begrenzt — an Zeit und an Anzahl. Was zuerst aufgebraucht ist, beendet sie:
| Einstellung | Standard |
|---|---|
| Lesefreigabe: Dauer | 15 Minuten |
| Lesefreigabe: Zugriffe | 50 |
| Geheimnisfreigabe: Dauer | 5 Minuten |
| Geheimnisfreigabe: Zugriffe | 5 |
| Verfall bei Untätigkeit | 5 Minuten |
| Schreiben erlaubt | ❌ aus |
| Biometrie bevorzugt | ✅ an |
Alle Werte sind in den Einstellungen änderbar. Ein ikeepass_lock ist jederzeit und ohne Rückfrage möglich — der Panikschalter.
34 Werkzeuge in sieben Gruppen
| Gruppe | Thema | Beispiele |
|---|---|---|
| A | Status und Sitzung | ikeepass_status, ikeepass_lock, ikeepass_open_database |
| B | Navigation und Metadaten | ikeepass_search_entries, ikeepass_get_entry, ikeepass_list_tags |
| C | Geheimnisse | ikeepass_get_password, ikeepass_get_totp, ikeepass_use_credential |
| D | Schreibende Vorgänge | ikeepass_create_entry, ikeepass_update_entry, ikeepass_rotate_password |
| E | Analyse ohne Geheimnisausgabe | ikeepass_health_report, ikeepass_check_pwned, ikeepass_list_duplicates |
| F | Ohne Datenbankzugriff | ikeepass_generate_password, ikeepass_password_strength, ikeepass_parse_otp_uri |
| G | Audit und Richtlinien | ikeepass_audit_log, ikeepass_get_policy |
Was bewusst nicht angeboten wird
Diese Sperren sind Teil der Sicherheitszusage, nicht eine Lücke im Funktionsumfang:
| Nicht verfügbar | Grund |
|---|---|
| 🔑 Masterpasswort | Es verlässt die App unter keinen Umständen |
| 📤 Datenbankexport | Ein Aufruf würde die gesamte Datenbank herausgeben |
| ⏱️ TOTP-Secrets | Nur der laufende Code wird herausgegeben, nie das Geheimnis dahinter |
| 🔐 Passkey-Privatschlüssel | Nicht auslesbar, auch nicht mit Freigabe |
| 📎 Anhang-Inhalte | Dateien bleiben in der Datenbank |
| 📚 Sammelabfragen | Kein „gib mir alle Passwörter" |
| 🗑️ Endgültiges Löschen | Einträge wandern höchstens ins Archiv |
Auch beim Öffnen einer Datenbank gilt: Der Agent darf nur aus der Liste der zuletzt geöffneten wählen — ein freier Pfad ist unzulässig, und das Passwort läuft ausschließlich über den Dialog der App.
Zugriffshistorie
Jeder Zugriff wird protokolliert: Zeitpunkt, Client (etwa „Claude Code"), Prozesskennung, Werkzeug und Ergebnis. Die Historie lässt sich in der App einsehen — und über ikeepass_audit_log auch vom Assistenten selbst, damit er Rechenschaft über sein eigenes Tun ablegen kann.
Typische Anwendungsfälle
- 🩺 „Prüfe meine Datenbank auf schwache und doppelte Passwörter" — läuft vollständig ohne Geheimniszugriff
- 🔄 „Erzeuge ein neues Passwort für GitHub und trage es ein" — ein Bestätigungsdialog für den Schreibvorgang
- 📋 „Wie viele Einträge laufen im nächsten Monat ab?" — reine Metadaten
- ⏱️ „Lege einen OTP-Eintrag aus dieser
otpauth://-Adresse an" — Secret im Dialog maskiert
ℹ️ Nur macOS. Die iOS-App hat keinen MCP-Server; auf dem iPhone gibt es keine vergleichbare Schnittstelle für lokale Prozesse.
🛠️ Entwickler-Informationen
Architektur
Dependencies
- CommonCrypto - AES Verschlüsselung
- CryptoKit - SHA-256, HMAC
- zlib - GZIP Kompression
- Argon2 - Key Derivation (extern)