Martins key.matiq-Blog

>> Zurück zum Artikelverzeichnis >>


Die Balance wahren

Geschrieben: 09.02.2024
Letzte Überarbeitung: 20.02.2024
Stichwörter: Kennwörter, Sicherheit mit Bedienbarkeit

Meine Empfehlung für zu merkende Kennwörter ...

... ist, pseudozufällige Passwörter anhand von kreativ entwickelten Geschichten zu entwickeln und in der Regel1 auf eine Stärke von 128 Bit zu achten.2

Diese Empfehlung ist durchaus durchdacht. Mir ist schon klar, dass sie eine Zumutung darstellt. Aber mir erscheint dies, die beste Möglichkeit zu sein, im digitalen Bereich eine Sicherheit zu erreichen, die z. B. auch staatlichen Geheimdiensten Widerstand leistet.3

Es gibt immer Alternativen!

Im Gegensatz zu Politiker*innen, die häufig ihre Meinung als alternativlos hinstellen, oder die äußern, dass ihnen die Phantasie fehle, sich etwas anderes vorzustellen4, bin ich der Meinung, dass es durchaus andere begründete Meinungen als meine eigene gibt. Man braucht ja nur leicht andere Einschätzungen oder Ziele zugrunde legen.

Auch wenn die Sicherheit bei der Verwaltung von Geheimnissen im Vordergrund steht, so ist doch die Brauchbarkeit ein ebenbürtiger Aspekt. Ist das Verfahren nicht brauchbar, nützt die ganze Sicherheit nichts. Ist es völlig unsicher, nützt es wohl kaum von Brauchbarkeit zu sprechen. Deshalb gilt es, die Balance zwischen beiden Aspekten zu wahren und gute Kompromisse zu finden.

Je nach benutzender Person könnten solche Kompromisse anders ausfallen. Der Kompromiss "pseudozufällige Kennwörter mit 128 Bit Stärke", den ich persönlich bevorzuge, mag z. B. für die eine zu unsicher sein (da pseudozufällig und nicht echt zufällig) und für die andere zu wenig brauchbar (da nur mit viel Kreativität und Mühe erreichbar) sein.

Daher will ich einige (die meiner Meinung nach wichtigsten) Alternativen besprechen und versuchen, herauszufinden, was sie für Konsequenzen hätten. Wenn man diese tragen will, dann dürften solche Alternativen durchaus Sinn machen. Wenn nicht, so weiß man jedenfalls besser, warum man sie nicht wählen will.

Alternative: Geringere Passwortstärke wählen ...

... bei Internet-Logins

Man muss einem Internetdienst ja ohnehin bis zu einem bestimmten Grad vertrauen. Anderenfalls sollte man mit diesem überhaupt nicht kommunizieren. Selbst bei clientseitiger Verschlüsselung (angebliche "Zero-Knowledge"-Technologie5) ist Vertrauen nötig. Denn wäre der Dienst bösartig, könnte er einfach die JavaScripts so verändern, dass diese doch die Klartext-Informationen an den Server weiterleiten.6

Wenn man einem Internetdienst zutraut, dass er die Serverdaten zuverlässig vor fremdem Zugriff schützt, so sind für die Passwortstärke keineswegs 128 Bit erforderlich, sondern weitaus weniger. Denn selbst Botnets können nur in weitaus geringerer Frequenz Kennwörter auf einem Internet-Account ausprobieren, als dies bei abgegriffenen Kennwortdaten mit Offline-Angriffen der Fall ist.

Das Problem ist nur, dass es selbst bei renommierten Unternehmen wie Microsoft®7, GoDaddy®7 und LastPass7 Dateneinbrüche gegeben hat.8 (Bei LastPass waren allerdings dabei gravierende Sicherheitsmängel offenbar geworden. Vielleicht gab es solche auch bei den anderen beiden Unternehmen? Dann könnte man vielleicht annehmen, dass bestimmte, vielleicht kleinere Unternehmen einen effektiveren Schutz bewerkstelligen. (Ich persönlich würde jedoch eine solche Annahme ohne klare Hinweise, dass es wirklich so ist, lieber nicht treffen.)

Aber man kann natürlich recherchieren, wie viele Sicherheitsvorfälle es bei einem bestimmten Dienst (und anderen Diensten, bei denen ähnliche Sicherheitsstandards gelten) in den letzten Jahren gegeben hat9 und daraus eine Risikoabschätzung ableiten.

... bei lokalen Geräten und Passwortmanagern

In diesem Fall (der durchaus wichtiger als der der Internet-Kennwörter ist, da hier merkbare Kennwörter erforderlich sind) hat die Nutzer*in immerhin selbst die Möglichkeit, auf die installierte Hardware aufzupassen und Unbefugten den Zugang zu verwehren. Ohne Zugang10 kommen Angreifer*innen weder an die Kennwörter noch an die damit geschützten Daten.

Man sollte dann

  • Bei Verlassen des Arbeitsplatzes bei angemeldeter Sitzung diese immer sperren (oder zumindest ein Timeout für automatische Sperrung festlegen) und
  • bei Verschrottung der Geräte die Platte sicher und komplett löschen oder physikalisch (z. B. durch Bohrmaschine oder Hammer) zerstören.

D. h. das Kennwort würde nur als letzte Hürde dienen, um die Daten zu schützen. Falls das Kennwort schwach gewählt ist, hält diese Hürde allerdings gegenüber Profis, die doch Daten abgreifen konnten, nicht stand.

... Risikobereitschaft vorausgesetzt

Eine gewisse Risikobereitschaft ist allerdings bei reduzierter Passwortstärke Voraussetzung. Doch beinhaltet das Fehlen der digitialen Risikobereitschaft auch ein Risiko, da dies ja Aufwände bedeutet. Man muss also abwägen. Es gilt: Der zu leichtsinnige Hase wird wohl vom Fuchs gefressen. Der zu ängstliche Hase kann aber verhungern.

In dem Blog-Artikel "Die Mathematik der Passwortstärke" wird ja durchaus erklärt, warum auch Kennwörter, die keine 128 Bit an Stärke besitzen, derzeit nicht immer geknackt werden. (Es ist halt für Hacker*innen oft einfacher, nur die leicht zu knackenden Kennwörter abzusahnen, als die mittelstarken mit aller Gewalt zu knacken.) Aber man läuft natürlich Gefahr, dass es eine*n dann bloß später erwischt. Wenn man dieses Risiko eingehen mag, warum nicht? Für eine begrenzte Übergangzeit (z. B. bis man ein 128-Bit starkes Kennwort den Fingern11 beigebracht hat) halte ich dieses Risiko ohnehin für vertretbar.

... oder man rechnet genau nach

Die 128 Bit sind recht grob übernommen von den NIST-Empfehlungen für uneingeschränkte empfohlene Verschlüsselungs- und Hash-Algorithmen. Nun verlangen die NIST-Empfehlungen bis 2030 streng genommen nur 118 Bit, und es werden 128 Bit erst ab 2030 verlangt, und selbst dann gibt es noch Ausnahmen, bei denen 118 Bit erlaubt sind.

Man kann sich jetzt damit beschäftigen, ob diese 10 Bit geringere Stärke nicht auch für Kennwörter im Bereich Geräte und Hauptpasswörter bei Browsern und Passwortmanagern ausreichend sind. Sind die Übergangsregeln für 118-Bit-Algorithmen nur Kompromisse, die das NIST bezüglich der Weiterverwendung von schon im Einsatz befindlicher Software eingegangen ist, oder hält das NIST tatsächlich 118 Bit für sicher bis 2030? Muss man tatsächlich die Sicherheitsstärken für alle Algorithmen (symmetrische und asymmetrische Verschlüsselung und auch Hash-Algorithmen) und auch die Kennwortstärke gleich wählen?12

Wenn man weiß, welche Schlüsselstreckung ein Browser oder ein Gerät bei der Anmeldung vornimmt, kommt man vielleicht auch damit auf eine noch etwas geringere notwendige Kennwortstärke.

Mir erschien der Aufwand, die obigen Fragen sicher zu ergründen, allerdings zu hoch. Ich halte es für einfacher, ein längeres Kennwort zu erlernen, als der Sicherheit eines kürzeren Passworts nachzugehen, die ohnehin in sechs Jahren obsolet ist. Aber andere mögen das vielleicht anders sehen.

Echt zufällige Kennwörter für Geräte und Passwortmanager wählen?

Pseudozufällige Kennwörter zu entwickeln ist nicht jedes Menschen Sache. Dazu braucht es Kreativität, Geduld und ein Gefühl dafür, ob ein Kennwort aus der Sicht der Hacker*in wirklich zufällig erscheint.

Eine mögliche Alternative ist es, echt zufällige Kennwörer zu entwickeln. Bei diesen wäre man auch sicherer als mit meinem Vorschlag der pseudozufälligen Kennwörter.

Es gibt verschiedene Möglichkeiten:

  • Zufällige Kennwörter auswendig lernen
  • Passphrasen generieren und auswendig lernen
  • Passphrasen generieren und auswendig lernen und von diesen ein Kennwort ableiten (abgekürzte Passphrase), das schließlich die ursprüngliche Passphrase ersetzt.

Bei allen diesen (im Folgenden näher vorgestellten) Möglichkeiten gibt es, wie auch bei der Erstellung und Nutzung pseudozufälliger Kennwörter Vor- und Nachteile. Sie sind unterschiedlich in den Aspekten:

  • Wie aufwendig ist die Erstellung des Kennworts (bzw. der Passphrase)?
  • Wie aufwendig ist das Auswendiglernen?
  • Wie aufwendig ist später die regelmäßige Eingabe des Kennworts (bzw. der Passphrase)?
  • Bei echt zufälligen Kennwörtern oder Passphrasen stellt sich die Frage nach der Sicherheit gegen das Erraten nicht, aber bei pseudozufälligen Kennwörtern schon.

Auch bei der Abwägung zwischen diesen vier Aspekten sollte man eine sinnvolle Balance finden. Betrachten wir daher die Möglichkeiten genauer:

Zufällige Kennwörter auswendig lernen

Also man generiert Kennwörter mit 128 Bit Entropie (z. B. ein 22 Zeichen langes Kennwort aus Klein- und Großbuchstaben und Ziffern) und lernt dieses auswendig. Es gibt auch für zufällig generierte (also sehr kryptische) Wörter Merkstrategien. Ich habe mich nur nicht damit beschäftigt, weil ich mir pseudozufällige Kennwörter leichter merken kann. Aber die Menschen sind verschieden. Ein echt zufälliges Kennwort wäre natürlich sicherer. Ein pseudo-zufälliges Kennwort könnte auch sicher sein, aber der Weg dahin erfordert Einiges an Kreativität und Einfühlungsvermögen in die Gedankenwelt der Hacker*innen. (Was macht ein Kennwort erratbar? Was durchkreuzt jegliche Erratbarkeit?)

Passphrasen generieren

Mit Hilfe eines Würfels und einer Diceware, d. h. einer Liste von einfachen Wörtern, die je einer Folge von ausgewürfelten Zahlen (je 1 bis 6) zugeordnet sind, lässt sich eine echt zufällige Folge von Wörtern erstellen. Z. B. liefert EFF's Long Wordlist eine derartige Liste. Wenn dann fünf Würfelergebnisse 4, 3, 4, 6, 3 ergeben, so findet man in der Liste unter "43463" das Wort "panoramic". Jedes so ermittelte Wort hat dann eine Entropie von 12,92 Bits. Für 128 Bits benötigt man 10 Worte. Wenn 100 Zeichen für ein Passwort erlaubt sind, könnte dies reichen, um die 10 Worte darin unterzubringen.

Man kann jetzt daran gehen, diese Worte nach und nach auswendig zu lernen und auch mit den Fingern11 einzuüben. Hilfreich ist dabei, aus der Passphrase eine Geschichte zu entwickeln, die als Eselsbrücke dient.

Variante: Abgekürzte Passphrase

Das Folgende ist derzeit nur eine Idee, die aber evtl. weitergedacht zu einer neuen praktikablen Variante führen könnte:

Ein Problem einer Passphrase ist die lange Eintippzeit. (Passphrasen sind ja nur für notwendig einzutippende Kennwörter, wie bei der Geräte-Anmeldung, sinnvoll, da andere (z. B. Internet-Kennwörter) viel leichter über einen Passwortmanager generiert und per Copy/Paste – oder über den Passwortmanager des Browsers – eingegeben werden.)

Für die fünf Würfe gibt es 7776 Kombinationen und entsprechend viele Wörter. Diesen Wörter lassen sich nun auch 7776 Kombinationen von je einem Groß- und zwei folgenden Kleinbuchstaben als Abkürzung zuordnen (es gibt 17576 mögliche solche Kombinationen, d. h. mehr als doppelt soviel wie nötig). Dem ersten Wort in der Liste könnte man z. b. 'Aaa', dem nächsten 'Aab' zuordnen. (Nach 'Aaz' kommt 'Aba', nach 'Azz' kommt 'Baa'.) Diese Abkürzungen könnte man zusätzlich in der Liste eintragen.

Angenommen, die Passphrase ist bereits auswendig gelernt. Die Zuordnung kann man nun in der Liste nachschlagen. Die 10 zugeordneten Abkürzungen kann man nun auch auswendig lernen. (Bei künftigen anderen Passphrasen müsste man zwar evtl. neue Abkürzungen lernen, aber für sich genommen würde eine Zuordnung zwischen einem Wort der Liste und seiner Abkürzung immer dieselbe sein und, wenn man sie vergessen sollte, könnte man sie in der Liste nachschlagen. Die Liste selbst ist nicht geheim.)

Jetzt könnte man die Wörter der Passphrase (Stück für Stück, um die Finger11 es lernen zu lassen) durch deren Abkürzungen ersetzen. Das sieht dann zwar kryptisch aus, aber als Leitfaden hat man immer noch die Passphrase und dahinter die dieser Passphrase zugeordnete Geschichte.

Am Ende sollte das einzutippende Kennwort nur noch 30 Zeichen ausmachen, schön übersichtlich, da das erste Zeichen einer jeden Abkürzung ein Großbuchstabe ist.

Ich kann mich erinnern, dass ich als junger Mensch recht schnell die binäre Codierung von ASCII-Zeichen auswendig wusste. Deswegen glaube ich, dass der oben beschriebene Weg für viele durchaus gangbar sein könnte.

Fortgeschritte Variante: Kürzere Abkürzungen, Wortpaare

Wenn man statt 7776 nur 3844 (also etwas weniger als die Hälfte) Wörter in der Liste hat, dann könnte man für die Abkürzungen eine Kombination von zwei alphanumerischen Zeichen (insgesamt 3844 verschiedene Kombinationen möglich) wählen. Um 128 Bit Entropie zu erhalten, bräuchte man allerdings 11 Wörter. Und damit man die Abkürzungen noch halbwegs übersichtlich eingeben kann (man müsste das auch visuell kontrollieren können), sollte man wohl (da die Abkürzungen dann an beiden Stellen sowohl Klein- als auch Großbuchstaben als auch Ziffen haben können) nun Leerzeichen nach je zwei Abkürzungen (also nach je vier Zeichen, ähnlich wie bei der IBAN) einstreuen.

Im Ergebnis würde man auf 22 Zeichen für die Abkürzungen und dazwischen insgesamt fünf Leerzeichen kommen, das wäre wohl weniger Tipparbeit als in der ersten Variante mit 30 Buchstaben.

Man könnte die gleiche Liste von 7776 Wörtern verwenden, aber die letzten 88 Wörter weglassen und bei den übrigen je zwei Wörtern dieselbe Abkürzung zuordnen.

Die Auswahl würde dann nicht durch Würfeln, sondern durch einen Zufallszahlengenerator, den wir z. B. in key.matiq einbauen müssten, erfolgen. Es würden dann nicht die Worte, sondern die Abkürzungen ausgewählt und die Wortpaare (mit gleicher Abkürzung) dazu angezeigt. Der Vorteil wäre, dass man sich aus jedem Wortpaar selbst ein Wort für die Passphrase aussuchen könnte (ohne Entropie zu verlieren). Man hat also mehr Möglichkeiten, für die Passphrase eine gute Geschichte zu finden. Man braucht sich nur das gewählte Wort eines Paares merken, nicht das verworfene, da es letztlich auf die Abkürzung ankommt.

Englisch – Deutsch?

Die Wortliste von EFF gibt es schon ziemlich lang. Es gibt andere Wortlisten, die aber nicht ganz so nutzungsfreundlich sind. Von daher denke ich, sollte man von der EFF-Wortliste ausgehen. Eine deutsche Fassung hätte den Nachteil, dass es ja für jedes Wort leicht mehrere Übersetzungen geben kann und auch in der Liste durchaus Synonyme vorkommen. Da etwas Konsistentes hinzubekommen, wäre nicht nur viel Arbeit für die deutsche Sprache, sondern müsste dann in Zukunft auch für jede weitere Sprachunterstützung erfolgen.

Da denke ich doch, dass es zumutbar ist, zehn oder elf englische Worte nachzuschlagen und ggf. zu lernen, um die passende Geschichte in der eigenen Sprache zu entwickeln.

Sieht dies jemand anders? Dann bitte ich um Feedback, vor allem jedoch um konkrete Vorschläge, d. h. Wortlisten analog der von EFF in anderen Sprachen.

Unterschiedliche merkbare Kennwörter für jeden Zweck

Für Benutzer*innen, die sich nur selten bei Web-Apps anmelden, empfehlen wir, dass sie die Kennwörter für den Browser ("Hauptpasswort"), key.matiq ("Hauptkennwort") und den Computer ("PIN" oder "Passwort") gleich wählen.

Irgendwann ist dieses Kennwort aber eingeübt, und es kommen auch noch andere Geräte hinzu, weitere zu merkende und einzutippende Kennwörter.

Dann kann es Sinn machen, ein System von verschiedenen Kennwörtern zu entwickeln mit gemeinsamen Teilen. Z. B. einem gemeinsamen langen Teil, der zunächst eingetippt wird. Dann einem Teil, der verschieden ist für jedes Gerät bzw. für die Cloud (PC, Laptop, Smartphone, Cloud) und dann einem Teil, der verschieden ist für jeden Zweck bzw. jede App (Anmeldung an das Gerät, Hauptpasswort für den Browser, Masterpasswort/Hauptkennwort für einen Passwortmanager, Passwort für eine Remote-Login-Sitzung, etc.)

Die Übersicht kann man ganz gut behalten, indem man die Teile z. B. in key.matiq als Teilgeheimnisse (Komplemente oder Komponenten13) implementiert.

Man kann zunächst den prinzipiellen Aufbau für alle einzutippenden Kennwörter gleich halten, und später kann man auch den Aufbau varieren, falls man ein gutes Gedächtnis hat,

Im Hinterkopf sollte man die Frage behalten: Was passiert, wenn eines der einzutippenden Kennwörter kompromittiert wird. Also z. B. ungewollt die PIN des PC doch an Microsoft geschickt wird. Wie sicher sind dann noch die anderen Kennwörter? Welchen Aufwand muss ich dann betreiben, um den Schaden gering zu halten? Und welchen Aufwand muss ich im Normalfall, also täglich betreiben? Wie wahrscheinlich ist es, dass der Bösfall eintritt?

Auch sollte man aufpassen, es nicht allzu kompliziert zu machen.14 Alle Kennwortteile und auch der Aufbau sollten regelmäßig den Fingern (zum Erhalt des Trainingszustands)11 angeboten werden, oder es sollte zumindest einen sicheren Notnagel geben, über den man z. B. noch in die key.matiq-Box hineinkommt, um nachzuschauen. (Auch wenn der PC kaputt, das Smartphone verloren gegangen, oder das Haus abgebrannt ist.)

Die verschiedenen Risiken sollten Sie gegeneinander abwägen. Es gilt für jedes Einzelrisiko: Risiko gleich Eintrittswahrscheinlichkeit mal Schaden bzw. Aufwand. Der tägliche Aufwand (100 % Eintrittswahrscheinlichkeit) sollte auch nicht unterschätzt werden.15. Man muss eine Balance finden! Und damit kommen wir wieder zum Motto dieses Artikels.

Fazit

In diesem Artikel wurden viele Alternativen besprochen, mit denen man Risiken bezüglich der Passwortsicherheit begegnen kann. Ich habe zwar Preferenzen, die ich auch nicht verheimliche, aber letztlich muss jede*r selbst für sich entscheiden, was er für sich für sinnvoll hält. Es gibt da kein absolutes Ja oder Nein, sondern eher die Suche einer klugen Balance zwischen verschiedenen Ansätzen.

Auch wenn ich persönlich lieber mit pseudozufälligen Kennwörtern operiere, so gibt es doch auch andere, die Passphrasen bevorzugen. Diese sollten jedenfalls auch von key.matiq unterstützt werden. Vielleicht sogar auch mit den beiden Varianten, die mir als Mischform eingefallen sind. (Das wird allerdings wohl etwas dauern, weil wir derzeit noch heftig mit der CKS-Implementation beschäftigt sind.)

1) Eine Ausnahme bilden z. B. PINs von Chipkarten, da hier der Schutz durch die Selbstzerstörung nach einer Anzahl Fehlversuchen gewährleistet wird.
Eine andere Ausnahme bilden z. B. Zahlenschlösser, weil hier eine Vielzahl langsamer manueller Versuche (unter dem Risiko des in flagranti erwischt Werdens) oft bereits einen ausreichenden Schutz ermöglicht, und die Erhöhung des Schutzes normalerweise einen Austausch der Hardware (des Schlosses oder gleich des ganzen Tresors) voraussetzt.

2) Siehe den Blog-Artikel "Das gute Kennwort".

3) Die Enthüllungen von Edward Snowden sollten wir nicht vergessen. Offenbar sammelt die NSA in großem Stil nach wie vor Daten über die gesamte Weltbevölkerung, die bei Bedarf dazu dienen können, Dossiers über beliebige ins Visier geratene Personen zu erstellen. Was wissen wir, wer z. B. in Zukunft Präsident*in der USA wird? Und was es bedeuten wird, wenn diese dann Zugriff auf diese Daten hat?

4) Ich habe den Verdacht, dass diesbezügliche Äußerungen gar nicht auf Fantasielosigkeit zurückzuführen sind, sondern eher das Ziel verfolgen, die Kritik anderer niederzureden.

5) Siehe Glossar "Zero-Knowledge-Server".

6) Es ist nicht einmal Bösartigkeit erforderlich. LastPass7 hatte z. B. von "Zero-Knowledge" gesprochen, obwohl sie ganz bewusst Begleitdaten im Klartext auf dem Server abgespeichert hatten. (Ohne dass sie dies kenntlich machten oder es für die Nutzer*innen einen Vorteil brachte.) Es war einfach eine Lüge, nicht um ihre Kund*innen zu bestehlen, sondern um sich Aufwand zu ersparen und um den Eindruck zu erwecken, dass sie wenigstens so sicher seien, wie ihre Konkurrenz. Das sollte man zwar nicht gerade "bösartig" nennen (denn sie haben ihren Kund*innen ja nicht absichtlich geschadet), aber natürlich haben sie damit ihre Kund*innen schwer hintergangen (und haben jenen grob fahrlässig geschadet).

7) Hinweise zu Marken Drit­ter:
"GoDaddy" ist eine eingetragene Marke der GoDaddy Operating Company, LLC. Inc.
"LastPass" ist eine Marke oder registrierte Marke von LastPass US LP in den U. S. und anderen Ländern.
"Microsoft" ist eine eingetragene Marke der Microsoft Corporation in den USA und/oder anderen Ländern.

8) Siehe die Blog-Artikel "Unsichere Zeiten" und "Sicherheitsbresche bei LastPass".

9) Im EU-Raum sind durch die DSGVO Unternehmen verpflichtet, ihre Kund*innen über sie betreffende Sicherheitsvorfälle unverzüglich zu unterrichten.

10) "Zugang" heißt hier nicht nur "physikalischer Zugang". Ein Virenscanner kann in der Regel ebenfalls alle Daten des Rechners lesen. (Sonst könnte er seine Aufgabe schlecht erfüllen). Daher muss man dem Scanner, bzw. dessen Hersteller schon vertrauen.

11) Siehe auch den Blog-Artikel "Das Gedächtnis der Finger".

12) Die verschiedenen Algorithmen unterscheiden sich in der Zeitdauer. Eine Hash-Berechnung mit SHA-256 dauert (auf unserem Server) ungefähr doppelt solange wie eine AES-Entschlüsselung, eine RSA-Entschlüsselung ungefähr 1000 mal so lang. Dementsprechend könnte man wohl beim Hashing mit SHA-256 wohl ein Bit weniger an Sicherheitsstärke (bei RSA-Schlüsseln sogar 10 Bits weniger an Stärke) verantworten. Aber das eine Bit, was man beim Hashing sparen könnte und was dann auf die nötige Kennwortstärke durchschlagen würde, macht den Kohl wohl auch nicht fett.

13) Siehe die Blog-Artikel "Das Komplement-Konzept" und "Komponenten".

14) Ich stimme Ihnen zu, das klingt doch widersprüchlich: Ich führe viele in der Summe komplizierte Aspekte an und schreibe dann, Sie sollten es ihrerseits einfach halten. Aber ist es nicht besser, sich lieber einmal durch eine komplizierte Gemengelage an Aspekten zu arbeiten, um dann eine für eine*n selbst passende, genügend einfache Lösung für den täglichen Gebrauch zu finden, als es sich voreilig zu einfach zu machen und dann später darüber bös zu stolpern?

15) Siehe auch den Blog-Artikel "Risikominimierung".


>> Zurück zum Artikelverzeichnis >>