Martins key.matiq-Blog
>> Zurück zum Artikelverzeichnis >>
Geheimnisse im Team:
Übertragung oder gemeinsamer Tresor?
Geschrieben: 18.12.2025
Stichwörter: Grundsätze, Sicherheit, Sicherheit mit Bedienbarkeit
Fast alle Online-Passwortmanager bieten "gemeinsame Tresore" für die Geheimnisverwaltung von Teams an. Nur key.matiq macht es anders. Warum?
Sicherheit und Funktion müssen Hand in Hand gehen
Jede*r weiß, dass digitale Geheimnisse in Unternehmen (aber auch in Vereinen und anderen Organisationen) gut vor Cyberangriffen geschützt werden müssen. Im Schadensfall steht sonst der Betrieb schnell still.
Das Root-Passwort an der Tafel im Büro gehört daher (hoffentlich) ziemlich überall der Vergangenheit an.1 Das Teilen von Passwörtern kann mittels teamfähiger Passwortmanager erfolgen. Auch die Übertragung von digitalen Geheimnissen durch Dienste wie z. B. onetimesecret.com2 kann eine saubere Möglichkeit sein.
Doch es geht darum, den Umgang mit Geheimnissen im Team sowohl sicher als auch alltagstauglich zu gestalten. Geht etwas nicht effizient genug, wächst die Versuchung, Sicherheitsaspekte3 nachrangig zu beachten.
Problempunkte
- Ein zu teilendes Geheimnis sollte nur so viele Mitwisser*innen haben, wie tatsächlich erforderlich ist. Die Devise sollte lauten: So viele wie nötig, so wenig wie möglich!
-
Wenn eine Mitwisser*in eines Geheimnisses aus dem Team ausscheidet, sollten
alle Geheimnisse, auf die sie Zugriffsmöglichkeiten hatte, geändert werden.
Genauer: Es geht um Geheimnisse, von denen nicht ausgeschlossen werden kann, dass das ausscheidene Mitglied sie sehen konnte. Diese sind sicherheitshalber mit dem Ausscheiden als "kompromittiert" zu betrachten.4 -
Wenn eine Administrator*in aus dem Team ausscheidet, die in der Lage war,
sich selbst Berechtigungen zum Einsehen von Geheimnissen zu erteilen,
sollten alle diese Geheimnisse mindestens dann als "kompromittiert"
betrachtet werden, wenn ihr im Nachhinein genügend kriminelle Energie
zugetraut wird, diese Möglichkeit auch auszunutzen. Die erforderliche
kriminelle Energie dürfte geringer anzusetzen sein, wenn solche Tätigkeiten
möglich sind, ohne auffällige Spuren zu hinterlassen.
Es spricht aber auch nichts dagegen, wenn die Nachfolger*in einer Administrator*in grundsätzlich, um auf der sicheren Seite zu sein, (unabhängig von dem, was sie der Vorgänger*in zutraut, oder auch nicht) alle Geheimnisse austauscht, auf die die Vorgänger*in potentiell zugreifen konnte. - Wenn ein Geheimnis nicht einmalig geteilt wird, sondern auch Veränderungen geteilt werden sollen, sollte hierfür eine automatisierte Lösung gewählt werden, die sicherstellt, dass diese Updates auch tatsächlich ankommen.
Zusammengefasst: Das Teilen sollte sehr zielgenau sein. Sowohl in Bezug auf den Kreis der Geheimnisträger*innen als auch auf die zeitnahe Aktualisierung.
Die einfache Lösung: Der gemeinsame Tresor
Es ist die übliche Lösung der teamtauglichen Online-Passwortmanager. Jedes Teammitglied hat einen eigenen Passwortcontainer (oft "Tresor" oder "Vault" genannt), aber es lassen sich auch ein oder mehrere zusätzliche Tresore einrichten, die jeweils von mehreren Teammitgliedern gemeinsam genutzt werden.
Es muss dann natürlich eine Administrator*in für das Gesamtpaket geben, die die gemeinsamen Tresore einrichtet und auch Berechtigungen für den Zugriff darauf einrichtet (und auch ggf. wieder entzieht).
Wenn alle Mitglieder des Teams alle gemeinsamen Geheimnisse ohnehin teilen müssen, wäre ein solcher gemeinsamer Tresor doch eine einfache und gute Lösung, oder?
Aufpassen: Kann man sicher sein, dass solch eine Voraussetzung auch in Zukunft gelten wird? Wenn nicht, dann könnte es sein, das man in eine Situation schliddert, in der doch einige Teammitglieder auf mehr Geheimnisse potenziellen Zugriff haben, als sie haben müssten. Hat man dann die Kapazitäten, eine bessere Lösung zu finden, oder wird dann (z. B. aufgrund von Zeitdruck) der Grundsatz "so wenig wie möglich" bei den Geheimnisträger*innen schleichend immer mehr verletzt?
Auch bei der Administrator*in ist Vorsicht angesagt. Handelt es sich hier um die Firmenchef*in, dann dürfte es wohl vorerst in Ordnung gehen. Aber wächst die Firma, werden typischerweise solche Aufgaben delegiert. Dass könnte dann zum Problem werden. (Dieses Problem entfällt nur, wenn die Administrator*in ohnehin alle geteilten Geheimnisse kennen müsste. Und dann auch nur, solange diese Bedingung tatsächlich gilt.)
Schließlich gibt es noch ein Problem mit dem Aufwand: Wenn einige Mitglieder des Teams einige Geheimnisse teilen müssen, andere Mitglieder aber andere Geheimnisse, sollten schon mehrere gemeinsame Tresore eingerichtet werden. Möglicherweise werden das dann mit der Zeit immer mehr geteilte Tresore, was den Verwaltungsaufwand in die Höhe treibt. Oder aber es wird geschludert, was dann das Risiko erhöht.
Übertragung
Eine handgestrickte Übertragung im Einzelfall auf sichere Weise durchzuführen, ist nicht ganz ohne Aufwand.5. (Jedenfalls deutlich mehr als z. B. der Aufwand für das Sperren eines gemeinsamen Tresors für ein ausgeschiedenes Teammitglied betragen würde.6)
Wenn die Übertragung nicht nur einmalig erfolgt, sondern auch für den Fall der Veränderung des Geheimnisses wiederholt werden sollte, macht es also schon Sinn, die Übertragung durch einen teamfähigen Passwortmanager machen zu lassen, der ggf. auch die Aktualisierung bei den Mitwisser*innen besorgt. Schauen wir uns also key.matiq diesbezüglich an. Denn key.matiq kann genau das.
Bei key.matiq ist es möglich, auf Geheimnis-Ebene einen Verteiler einzurichten, so dass andere Boxen immer nur die für ihre Eigentümer*innen wirklich nötigen Passwörter, Schlüssel und andere digitalen Geheimnisse erhalten.
Die Verteiler können für jedes Geheimnis einzeln erstellt werden, aber es ist auch möglich, Verteiler-Objekte zu erstellen und zu nutzen. Diese können auch in einem Gruppen-Container gelagert werden und so für alle Teammitglieder zugänglich sein. Auch hier gibt es eine Administrator*in (oder mehrere davon), doch diese hat keinen direkten Zugriff auf die Geheimnisse.
Für diese geheimnisspezifische Verteilung ist vonseiten der Nutzer*in nicht viel Aufwand erforderlich. Denn die Teammitglieder können sich über einen gemeinsamen Gruppen-Container miteinander verbinden, der (im Gegensatz zu einem gemeinsamen Tresor) keine Geheimnisse7, aber Mitgliedsobjekte enthält, die dann in Verteilern für Geheimnisse gezielt ausgewählt werden können.
Es gibt zwar auch hier prinzipiell Manipulationsmöglichkeiten. Aber deren Inanspruchnahme würde für die Administrator*in das starke Risiko in sich tragen aufzufliegen, weil die Übertragungs-Logs protokollieren, an welche Boxen das jeweilige Geheimnis tatsächlich gegangen ist. (Diese Logs sind außerhalb der Reichweite der Administrator*in und können daher nicht von ihr verfälscht werden.)8
Handhabung der Problempunkte durch key.matiq
Ausscheiden eines Teammitglieds
Das ist bei der Übertragung nicht ganz so trivial wie bei gemeinsamen Tresoren. Aber die Arbeit, festzustellen, welche Geheimnisse nun geändert werden müssen, übernimmt key.matiq und markiert beim Ausscheiden eines Teammitglieds aus einem Verteiler alle Geheimnisse, die davon betroffen sind.
Es ist egal, wie das Teammitglied die Verbindung zu dem geteilten Geheimnis verloren hat, ob es die Mitgliedschaft in der Gruppe verlustig wurde oder sonstwie nicht mehr dem effektiven Verteiler eines geteilten Geheimnisses angehört. Die Autor*in wird von key.matiq benachrichtigt, dass für das Geheimnis nun ein Risiko besteht und es daher abzuändern ist.
Ausscheiden der Administrator*in
Die Administrator*in eines Gruppen-Containers hat höchstens auf den von der Autor*in eines Geheimnisses genutzten Verteiler Zugriff. Aber in den Übertragungsprotokollen steht, welche Boxen letztlich das Geheimnis erhalten haben. Die Backups des Gruppen-Containers könnten auf ungerechtfertigte Manipulationen durch die Administrator*in hin untersucht werden.
Da die Möglichkeiten einer Gruppenadministrator*in zur Manipulation weitaus geringer (und die Risiken der Entdeckung von Manipulationen weitaus höher) sind, als es bei Administrator*innen von gemeinsamen Tresoren der Fall ist, kann im Normalfall davon ausgegangen werden, dass die über die Gruppe verteilten Geheimnisse durch das Ausscheiden allein noch nicht kompromittiert worden sind.
Ausnahmen:
- Geheimnisse, die direkt auch an die Gruppenadministrator*in gesandt wurden, sind wie bei anderen ausgeschiedenen Teammitgliedern als "kompromittiert" zu bewerten.
- Gibt es Anlass, bei der ehemaligen Gruppenadministrator*in kriminelle Energie zu vermuten, sollten Backups des Gruppen-Containers auf mögliche Manipulationen hin untersucht werden und im Zweifel weitere Maßnahmen erwogen werden.9
Automatisierte Aktualisierung
key.matiq lässt zu, dass bei einer Veränderung eines geteilten Geheimnisses automatisch eine Übertragung angestoßen wird. Derzeit10 beschränkt sich dieser Anstoß allerdings in einigen Fällen (aus technischen Gründen, die hoffentlich bald abgestellt werden können) noch auf die Führung der Nutzer*in, die Übertragung zu starten. Aber bei der inhaltlichen Änderung eines Geheimnisses wird bereits die Übertragung automatisch gestartet.
Zielgenauigkeit
key.matiq fördert also die Zielgenauigkeit sowohl in Hinblick auf den Kreis der Geheimnisträger*innen als auch auf die zeitnahe Aktualisierung.
Nachgefragt: Wie steht es um KISS11?
"Die Einfachheit ist die Freundin der Sicherheit" heißt es nicht umsonst. Denn wird etwas kompliziert, so wird es leicht schwierig, noch zu durchschauen, ob es auch sicher ist. Und komplizierte Software ist auch eher fehleranfällig als einfach gestrickte.
Aber manchmal ist es so, dass was zu einfach gehalten ist, nicht mehr sicher genug ist (wenn z. B. alle Geheimnisse eines Teams in nur einem gemeinsamen Tresor gehalten werden). Oder es wird für die Anwender*innen schwierig, eine sichere Lösung zu handhaben (wenn viele gemeinsame Tresore mit unterschiedlichen Kreisen von Zugriffsberechtigten gemanaged werden müssen).
Wenn aber Einfachheit mit Sicherheit kollidiert und Einfachheit für die Nutzer*innen sich mit der Einfachheit für die Entwickler*innen (KISS) beißt, dann muss man Prioritäten setzen. Wir haben diese wie folgt gesetzt:
- Sicherheit,
- einfache Handhabung für die Anwender*innen,
- einfache Implementation (KISS).
Die Sicherheit verlangt, dass es für die Nutzer*innen die einfacher sein muss, eine sichere Konfiguration zu wählen, als eine unsichere Konfiguration.
Die einfache Handhabung für die Anwender*innen verlangte Maßnahmen, die durchaus viel Aufwand für die Entwicklung von key.matiq bedeuteten. Aber dieser Aufwand (und auch die höhere Fehlerrisiken in der Einführungsphase wegen der deshalb komplizierteren Implementation) sind aufgrund der oben genannten Prioritäten zu akzeptieren.12
Weitere Vorteile des Übertragungskonzepts gegenüber gemeinsamen Tresoren
Versiegelte Geheimnisse
Neben den Sicherheitsfragen, bietet key.matiq mit dem Konzept der Übertragung von Geheimnissen auch noch einen wichtigen funktionellen Vorteil gegenüber gemeinsamen Tresoren:
Es ist möglich, damit Notfallkoffer zu erstellen, in denen versiegelte Kerngeheimnisse enthalten sind. Z. B. das eigene Hauptkennwort, oder ein Teil davon. Wird es geändert, wird die Aktualisierungsübertragung automatisch angestoßen.
Verstirbt die Sender*in oder fällt sie ins Koma, kann dann die Empfänger*in den Siegelbruch beantragen und kann nach einer (zuvor von der Sender*in eingestellten) Karenzeit das Geheimnis im Klartext sehen. Zur Missbrauchsabwehr wird die Sender*in informiert und kann, wenn sie gar nicht tot oder bewusstlos ist, während der Karenzzeit den Siegelbruch noch stoppen.
Über einen gemeinsamen Tresor kann das so nicht funktionieren.13
Teilgeheimnisse
Komplemente und Komponenten werden von key.matiq bei der Übertragung von Geheimnisse ebenfalls berücksichtigt:
- Zunächst werden für die Komponenten die vorgesehenen Operationen ausgeführt (d. h. im einfachsten Fall: Einfügung der Komponentenwerte).
- Für die Komplemente werden die Hinweise auf den Wert mit übertragen und der Name der sendenden Box jeweils dem Komplementnamen vorangestellt. Bei der Ansicht des empfangenen Geheimnisses wird dann das Komplement nicht nur mit dem Hinweis auf den Wert, sondern auch mit Bezug auf die Quelle (sendende Box, bzw. deren Besitzer*in) abgefragt. D. h. die Komplemente (deren Werte ja grundsätzlich nicht von key.matiq, sondern anderswo zu speichern sind) werden über einen (von Sender*in und Empfänger*in zu besprechenden) alternativen Weg übergeben.
Bei einem gemeinsamen Tresor müsste entweder auf Teilgeheimnisse (Komponenten und Komplemente) verzichtet werden, oder es müssten auch Komponenten und Komplemente geteilt werden.14
Nachteile des Übertragungskonzepts gegenüber gemeinsamen Tresoren
- Während bei gemeinsamen Tresoren neu erstellte Geheimnisse oder deren Änderungen im gemeinsamen Tresor sofort verfügbar sind, ist dies bei der Übertragung nicht der Fall. (Allerdings dürfte der Nachteil dieses Zeitverlustes durch den zuvor beschriebenen vorteilhaften Sicherheitsvergleich noch mehr als kompensiert werden.)
-
Wichtiger ist wohl folgender Fall: Wenn eine Geheimnis-Autor*in (also
z. B. die Administrator*in eines Computers, die typischerweise das
Admin-Passwort des Computers festlegt und bei Bedarf ändert) im Urlaub
ist, wird sie für ihre Aufgabe eine Stellvertreter*in benennen.
In diesem Fall kann die Stellvertrer*in im Fall der notwendigen Änderung des Admin-Passworts das Kennwort in einem gemeinsamen Tresor problemlos ändern. Im Übertragungsfall müsste sie das neue Kennwort der ursprünglichen Geheimnis-Autor*in (und allen Mitwisser*innen des bisherigen Kennworts) mitteilen und nach dem Urlaub müsste die ursprüngliche Autor*in dann wieder übernehmen (und ggf. Teilgeheimnisse abändern oder wieder einfügen).
Dieser Fall ist zwar selten, wird aber bei der Übertragung noch recht unbefriedigend gelöst. Auf Dauer sollte dieses Problem behoben werden.
Zwischenergebnis
Beim Vergleich des Konzepts gemeinsamer Tresore mit dem der Übertragung zeigt sich ein deutlicher Sicherheitsvorteil für die Übertragung von Geheimnissen gegenüber gemeinsamen Tresoren. Die derzeitigen funktionellen Vorteile von key.matiq würden bezüglich der Teilgeheimnissen wohl auch mittels gemeinsamer Tresoren ganz gut implementieren lassen, bei der Versiegelung wäre es jedoch deutlich einfacher, es bei der Übertragung zu belassen.
Der Fall der Urlaubsvertretung zeigt aber, dass noch Nachbesserungsbdarf besteht.
Vielleicht Kombi von Übertragung und gemeinsamen Geheimnissen?
Es ist denkbar, ein duales Konzept zu entwickeln: Übertragung von Geheimnissen (was sicherlich besser für versiegelte Geheimnisse passt), aber auch gemeinsame Geheimnisse (vielleicht auch gemeinsame Teilgeheimnisse, vielleicht sogar gemeinsame Ordner und gemeinsame Notizen).
Da treten natürlich eine Reihe von Implementationsproblemen auf, die aber im Prinzip alle lösbar sein sollten.
Die entscheidende Frage ist jedoch, ob solch ein duales Konzept wirklich hilfreich wäre: Wegen des einen Problems (bei der Urlaubsvertretung) gleich einen komplett zweiten Strang der Geheimnisteilung hochzuziehen, bedeutet ja schließlich auch, dass man damit die Benutzer*innen belastet: Diesen sollte immerhin die komplette Funktionalität des Passwortmanagers dargelegt werden. Und sie müssen davor gewarnt werden, gemeinsame Geheimnisse falsch (im Sinne der o. g. Sicherheitsbedenken15) zu benutzen.
Daher sollten wir zunächst schauen, ob wir das "Urlaubsvertretungs"-Problem nicht mit einfacheren Mitteln lösen können (z. B. dass man für zu übertragende Geheimnisse auch einen "Autor*innen-Kreis" festlegen kann). Da gibt es auch einige Probleme, aber vielleicht sind diese leichter lösbar.16
Nur wenn sich so keine befriedigende Lösung finden lässt, sollte der "Hammer" mit dem dualen Konzept herausgeholt werden, dann aber auch mit allen Konsequenzen17 implementiert werden.
Fazit
Im Zwischenergebnis stellte sich bereits heraus, dass key.matiq mit seinem Übertragungskonzept derzeit einen deutlichen Sicherheitsvorsprung vor Passwortmanagern hat, die auf gemeinsame Tresore setzen. Allerdings gibt es noch ein Problem (Urlaubsvertretung von Geheimnisautor*innen), das noch nicht sauber gelöst, aber eine Zeitlang durchaus hinnehmbar ist.
Langfristig sollte jedoch auch dieses Problem gelöst werden. Es gibt dafür derzeit zwei Möglichkeiten. Bevorzugt wird die Lösung mit dem "Autor*innenkreis", aber nur, wenn diese letztlich die erhoffte Qualität hat.
1) Das gab es tatsächlich. In einem Münchner Rüstungsbetrieb habe ich es in den 1980er Jahren mit eigenen Augen gesehen: An der Pforte scharfe Sicherheitskontrollen, aber in den Büros purer Leichtsinn.
2) Siehe https://onetimesecret.com. Mit diesem Dienst kann man z. B. ein zufällig erzeugtes18 sicheres Passwort an eine Kolleg*in verschicken. Sobald dieses dort angekommen ist, weiß man, dass es zumindest niemand anders abgerufen hat (da es nur einmal abrufbar ist).
Wenn man auf diese Weise mit der Kolleg*in nun dieses gemeinsame Passwort teilt, können damit die eigentlichen zu teilenden Geheimnisse verschlüsselt werden (z. B. in einer verschlüsselten ZIP-Datei) und der Kolleg*in zugesandt werden.
3) Die wichtigsten Aspekte habe ich im Blog-Artikel: "Passwortsicherheit ohne Lücken" dargestellt.
4)
Wenn jemand eine Firma verlässt, gilt die Regel, dass er*sie den
(physikalischen) Schlüssel abgeben muss. Übersetzt auf digitale Schlüssel
heißt das, dass diese durch neue ersetzt werden müssen. Denn Vergessen kann
man nicht erzwingen und es besteht keine Kontrolle mehr darüber, ob sich das
ehemalige Teammitglied nicht leichtsinnig oder
krankheitsbedingt19 verplappert oder gar
schmieren lässt. Oder auch nur eines der Kennwörter demnächst bei einem
unsicher speichernden Internetkonto verwendet, das dann gehackt wird. Solche
Dinge passieren leider. Nicht immer, aber manchmal und dann oft mit schlimmen
Folgen.
Ein digitaler Schlüsselwechsel entspricht eher dem Wechsel eines
physikalischen Schlosses als der Rückgabe der physikalischen Schlüssel. Das
ist auch nötig, weil digitale Geheimnisse viel leichter kopierbar sind, als
metallene Schlüssel. Das bedeutet aber auch, das ein digitaler
Schlüsselwechsel sicherer ist als die Rückgabe eines physikalischen
Schlüssels.
5) Man muss sich vergewissern, dass das Verfahren in jeder Hinsicht sicher ist (es also nicht z. B. Seitenkanalattacken zulässt). Man muss sich auf einen gemeinsamen Schlüssel einigen, man muss die zu übertragenden Daten verschlüsseln und auf der anderen Seite wieder entschlüsseln. Vielleicht sollte man sich eine Anleitung schreiben, damit man beim nächsten Mal nicht einen dummen Fehler macht.
6) Das Sperren des weiteren Zugriffs auf einen gemeinsamen Tresor, also auf die nun darin liegenden geänderten Geheimnisse ist problemlos möglich, indem das System für die verbleibenden zugreifenden Teammitglieder einen Schlüsselwechsel vornimmt und die Inhalte des Tresors auf diese neuen Tresorschlüssel umschlüsselt.
7) Siehe den Begriff "Geheimnis" im Glossar.
8)
Die Administrator*in könnte z. B. einen oder mehrere Mitgliedsnamen im
Gruppen-Container verändern, um die Sender*in eines Geheimnisses dazu zu
bringen, dieses an die falsche Box zu senden. Das fällt dann aber im
Transfer-Log auf, denn dort werden die Boxen genannt, an die gesendet wurde.
Sie könnte auch einen Verteiler in dem Gruppen-Container einrichten, und den
Teammitgliedern vorschlagen, diesen für den Geheimnisversand zu verwenden.
Wenn sie diesen Verteiler später verändert, könnte sie so selbst zur
Adressat*in werden. Aber auch das dürfte im Transfer-Log auffallen.
Derartige Manipulationen würden dann auch bei den täglichen Backups
des Gruppen-Containers gespeichert, so dass das Risiko für die
Administrator*in entstünde, dass diese Backups als Beweise für die
Manipulation dienen können. (Auf die Backups hat die Administrator*in nur
lesenden Zugriff. Die Löschung erfolgt nur durch key.matiq nach einem festen
Zeitplan.)
Die Geheimnis-Autor*innen können übrigens nicht gezwungen werden, Verteiler
aus dem Gruppen-Container20 zu
verwenden. Auch praktisch dürfte das nur selten der Fall sein, da bei meist
wenigen Boxen als Adressaten einfach diese Boxen in den Geheimnis-Verteiler
eingetragen werden.
9)
Je nach Risikoeinschätzung könnten einzelne bis hin zu sämtliche über die
Gruppe versandte Geheimnisse abgeändert werden. Letzteres entspricht dem
Auswechseln sämtlicher physikalischer Schlösser, für die ein ausgeschiedenes
Teammitglied Schlüssel besaß, aber abgegeben hatte.
Anhand dieser Parallele kann man in etwa auch die Risikoabwägung vornehmen:
Würde man analog sämtliche physikalische Schlösser austauschen wollen, wäre
entsprechend sicherlich auch die Abänderung bedrohter digitaler Geheimnisse
geboten.
10) Im Jahr 2025, bei der letzten Gesamtüberprüfung dieses Blog-Artikels
11) "Keep it simple, stupid", siehe Wikipedia "KISS-Prinzip".
12)
Die Implementation kann nicht einfacher sein, als es die Sicherheit und
genügend einfache Handhabung für die Nutzer*innen zulassen.
Fehler, die passieren können (aber auch durch das Entwicklungsteam nach
und nach immer unwahrscheinlicher gemacht weden können) sind schließlich eher
zu verkraften, als Sicherheitsrisiken, die durch Benutzungsfehler
entstehen bzw. nur durch aufwändige Handhabung zu vermeiden sind und im
Umkehrschluss durch diesen Aufwand geradezu wahrscheinlich gemacht
werden.
13) Passwortmanager, die mit persönlichen und gemeinsamen Tresoren für die Teamarbeit arbeiten, haben den Notfallkoffer auch nicht über versiegelte Geheimnisse realisiert, sondern lassen z. B. einen Code erstellen und ausdrucken, der einer Erb*in gegeben werden kann, die ihr damit im Notfall Zugriff auf die Daten erlauben.
14) Das könnte man wohl bei gemeinsamen Tresoren auch realisieren: Komponenten (d. h. deren Namen und Werte) und Komplemente (d. h. die Namen und Hinweise auf die Werte) könnten ebenfalls geteilt werden.
15) D. h. die Nutzer*innen müssen davor gewarnt werden, das jeweilige Geheimnis mehr als nötig mit anderen zu teilen, insbesondere sollten sie nicht einfach alle Geheimnisse mit dem ganzen Team teilen.
16)
Wie sollten z. B. Teilgeheimnisse behandelt werden? Möglicherweise werden
diese in Fällen, wo man einen Autor*innenkreis braucht, gar nicht so oft
benötigt.
Vielleicht muss man aber auch Komplemente und Komponenten innerhalb des
Autor*innenkreises verteilen und synchronisieren lassen. Und dann muss noch
das Problem gelöst werden, wie man die empfangsseitige
Komplettierung möglichst elegant (d. h. mit möglichst wenig menschlichen
Eingriffen und menschlicher Verwirrung) zum Funktionieren bringt.
Ich sehe durchaus Chancen, dass eine Lösung gelingt.
17)
In diesem Fall müsste es wohl auch gemeinsame Teilgeheimnisse (d. h.
gemeinsame Komplemente und gemeinsame Komponenten), vielleicht sogar
gemeinsame Ordner geben.
Diese müssen natürlich bei den Kosten berücksichtigt werden, d. h. sie müssten auch bei der Inanspruchnahme des Kontingents zählen, bzw. sie würden gesperrt,
wenn das Kontingent überschritten wird.
Da die Namen von Teilgeheimnissen innerhalb einer Box eindeutig sein müssen,
muss hier aufgepasst werden, dass es keine Namenskonflikte gibt. Das ist
am leichtesten mit einem gemeinsamen Prefix zu erreichen, auf den sich alle
Mitbesitzer*innen eines gemeinsamen Geheimnisses einigen. (Das ist nicht ganz
trivial, da ja kaum für alle Zukunft absehbar ist, wer sich mit wem bei einem
gemeinsamen Geheimnis trifft. Also dürfte es wohl auf ein generiertes Prefix
(was noch nicht benutzt wurde) hinauslaufen, das dann vermutlich recht
kryptisch ausschauen dürfte. Also auch noch keine Ideallösung.
Schließlich sollte key.matiq erkennen, ob Geheimnisse missbräuchlich unter zu
vielen Boxen geteilt werden: Z. B. könnte bei mehr als drei
Geheimnisträger*innen eine Warnung erfolgen. Auch könnte key.matiq eine
Statistik erstellen, die ermittelt, ob geteilte Geheimnisse wirklich von allen
Mitwisser*innen genutzt werden. Und wenn nicht, sollte key.matiq dies
monieren.
Ob diese Aufwände gerechtfertigt sind, sollte bei der Entscheidung über die
letztliche Lösung mit bedacht werden.
18) Praktisch jeder noch so einfache Passwortmanager (wie z. B. KeePass21, auch der eingebaute Passwortmanager vom Firefox)21 enthält auch einen Generator für sichere Passwörter.
19) Bei Demenz (gerade auch beginnender, noch nicht als diagnostizierter Demenz) kann es durchaus vorkommen, dass eine*m durch irgendeinen Anstoß ein Passwort einfällt und man davon plaudert, weil man im Moment völlig vergessen hat, dass man es für sich behalten sollte. Auch führt die Demenz oft zur Enthemmung, d. h. selbst, falls die Geheimhaltungspflicht dem Betroffenen noch bewusst sein sollte, kann deren Verletzung Folge der Krankheit sein.
20) Verteiler in Gruppen-Containern sind gewöhnlich nicht für Geheimnisse gedacht, sondern für Nachrichten.
21) Hinweise zu Marken Dritter:
"KeePass" scheint ein Warenzeichen von Dominik Reichl zu sein.
"Firefox" ist eine eingetragene Marke der Mozilla Foundation.