Ein Geheimnis, das nie sichtbar werden darf
Szene 10 von 13
Ein Zugangscode musste von einer autorisierten Quelle direkt in eine Konfiguration fließen — ohne je in einer Nachricht, einem Protokoll oder einer Aufnahme zu erscheinen.
Erklärung
Ein Geheimnis, das einmal in einem Chat-Verlauf, einem Protokoll oder einer Videoaufnahme steht, ist kompromittiert — unabhängig davon, ob es später gelöscht wird. Die Regel war deshalb nicht „vorsichtig damit umgehen“, sondern strukturell: der Wert wurde nie von einer Instanz gelesen, die ihn hätte ausgeben können. Für die abschließende Bildschirmaufnahme kam eine zweite, unabhängige Vorsichtsmaßnahme hinzu: die Sekunden der Code-Eingabe wurden nachträglich verwischt — und diese Verwischung wurde nicht einfach angewendet und geglaubt, sondern sekündlich abgetastet und an zwei gezielten Vollbild-Ausschnitten kontrolliert, bevor die Aufnahme irgendwo verwendet wurde. Zwei getrennte Schutzschichten: eine, die das Geheimnis nie erzeugen lässt, und eine, die eine sichtbare Eingabe im Nachhinein unkenntlich macht und genau diese Unkenntlichkeit kontrolliert.
Zwei getrennte Schutzschichten
- Autorisierte Quelle
- Der einzige Ort, an dem ein Geheimnis überhaupt gelesen werden darf.
- Blinder Kanal
- Ein Übertragungsweg, der den Wert weiterreicht, ohne ihn je auszugeben oder zu protokollieren.
- Nachprüfbare Verwischung
- Eine Bildveränderung, deren Wirksamkeit sekündlich abgetastet und an zwei gezielten Vollbild-Ausschnitten kontrolliert wird.
Selbst ausprobieren
Nennt einen Ort in eurem eigenen Arbeitsablauf, an dem ein Geheimnis heute sichtbar wird, obwohl es nicht müsste (ein Terminal-Verlauf, ein Chat, ein Screenshot).
Belege
Ausführungsanweisung · blinder Kanal · docs(ios): reviewer-code alignment — controller lacks ASC access; exact owner action recorded
2026-09-23 · docs/lernbegleiter/engineering/app-review-reconciled-handoff-2026-09-23_08-34-54.md · 1e18520471a7bf9290a6f6a65eae40e4b695b16c
**Exact owner action required (one of two; no value is ever typed into a chat, report or log):** - **B (host side, recommended — matches the code path Apple already holds):** on study-dev, as the deploy user, replace the value of `STUDY_REVIEW_OTP_CODE` in `/etc/lernvisite/instance.env` with the six digits from ASC → App Review Information → Sign-In Information → Password, then `sudo systemctl daemon-reload && sudo systemctl restart lernvisite.service` (unit loads the file via `EnvironmentFile=`; see `web-review-otp-400-diagnosis-2026-09-23_06-42-24.md`). Access path on record: `tsh ssh --proxy=tpfra.emedys.com <besitzer>@study-dev` (`docs/infra/DEVELOPMENT-AGENT-HANDOVER.md:66`). Edit with an editor, not with a command line containing the value. Tell me "aligned" (no value). - **A (ASC side):** read the current six digits from `instance.env` on study-dev yourself and set the ASC Password field to it (ASC web session must be yours; I will not sign in). After either: I run the outside-in journey (request → verify → `/auth/profile` 200) and record it as execution proof, then ask the controller for the `auth.review_otp_bypass` audit row (timestamp + account). Receipt ≠ execution: both recorded separately before READY.
Verwischungsprüfung · sekündlich abgetastet · evidence(ios): final TF 1.0 (10) review recording (masked), run receipts, web-side enrollment finding
2026-09-23 · docs/lernbegleiter/engineering/ios-review-recording-tf10-2026-09-23_09-39-26.md · 768ebb73b0f767f1147c6fc94b8ec03325cc27a5
Method: one frame per second across cut-relative 152–178 s (contact sheet) plus full-resolution crops of the field region at 166 s and 171 s. Result: the code field and the keyboard suggestion strip are uniformly blurred from 155 s to 174 s (entry started at ~157 s, "Anmelden" at ~171 s); no digit is legible; the on-screen keypad shows only its fixed 0–9 keys. The first 4 s of the cut start on the dashboard (the phone's wallpaper frames at raw 663–664 s are excluded). Published cut SHA256 `0cd5020b36a324df…`, 378 s, 1206×2622, 30 fps, no audio.
Mit meinem Konto im Hörsaal öffnen →