Deterministisches, mentales Master‑System für Self‑Custody & Zugangssicherheit

Fragen Wallet
, , , ,
1

Bitte nutze die :magnifying_glass_tilted_left: Suchfunktion bevor du eine Frage stellst!

„XXX – deterministisches, mentales Master‑System für Self‑Custody & Zugangssicherheit (Open‑Source‑Konzept)“

Hallo zusammen,

ich möchte euch ein Projekt vorstellen, an dem ich seit einiger Zeit intensiv arbeite und zu dem ich gerne Feedback, kritische Fragen und ggf. Mitstreiter aus der Community gewinnen würde.

YKurz gesagt:
Es geht um ein deterministisches Master‑System für Geheimnisse und Zugänge, das ohne zentrale Tresore und ohne klassische Seed‑Zettel auskommt. Das Ziel ist, ein Modell zu entwickeln, das sowohl für Alltagspasswörter als auch für Bitcoin‑Self‑Custody und andere Hochsicherheits‑Anwendungen besser zur „kognitiven Realität“ von Menschen passt.

Ausgangsproblem

  • Heute verteilen sich digitale Identitäten auf zig Konten, Geräte und Wallets.
  • Passwort‑Wiederverwendung, unsichere Muster und überfordernde Komplexität sind die Regel, nicht die Ausnahme.
  • Klassische Passwort‑Manager lösen das Problem oft, indem sie alles in einem zentralen Tresor bündeln. Hardware‑Wallets verschieben das Problem in Richtung Seed‑Backup (Single Point of Failure).
  • Dazu kommt: Viele Menschen sind in der Praxis mit den empfohlenen Sicherheits‑Workflows überfordert – gerade langfristig und im Nachlass‑/Family‑Office‑Kontext.

Grundidee von XXX (ohne technische Details)

XXX verfolgt einen anderen Ansatz:

  • Statt viele einzelne Passwörter oder Seeds zu speichern, steht eine kleine, klar definierte mentale Struktur im Zentrum.
  • Aus wenigen mentalen Ankern in Kombination mit gerätegebundenen Faktoren werden deterministisch alle benötigten Geheimnisse für unterschiedliche „Slots“ (Konten, Wallets, Systeme) abgeleitet.
  • Es gibt keinen zentralen Klartext‑Tresor und keinen universellen Seed‑Zettel, der alles entscheidet.
  • Das System ist von Anfang an auf Offline‑Nutzung und Dezentralität ausgelegt; Server sind optional und dienen nur Komfortfunktionen (Sync, Freigabe‑Workflows etc.).

Wichtig: Ich teile hier bewusst keine exakten Ableitungsformeln, keine konkreten Parameter und keinen Pseudocode, sondern nur das Architektur‑Prinzip und das Sicherheitsmodell.

Sicherheitsmodell (High Level)

  • Mehrere voneinander getrennte Komponenten:
    • ein zentraler mentaler Anker (Master),
    • weitere mentale Strukturteile,
    • gerätegebundene Faktoren,
    • optional zusätzliche Hochsicherheits‑Layer.
  • Für „normale“ Anwendungsfälle reichen wenige Komponenten; für Hochsicherheit sind alle Layer plus organisatorische Maßnahmen vorgesehen (Multi‑Party‑Freigaben, Nachlass‑Prozesse usw.).
  • Ziel ist, dass kein einzelner Leak (Datenbank, Gerät, Zettel, Phishing) ausreicht, um alles zu kompromittieren.

Bezug zu Bitcoin / Self‑Custody

Für Bitcoin sehe ich vor allem drei Anwendungsfelder:

  • Self‑Custody ohne klassischen Seed‑Zettel:
    Schlüsselmaterial wird deterministisch aus der mentalen Struktur abgeleitet, anstatt als einmalige 24‑Wort‑Phrase auf Papier zu liegen.
  • Multi‑Sig / Family‑Office / Nachlass:
    Unterschiedliche Personen/Rollen erhalten eigene Slots und Sicherheitsstufen; komplexe Freigabestrukturen lassen sich kognitiv und organisatorisch besser abbilden.
  • Zukünftige Strukturen wie Merkle‑basierte Output‑Modelle:
    Das System ist so gedacht, dass es auch mit flexibleren Output‑/Policy‑Modellen zusammenspielen kann, ohne dass On‑Chain‑Mehrkomplexität entsteht.

Ich behaupte ausdrücklich nicht, dass das Projekt fertige Produkte ersetzt oder dass die Kryptografie „besser“ als bei bestehenden Lösungen ist. Es geht um ein anderes Architektur‑Paradigma, das ich mit der Community diskutieren und weiterentwickeln möchte.

Open‑Source‑Gedanke und Mitstreiter

Mein Ziel ist, die sicherheitskritische Kernlogik perspektivisch offen spezifiziert und überprüfbar zu machen (Open‑Source‑Kern, formale Spezifikation, Audits etc.).
Aktuell arbeite ich an Whitepaper, Bedrohungsmodell und Prototyp‑Konzepten.

Ich suche insbesondere:

  • Menschen mit Erfahrung in Bitcoin‑/Lightning‑Entwicklung,
  • Kryptografie‑ und Sicherheits‑Ingenieure
  • sowie gern auch kritische Denker, die das Konzept zerpflücken und auf Schwachstellen abklopfen.

Es geht mir an dieser Stelle nicht um Token‑Sales, Altcoins oder kurzfristige „Investments“, sondern um fachlichen Austausch und langfristige Architektur.

Wer Interesse hat, kann hier im Thread Fragen stellen oder mir eine Direktnachricht schicken. Bei ernsthaftem Interesse und unterschriebenem NDA gibt es dann einen Zugang zu einem strukturierten Informations‑Ordner mit mehr Details (Architektur‑Übersicht, Use‑Cases, Risikoanalyse), aber weiterhin ohne vollständige „Nachbau‑Anleitung“.

Vielen Dank fürs Lesen – ich freue mich auf konstruktive Kritik und Rückfragen.

1 „Gefällt mir“
2

Ich bin mir nicht sicher, ob ich Dein Projekt wirklich durchdringe.

Wie soll sich der Nutzer daran erinnern, wie viele Layer er für das jeweilige Passwort benutzt hat… M.E. sind immer alle Layer nötig.

Am Anfang Deines Posts dachte ich noch, es ginge um eine spezielle Memory Technik. Am Ende wurde klar, dass es um Software/ Technik geht. Anwendungsbeispiele/-szenarien würde helfen, Dein System besser nachvollziehen zu können.

1 „Gefällt mir“
3

Nette Idee eigentlich.

Was ist denn, wenn mein Gerät gestohlen wird oder ich einen Schlag auf den Kopf bekomme und einen Anker vergesse.

Bin ich dann für immer von allem ausgesperrt. Falls nein, wie komme ich dann wieder ran, aber nicht jemand der z.B. mein Gerät gestohlen hat, wir beide hätten dann einen Teil des Zugangscodes, wenn ich das richtig verstehe, wer entscheidet dann wie, wer den Zugang bekommt?

Meinst du genügt das um genügend Sicherheit in den Key zu bekommen?

Und so würde ich meine Private Keys in Form meiner Gedanken und Geräte immer bei mir tragen?

1 „Gefällt mir“
4

Danke für die kritischen Rückfragen, genau dafür habe ich das hier eingestellt :blush:
Ich versuche es etwas klarer zu machen, ohne in interne Details oder Formeln abzurutschen.

1. „Was ist, wenn Gerät weg ist oder ich einen Anker vergesse?“

Das System ist bewusst nicht so gedacht, dass ein einzelner mentaler Anker oder ein einzelnes Gerät alles entscheidet.
Es gibt drei Ebenen, mit denen man solche Szenarien abfedern kann:

  • Für „normale“ Zugänge (Mail, Social Media etc.) reicht eine relativ einfache Kombination, die man im Zweifel neu setzen oder über klassische Wege wiederherstellen kann.
  • Für Hochsicherheit (Vermögen, Nachlass, Admin‑Zugänge) kommen zusätzliche Layer und organisatorische Mechanismen dazu – z.B. definierte Vertrauenspersonen oder Multi‑Party‑Freigaben, die im Ernstfall helfen können, ohne dass irgendeine Einzelperson die komplette Kontrolle hat.
  • Es ist explizit Teil des Konzepts, dass man Recovery‑Pfade planen kann, die nicht an ein einziges Gerät und nicht an eine einzige Person gebunden sind.

Kurz: Ein Schlag auf den Kopf oder ein geklautes Gerät soll im Hochsicherheits‑Bereich nicht automatisch „Ende“ bedeuten – aber auch nicht dazu führen, dass ein Dieb mit einem Gerät und einem halben Anker alles bekommt.

2. „Trage ich dann meine Private Keys in meinem Kopf mit mir herum?“

Nein, nicht 1:1.
Die Idee ist eher:

  • Im Kopf liegt eine Struktur, aus der sich Schlüsselmaterial deterministisch ableiten lässt.
  • Die konkrete Ableitung läuft immer über Software auf einem Gerät, mit zusätzlichen Faktoren (z.B. Pepper) – nicht im Kopf per Kopfrechnen.
  • Der mentale Teil allein reicht nicht, das Gerät allein reicht ebenfalls nicht; erst die Kombination plus ein paar weitere Rahmenbedingungen ergibt einen funktionsfähigen Schlüssel.

Damit unterscheidet sich das deutlich vom „Seed auswendig lernen“‑Ansatz:
Der Seed ist der Schlüssel.
Hier ist der Kopf nur ein Teil der Gleichung.

3. „Wie soll sich der Nutzer merken, welche Layer er wo benutzt?“

Das wäre tatsächlich unbenutzbar, wenn der Mensch das frei im Kopf organisieren müsste.
Genau deswegen ist die Idee:

  • Die App führt den Nutzer durch eine klar definierte Struktur (Kategorien, Sicherheitsstufen, Slots).
  • Der Nutzer muss sich nicht merken „bei diesem Login Layer 1+3, bei jenem 1+2+4“, sondern er wählt z.B. „Alltag“, „Finanzen“, „Hochsicherheit“ – die genaue Kombination der Layer hängt an der Slot‑Konfiguration, nicht im Kopf des Nutzers.
  • Die mentale Komponente bleibt bewusst klein und stabil, die Variabilität liegt in der Architektur.

Mir ist wichtig:
Ich behaupte nicht, dass das alles schon fertig, perfekt oder für jeden geeignet ist.
Es ist ein Architektur‑Vorschlag, der ein paar strukturelle Schwächen klassischer Seed‑/Tresor‑Modelle anders adressieren will.
Eure Fragen helfen mir sehr, die blinden Flecken und Kommunikationsprobleme zu sehen – also gerne weiter kritisch nachhaken :blush:

5

Hört sich schon fast zu komplex an, um damit die breite Masse zu adressieren.

Aber kann man jetzt schwer abschätzen, auch wegen weiteren Schwachpunkten, solang man nicht konkret weiß, wie es funktioniert.

Aber ist auf jeden Fall interessant :slight_smile:

Der Gedanke ist cool.

Nachteil zum Seed lernen wäre, dass man ohne das Gerät oder die Software evtl. nicht mehr rannkommt, wenn man zB. in ein anderes Land flüchtet.

Nachteil zum Seed im Bankschließfach wäre, dass man so relativ leicht erpressbar ist, hält dir jemand eine Knarre an den Kopf, kannst du für ihn sofort deinen Seed “ausrechnen” und das weiß er uU.

1 „Gefällt mir“
6

Danke dir, genau solche Einwände brauche ich, um zu sehen, wo das Konzept noch schlecht erklärt ist :blush:

1. „Hört sich schon fast zu komplex an für die breite Masse“

Wichtig ist:
Die ganze Geschichte mit „Vertrauenspersonen / Multi‑Party‑Freigaben“ ist nur für die Hochsicherheits‑Ecke gedacht (größere Vermögen, Nachlass, Firmen‑/Admin‑Zugänge).

Für normale Nutzerfälle soll das deutlich simpler aussehen, z.B.:

  • eine Kategorie „Alltag“ mit wenigen, immer gleich abgefragten Komponenten,
  • eine Kategorie „Finanzen“ mit einem zusätzlichen Schritt,
  • und nur wer will, schaltet die „Maximalvariante“ mit mehreren Beteiligten frei.

Also nicht: jeder muss ständig ein komplexes Ritual durchlaufen,
sondern: die Architektur kann sehr komplex, muss aber im Alltag nicht so genutzt werden.

2. „Ohne Gerät / Software komme ich evtl. nicht ran (Flucht ins andere Land)“

Ja, das ist ein Trade‑off. Ich sehe drei Ebenen:

  • Das System ist bewusst so gebaut, dass Kopf alleine nicht reicht – sonst wäre man unter physischem Zwang zu leicht erpressbar.
  • Gleichzeitig soll es aber möglich sein, mit relativ wenig Technik (z.B. einem frischen Standard‑Gerät + App) und der eigenen Struktur wieder handlungsfähig zu werden, selbst wenn man unterwegs alles verliert.
  • Für Extrem‑Szenarien wie Flucht etc. müsste man gezielt Slots definieren, die genau dafür optimiert sind (wenig Technik, dafür mehr mentale Last) – das ist eher ein Spezial‑Use‑Case.

Ich behaupte nicht, dass das System alle Flucht‑Szenarien perfekt abdeckt, aber es bietet mehr Gestaltungsspielraum als „ein Seed im Bankschließfach oder im Kopf“.

3. „Erpressbarkeit: Seed im Kopf vs. Struktur im Kopf“

Genau hier sehe ich einen Vorteil:

  • Beim gelernten Seed im Kopf weiß der Angreifer: Wenn er dich zwingt, kannst du ihm in einem Satz alles sagen.
  • Bei meinem Ansatz ist der Kopf nur ein Teil der Gleichung; selbst wenn man unter Druck Teile der Struktur preisgibt, fehlen im Idealfall noch weitere Komponenten (z.B. Gerätefaktor, Chili‑Layer, organisatorische Hürde), damit wirklich alle hochkritischen Zugänge offen sind.

Das löst das Problem „$5‑Wrench‑Attack“ nicht vollständig – das kann kein System –, aber es macht es schwerer, sofort den kompletten Zugriff zu bekommen. Man kann eher für bestimmte Kategorien/Volumina Grenzen einziehen.

Mir ist klar, dass das nach Text noch abstrakt wirkt.
Die nächsten Schritte für mich sind genau das, was du ansprichst: konkrete Anwendungsszenarien und Beispiele (z.B. „normale Privatperson“, „Selbstständiger mit Online‑Business“, „Family Office / Erbe“), damit man sehen kann, wie viel davon am Ende wirklich komplex beim Nutzer landet – und was im Hintergrund die Architektur erledigt.

7

Ich habe nur den Eingangs-Post gelesen. Die restlichen Antworten hier nur überflogen. Das ähnelt mir hier alles ein wenig zu sehr der Diskussionsweise einer KI.

Mir fällt zu „zentraler mentaler Anker“ lediglich ein, dass damit das System zum Scheitern verurteilt ist. Sauber modellierte Prozesse und Systeme sind so gestaltet, dass eine Fehlertoleranz gegenüber dem Faktor Mensch eingebaut ist. Der Mensch ist der größte Schwachpunkt in jedem System und dessen Fehler wird versucht durch Einbau von Redundanzen etc. entgegenzuwirken. Ein deterministisches System auf Basis eines nicht deterministischen Schlüsselelements (der Mensch) aufzubauen kann nicht funktionieren.

1 „Gefällt mir“
8

Und wie ist die definiert, m

Und wo ist die klare Definition?

9

Ich bin da ganz transparent: Ich komme nicht aus der IT‑ oder Kryptografie‑Ecke, sondern bin ursprünglich kompletter Laie gewesen. Gerade deshalb habe ich die bestehenden Systeme sehr „naiv“ hinterfragt – vor allem den aus meiner Sicht kritischen Punkt, dass vieles an einem Single Point of Failure (oder bestenfalls zwei Punkten) hängt: ein Gerät, ein Seed, ein Tresor, ein Login.

Weil mir das nicht gereicht hat, habe ich das Konzept mit Unterstützung von KI‑Systemen erarbeitet. Die KI ist für mich so etwas wie ein zentraler Wissensanker im Entstehungsprozess gewesen: Sie bringt das Fachwissen, ich bringe die Problemwahrnehmung, die Alltags‑Perspektive und die Anforderungen. Das eigentliche Ziel war dabei immer, ein offline‑fähiges System zu bauen, das weder von laufenden Servern noch von irgendeiner externen KI abhängig ist – und das damit auch deutlich robuster gegenüber zukünftigen Angriffsmodellen (inkl. leistungsfähigerer Rechner/Quantenrechner) sein soll.

Zu deinem Punkt „zentraler mentaler Anker = Scheitern“:
Ich bin völlig bei dir, dass der Mensch der größte Unsicherheitsfaktor ist und dass gute Systeme Fehlertoleranz einbauen müssen. Der „mentale Anker“ ist bei mir deshalb nicht das einzige Schlüsselelement, sondern nur ein Teil eines mehrschichtigen Modells. Die Idee ist gerade nicht: „Alles hängt am Kopf“, sondern:

  • Der Kopf liefert nur einen Teil der Struktur.
  • Geräte‑Faktoren und ggf. organisatorische Komponenten ergänzen diese Struktur.
  • Es werden bewusst Redundanzen und Recovery‑Wege eingeplant, damit ein einzelner Fehler (Vergessen, Unfall, Gerät weg) nicht alles zerstört – aber eben auch nicht jede einzelne Komponente allein genügt, um alles zu übernehmen.

Ob dieses Zusammenspiel am Ende wirklich gut modelliert ist, müssen Leute mit mehr Fachwissen als ich beurteilen – deswegen stelle ich das Ganze hier so offen zur Diskussion. Ich sehe mich eher als jemand, der aus der Praxis heraus einen massiven Handlungsbedarf gespürt hat und mithilfe von KI einen Architekturvorschlag gebaut hat, der jetzt von der Community zerpflückt, verbessert oder verworfen werden darf.

Wenn du Lust hast, tiefer einzusteigen: Ich würde mich sehr freuen, wenn du aus deiner Perspektive weiter auf Schwachstellen, Denkfehler oder unbeantwortete Fragen hinweist. Genau das bringt das Projekt voran.

10

Hi Bitcoin Maximalist, “klar definiert“ klingt erstmal nach Buzzword, wenn man es nicht konkret macht.

Mit „kleine, klar definierte mentale Struktur“ meine ich nicht irgendetwas Esoterisches, sondern etwas sehr Bodenständiges:

  • eine begrenzte Anzahl von Elementen (z.B. 2–3 kurze Bausteine),
  • deren Reihenfolge, Typ und Rolle einmalig festgelegt werden,
  • und die sich nicht ständig ändern, sondern über Jahre stabil bleiben.

Ein klassisches Beispiel vom Prinzip her (nicht 1:1 mein Setup) wären z.B.:
„ein Master‑Satz + ein persönliches Muster + ein fester Bezug auf eine Kategorie“.
Die App kennt die Struktur und weiß, wie sie daraus für verschiedene Slots unterschiedliche Ergebnisse ableitet; der Nutzer muss sich nur seine Bausteine merken, nicht 30 verschiedene Passwörter.

Die genaue Ausgestaltung (also wie viele Teile, welche Längen, welche Mathe dahinter usw.) möchte ich hier bewusst nicht im Detail veröffentlichen, weil genau das der Kern des Systems ist. Wichtig ist mir, dass:

  • der mentale Teil bewusst klein und stabil gehalten wird,
  • die Komplexität eher in der Architektur und im Ableitungsmechanismus liegt,
  • und dass niemand im Alltag irgendwelche Formel‑Gymnastik machen muss.

Wenn das Projekt weiter reift und externe Reviews dazu kommen, wird es natürlich eine offen dokumentierte Spezifikation geben – aber für ein öffentliches Forum versuche ich, erstmal auf der Konzept‑Ebene zu bleiben.

11

Genau so mache ich das seit fast 30 Jahren
:slight_smile:

12

Erzähle bitte mehr darüber :smiley:

13

Der OP hat es quasi erschöpfend ausgebreitet. Mir ist in Fleisch und Blut übergegangen all meine Zugriffe nach bestimmten Regeln aufzubauen.
Das fängt bei Passworten an, und geht bei wichtigen Dingen wie Seeds mit zusätzlichen organisatorischen Maßnahmen einher.

Jeder, der beruflich mit sehr wichtigen Accounts / Zugriffsarten zu tun hat, macht sich wohl Gedanken, wie das ausfallsicher & sicher zu organisieren ist.

14

Genau hier ist doch der Widerspruch in der Architektur. Wenn der „mentale Anker“ nicht kritisch ist, dann ist er überflüssig. Und wäre er für das System kritisch, wäre es nicht fehlertolerant und nicht deterministisch.

Du sagst selbst, dass der Mensch der größte Unsicherheitsfaktor ist. Dann musst du dir die Frage stellen: Warum den Menschen überhaupt als Schlüsselrolle in dieses System modellieren? Mehr Schichten bringen dir ja nicht wirklich etwas, wenn eine dieser Schichten eine massive Fehleranfälligkeit aufweist.

Was für Redundanzen stellst du dir konkret vor? Welche Art von Komponente ist das? Ein weiterer Mensch kann es nicht sein. Also muss es etwas anderes sein. Was bedeutet, auf den Menschen kann eigentlich erneut verzichtet werden, wenn im Fehlerfall mittels „nicht-menschlicher Redundanz“ der Fehlerfall behoben werden muss.
Inwiefern ist der Mensch dann ein sicherheitsrelevanter Bestandteil und erhöht nicht nur unnötig die Komplexität des Systems?

15

Wenn du das seit 30 Jahren so machst, ziehe ich den Hut – die meisten Menschen (mich eingeschlossen) schaffen dieses Niveau an Disziplin und Belastbarkeit nicht. Genau das ist aber der Kernpunkt meines Projekts:Ich versuche kein System für die wenigen Prozent zu bauen, die sich mit einem kurzen Anker im Kopf hunderte Zugänge zuverlässig merken können, sondern für die breite Masse, die genau daran scheitert – erst recht über Jahrzehnte, unter Stress, Krankheit, Alter, Umzug, Familien‑ und Firmenkonstellationen usw.

Mein Ansatz sagt nicht: „Alle sollen es so machen wie du“.
Er sagt: **Wir brauchen eine Architektur, die so tut, als wären alle Menschen so diszipliniert wie du – aber intern mit Redundanzen, Fehlertoleranz und klaren Prozessen nachhilft.**Wenn du Lust hast, würde mich trotzdem sehr interessieren, wie du dein System gedanklich strukturiert hast (ohne Details): eher ein Schema pro Dienst, ein universelles Muster, zusätzliche schriftliche Backups? Solche Erfahrungswerte helfen mir, das mentale Modell für „normale“ Nutzer besser zu gestalten.

16

Danke dir für die sehr klare Kritik, das hilft mir, meine eigenen Annahmen zu schärfen bzw. zu überprüfen.

Du sprichst zwei Punkte an:

  1. „Wenn der mentale Anker nicht kritisch ist, ist er überflüssig – ist er kritisch, fehlt Fehlertoleranz.“
  2. „Redundanz muss nicht‑menschlich sein, sonst bleibt der Mensch der Schwachpunkt.“

Vielleicht habe ich das bisher unglücklich formuliert. Ich versuche es anders:

1. Rolle des mentalen Ankers

Für mich ist der mentale Anker weder „alles oder nichts“, noch ein Deko‑Element.
Ich sehe ihn eher als eine von mehreren Zutaten in einem Rezept:

  • Ohne ihn bekommt man bestimmte Sicherheits‑/Recovery‑Eigenschaften nicht hin (z.B. kein klassischer Seed‑Zettel, kein zentrales Tresor‑File).
  • Aber er ist bewusst so eingebettet, dass sein Ausfall nicht automatisch Totalverlust bedeutet, sondern in definierten Szenarien durch andere Schichten abgefangen werden kann (z.B. spezielle Notfall‑Slots, Nachlass‑Prozesse, Multi‑Party‑Komponenten).

Deterministisch ist das System deshalb, weil aus einer Kombination von Faktoren ein eindeutiges Ergebnis entsteht – nicht, weil ein einzelner Faktor allein genügt.

Ob es sinnvoll ist, den Menschen überhaupt als eine dieser Zutaten zu verwenden, ist genau die Art Frage, die ich hier diskutieren will. Meine Intuition:
Ganz ohne menschliche Komponente landet man wieder bei rein technischen Single Points of Failure (Gerät, Tresor, Seed).
Nur mit menschlicher Komponente ist es natürlich hochfragil.
Ich versuche, einen Mittelweg zu modellieren – ob der tragfähig ist, muss sich zeigen.

2. Redundanzen – was meine ich damit konkret?

Mit „Redundanz“ meine ich z.B.:

  • dass es verschiedene Wege gibt, einen Hochsicherheits‑Slot wieder nutzbar zu machen (z.B. definierte Notfall‑Pfad‑Konfiguration, die andere Faktoren stärker gewichtet, dafür nur unter strengeren Bedingungen greift),
  • dass nicht alle kritischen Zugänge an denselben Typ Faktor gekoppelt sind (z.B. nicht überall dieselbe Nummer, dasselbe Gerät, dieselbe mentale Komponente),
  • dass bestimmte Rollen/Nutzungsszenarien (Privat, Business, Nachlass) unterschiedliche Kombinationen aus Mensch/Gerät/Organisations‑Layern verwenden.

Die Idee ist also nicht, den Menschen durch einen zweiten Menschen zu „redundantieren“, sondern:
Fehler des Menschen sollen idealerweise durch andere Eigenschaften des Systems gepuffert werden (z.B. klare Slot‑Trennung, bewusste Limits, definierte Notfallpfade) – ohne gleichzeitig alles so weich zu machen, dass jeder Leak sofort zum Generalschlüssel wird.

Ich gebe dir völlig recht: Das erhöht die Komplexität.
Die offene Frage ist für mich: Ist diese zusätzliche Komplexität gerechtfertigt, um bestimmte Risiken besser in den Griff zu bekommen, als es klassische Seed‑/Tresor‑Modelle tun?

Genau das versuche ich gerade mit euch herauszufinden. Wenn du magst, würde mich sehr interessieren, wie du eine ideale Architektur für „kein Seed‑Zettel, kein zentraler Tresor, trotzdem human‑tolerant“ skizzieren würdest – vielleicht liegt die Wahrheit eher in einer Kombination aus unseren Ansätzen.

17

Ja, das habe ich verstanden. Ich finde es toll was Du machst. Ich habe mich immer gefragt, warum so wenig Leute sich genau um diese Dinge ausreichend Gedanken machen::heart_exclamation:

Ich habe mich vor rund 30 Jahren (ich glaube es war irgendwann zwischen 1996 und 1998) hingesetzt, und mehrere Tag nur über meine Password-Policies nachgedacht. Zu diesem Zeitpunkt war mir bewusst, dass ich eine unüberschaubare Anzahl von Zugriffsdaten würde handhaben müssen, die unterschiedlichsten Sicherheitsanforderungen genügen mussten.
Und obwohl es seinerzeit noch vergleichsweise wenig gab, war schon absehbar, dass unangenehme Sicherheitlücken oft vom Anbieter ausgehen - nicht unbedingt von mir. Sicher gibt es auch Leute die „Passwort123“ für eine gute Idee hielten, in den 90ern noch viel mehr… aber dass ein Anbieter Passworte KLARTEXT speichert, oder eine Passwort-Länge von maximal 8 Zeichen vorsieht ist kein Unfall sondern blanker Wahnsinn. Aber das begegnet Dir!
Auch dass die lächerlichsten Zeichen evtl. nicht zugelassen werden, kommt leider immer wieder vor.
Meine Methodik hat sich also von den Anfängen mehrfach weiter entwickeln müssen, um der Realität zu genügen.

Ich werde hier gerne mein Erfahrungen einbringen, auch wenn ich aufgrund eigener Opsec keine technischen Details preisgeben kann.

Zunächst einmal: Ich erachte eine Anzahl von Passwort-Gerüsten von derzeit mindestens 20 Zeichen Länge für unerlässlich. Je nach persönlicher Lage benötigt man davon mindestens 4-6 Stück. Das ist für viele unangenehm, ich weiß, aber mMn unumgänglich. Nur so kann niemand Fingerabdruck oder andere Biometrie ohne Dein aktives Zutun missbrauchen, Keys stehlen o.ä.

Es mag einfache Fälle geben, wo man mit einem Passwort-Manager agieren kann, aber da ich KEINER Software traue, die ich nicht reviewed habe, scheidet das für mich aus.

Für die Passwort-Gerüste überlegt man sich nun Regeln, wie man für div. Services ein konkretes Passwort erzeugt. Das stellt sicher, dass Passworte nicht mehrfach verwendet werden. Div. Herausforderungen wie:

  • Passworte müssen alle 4 Wochen geändert werden
  • dürfen bestimmte Zeichen NICHT enthalten
  • sind von der Länge vorgegeben
    Sind dabei nur einige Punkte, die einen ärgern können.

Wenn man einen Zugang täglich benötigt mag man sich das schnell merken… aber was ist mit dem Account, den man einmal im Jahr zugreifen muss? Und der dann 18 Zeichen haben muss, und „?“ nicht als Zeichen erlaubt?

So, nun ist aber die Passwort-Sache, bzw. deren Erzeugung im Kopf für div. Services auch nur ein Teil der Geschichte. Was ist mit Seeds von Wallets? Von den Pins der 18 Plastikkarten? Was von den Schließfächern? Auch von den Services, auf die man nur alle 5 Jahre mal zugreifen mag?

:slight_smile:
Dazu werde ich mich im weiteren Thread äußern.

Ein Backup ist auch wichtig, gerade für Dinge, die man selten oder sehr selten zuzugreifen hat. Daher sollte man EIN Passwort haben, dass z.B. ein verschlüsseltes Offline-Backup öffnen kann, und dass niemals auf Geräten die online gehen eingegeben wird (ähnlich wie ein Seed niemals online eingegeben wird).

Nun aber genug für jetzt
:slight_smile:

18

Wow, erst mal großen Respekt dafür, wie tief du dir schon in den 90ern Gedanken über Passwort‑Policies gemacht hast, genau diese Art von langfristigem Denken fehlt den meisten komplett. :folded_hands:

Beim Lesen deiner Beschreibung ist mir aber ein Punkt sofort aufgefallen, den du ja selbst schon andeutest: Am Ende läuft bei deiner Methode sehr viel auf dich als einzelne Person und ein einziges, extrem wichtiges Master‑Geheimnis hinaus z.B. das eine Passwort, das dein verschlüsseltes Offline‑Backup öffnet. Sobald dieses eine Element fällt (Waffe auf der Brust, Erpressung, Unfall, Demenz, Schlaganfall, Koma, gezielter Angriff auf dein Gedächtnis etc.), ist entweder alles weg oder alles kompromittiert.

Genau hier setze ich mit meinem Projekt an:
Ich versuche, diese klassische „Master‑Passwort / MasterKopf“-Abhängigkeit zu durchbrechen und ein Modell aufzubauen, das

  • im Alltag komplett ohne Passwort‑Manager‑Datenbank auskommt,
  • auf einer mentalen Struktur und deterministischen Regeln basiert,
  • aber bei Extremfällen über zusätzliche, verteilte Recovery‑Mechanismen (mehrere unabhängige Personen/Komponenten, Zeitverzögerungen, Vetos etc.) verfügt, die den Single Point of Failure entschärfen.

Dein Ansatz ist aus meiner Sicht ein super starkes Fundament, weil du bereits:

  • mehrere Passwort‑Gerüste nutzt,
  • explizit über selten genutzte Zugänge, Seeds, Karten‑PINs, Schließfächer etc. nachdenkst,
  • und Opsec ernst nimmst, statt „noch ein Tool zu installieren und zu hoffen“.

Genau so jemanden wie dich könnte ich mir übrigens in einem Team sehr gut vorstellen nicht, um dein System einfach zu „übernehmen“, sondern um gemeinsam zu schauen, wie man deine jahrzehntelange Praxis mit einem recovery ähigen, aber trotzdem nicht zentralisiertem Modell kombinieren kann, das eben auch physische und kognitive Ausfall‑Szenarien berücksichtigt.

Wenn du magst, kann ich gern etwas mehr zu meinem Ansatz schreiben (ohne irgendwelche sensiblen Details von dir zu verlangen) – mich würde vor allem interessieren, wie du heute konkret mit den von dir selbst erwähnten Worst‑Case‑Szenarien (Unfall, Demenz, erzwungene Preisgabe) umgehst.

19

Dem ist nicht so, aber ich kann hier nicht viel genauer werden. Dinge die ich nach einem Schlaganfall nicht mehr brauchen würde, würden fallen, andere nicht.
Pistole-auf-der-Brust würde nichts nutzen, da ein extremer Aufwand notwendig wäre um an eines der Backups zu gelangen.

Ich schaue gerne weiter mit. Das Thema interessiert mich :slight_smile:

Erzwungene Preisabe, der klassische $5 Wrench ist kein Thema, wenn Du sehr aufwendige Prozesse benötigst um am Ende an Dein Backup zu gelangen. Vor allem, wenn Du Orte in aller Öffentlichkeit persönlich aufsuchen musst etc.
Bei Demenz beginnen Probleme schleichend. Entweder man sieht ein, dass man als Zentraler Akteur zurück treten muss, oder Dinge gehen verloren. Bei mir gingen durch Demenz nur Dinge unrettbar verloren, die ich danach nicht mehr benötige.
Unfall ist schon schwieriger, da man evtl zeitweise eine Vertretung benötigt. In Firmen kann man das z.B. mit Prokuristen lösen, die per Offline-Totmannschalter-Safe Zugriffe erhalten.

20

Aber ein Hinweis: Ich hoffe Du benutzt als AI eine lokale Installation auf einem Offline Rechner. Sonst würde ich schon Deine Diskussion mit der AI als Problem ansehen.