Zugangsdaten mit mehreren Feldern

Zugangsdaten sind auch der integrierte Kartentyp credential. Die generische Feldansicht ordnet nicht geheime Metadaten von Zugangsdaten gewöhnlichen Feldern und geheime Felder des Bodys sensitive zu, ohne beim Lesen ältere Bytes umzuschreiben. memories card field unterstützt dasselbe geordnete Schema; erfolgreiche Änderungen an Textfeldern behalten den strukturierten Body der Zugangsdaten bei, den bestehende Verbraucher verwenden. Binäre Zugangsdaten im älteren Format lehnen die Migration zu generischen Feldern ab, statt Bytes zu verlieren.

Ein Zugangsdaten-Eintrag kann mehrere unabhängige, optionale Felder enthalten. Alle können leer sein.

Content.credential (nicht geheim, kann sicher aufgelistet werden):

{
  "username": "octo",
  "url": "https://github.com",
  "notes": "work account",
  "custom": [{"name": "team", "value": "core"}],
  "secret_fields": ["password", "otp", "api_key", "pin"],
  "otp": {"digits": 6, "period": 30, "algorithm": "sha1"}
}

Strukturierter Body (mit dem Tresor verschlüsselt, als base64url in body):

{"memories.credential": 2, "password": "…", "otp": "…", "api_key": "…",
 "custom": [{"name": "pin", "value": "…"}]}

Kompatibilität und Migration

• Zugangsdaten im älteren Format behalten ihre unverarbeiteten geheimen Bytes in body. Sie werden unverändert gelesen: Ein otpauth://-Wert oder ein Titel, der mit OTP: beginnt, wird otp zugeordnet, Zugangsdaten mit HTTP-Authentifizierung oder erlaubten Hosts werden api_key zugeordnet, alles andere wird password zugeordnet. Binäre Geheimnisse im älteren Format (Schlüssel, Zertifikate) funktionieren weiterhin unverändert; sie haben lediglich keine Textfelder.
• Jeder bestehende Verbraucher eines einzelnen Geheimnisses (credential copy ohne --field, HTTP-Injektion, Run-Bindungen, Proxys, Login-Export) verwendet das primäre Geheimnis: die Bytes im älteren Format oder das erste nicht leere Feld aus password, api_key, otp und dem ersten geheimen benutzerdefinierten Feld.
• Die Migration erfolgt bei Bedarf: Jeder credential_set-Schreibvorgang auf Zugangsdaten im älteren Format schreibt sie im strukturierten Format neu und legt den bisherigen Wert im zugeordneten Feld ab. memories credential migrate VAULT ASSET führt dies ohne weitere Änderung aus. Die vorherige Revision bleibt im Verlauf erhalten, sodass keine Daten verloren gehen.

CLI

memories credential set VAULT [ASSET] [--title T] [--username U] [--url U] [--notes N]
    [--password] [--api-key] [--otp [--otp-digits 6|8] [--otp-period 30|60] [--otp-algorithm sha1|sha256|sha512]]
    [--field NAME=VALUE]... [--secret-field NAME]... [--remove NAME]...
memories credential show VAULT ASSET          # non-secret fields + names of secret fields
memories credential get VAULT ASSET --field NAME [--reveal]   # secret fields need --reveal
memories credential copy VAULT ASSET [--field NAME]           # clipboard, never printed
memories credential otp VAULT ASSET           # code from the otp field
memories credential migrate VAULT ASSET

Geheime Werte werden ausschließlich über Eingabeaufforderungen mit verdeckter Eingabe (--password, --api-key, --otp, --secret-field) eingegeben, niemals als Argumente. Eine leere Eingabe löscht den Feldinhalt.

Dienstanfragen

• credential_set {vault, asset?, title?, fields: {username?, password?, otp?, otp_params?, api_key?, url?, notes?, custom: [{name, value, secret}], remove: [name]}} — null oder ein fehlender Wert behält ein Feld bei, "" leert es. Erfordert erhöhte Berechtigungen.
• credential_show {vault, asset} — Ansicht ohne geheime Werte; erfordert erhöhte Berechtigungen.
• credential_copy {vault, asset, label?, field?} — ein Feld (als credential.field.copy protokolliert); erfordert erhöhte Berechtigungen.
• otp_code {vault, asset} — akzeptiert auch Zugangsdaten mit einem otp-Feld.

Gehosteter Berechtigungsumfang: credential_show/credential_copy benötigen Leserechte, credential_set benötigt Schreibrechte.

MCP

• credential_fields (Lesefreigabe): nicht geheime Felder und die Namen geheimer Felder; niemals geheime Werte.
• credential_reveal (allow_all-Freigabe): ein Feld; erfordert intent: "reveal_plaintext" und eine kurze Begründung in reason. Wird als credential.field.reveal protokolliert. Das Kopieren des gesamten Geheimnisses ist über MCP nicht verfügbar.
• sealed_reveal akzeptiert ein optionales field für versiegelte strukturierte Zugangsdaten.

Gehostetes Center und Ende-zu-Ende-Synchronisierung

Das RPC des gehosteten Centers akzeptiert credential_show (Lesen) und credential_set (Schreiben). Bei Ende-zu-Ende-Zugangsdaten (e2e) darf die Kopie im Center ausschließlich Deskriptoren enthalten: credential_set weist jedes nicht leere geheime Feld zurück, und geheime Werte werden ausschließlich innerhalb von für Geräte versiegelten Umschlägen übertragen.

Der Klartext versiegelter strukturierter Zugangsdaten ist entweder der strukturierte Body selbst oder {"meta": <non-secret fields>, "body": "<structured body>"}. Auf einem gekoppelten Gerät:

memories device sealed-get --vault V --card C --field username
memories device sealed-get --vault V --card C --field password --reveal
memories device sealed-get --vault V --card C --otp

Ohne --reveal/--field/--otp werden nur Deskriptoren und Namen geheimer Felder ausgegeben. Umschläge mit einem einzelnen Geheimnis im älteren Format verhalten sich wie bisher.

Mobil

Neue Zugangsdaten öffnen ein in Abschnitte gegliedertes Formular (Anmeldung, Einmalcode, API, Weitere, benutzerdefinierte Felder mit einem Schalter für geheime Werte). Alle Felder sind optional; der Name wird standardmäßig aus dem Benutzernamen oder dem URL-Host übernommen und beim Speichern nur dann abgefragt, wenn er noch leer ist. Die Detailansicht kopiert nicht geheime Felder direkt; geheime Felder und der aktuelle OTP-Code (mit Countdown) erfordern bei aktiviertem biometrischem Schutz die Systemsperre.