Kurzer Nachtrag auch von mir:
Mir ist beim Vergleichen von Alternativen heute wieder eingefallen, dass ich damals den VLC Media Player genutzt hatte um den Bildschirm aufzunehmen.

Nachteile:
- Tonspur muss separat aufgenommen werden (=umständlich)
- Streamingdienste wie Amazon Prime liefern nur nen schwarzen Screen
- Videobearbeitung bringt der auch nicht mit

Aber wenn man den VLC Player eh schon zum Filme schauen aufm rechner hat, dann ist er für manche Aufgaben ggf. die einfachste Lösung.

Ja, klar geht das. https://letmegooglethat.com/?q=keepassxc+how+to+use+TOTP+2FA%3F   

Also, wenn du meine Suchwörter direkt in Google einklimperst, dann sagt schon die Google KI im erweiterten Modus, wie es geht.

Zusätzlich kommen da diverse Youtube-Video-Anleitungen. Ist jetzt nicht wirklich schwer.

Ich würde auch immer noch beides benutzen. Die TOTPs auf demselben Gerät ist zwar praktisch, aber eigentlich dann kein 2FA mehr. Ich mache das z.T. aber auch, einfach als Backup und weil es manchmal geschmeidig praktisch ist.

Da ein Passwortmanager sowieso ein begehrtes Angriffsziel ist, sollte klar sein, daß dessen Absicherung mit einem sehr starken Faktor oder einem Hardware-Key oder einem 2FA, der wirklich auf einem anderen Gerät ist, hohe Priorität haben sollte.

Du kannst die DB/KeyFile auf einem Netzwerkshare ablegen und mit mehreren Geräten darauf zugreifen.
Alternative du nutzt einen File-Sync Service deiner Wahl OneDrive etc. pp. um das File hin und her zu syncen.

EDIT: Solange es nur um einen Benutzer geht, funktioniert das ganze relativ gut. Berechtigungssystem oder ähnliches suchst du aber bei KeePassXC vergebens. Falls du mehrere Nutzer damit ausstatten möchtest - würde ich in Richtung VaultVarden (Je nach allg. Kenntnissen) mit lokaler Instanz tendieren. Hier hast du weit mehr Einstellungs / Konfigurationsmöglichkeiten betreffend Multi-User Szenarien.

Ja, sowas kann man auch machen, solange man damit klarkommt und trotzdem sichergestellt ist, daß stets individuelle Passwörter für unterschiedliche Dienste verwendet werden.

Trotzdem halte ich das für weniger sicher, als tatsächlich zufällige Passwörter zu verwenden, die ein Passwort-Manager verwaltet und die nach keinem menschlichen Schema konstruiert sind.

Meist hat man bei deinem Vorgehen einen "sicheren" Teil im Passwort, der üblicherweise nicht erratbar sein sollte und einen dienstbezogenen Teil, der irgendwie offensichtlich für einen selbst ist, so daß man sich den nicht mal merken muss, weil man einfach weiß, wie man den konstruiert. Kann man dann am "sicheren" Teil einfach anhängen oder voranstellen.

Keine Ahnung welches Schema du benutzt, musst du selbstverständlich nicht mal im Ansatz offenlegen.


Ich sehe so ein managerloses Schema aus folgendem Grund als weniger sicher an:
mal angenommen ein Dienst wird gehackt und die haben die Kundenpasswörter nicht nach dem Stand der Technik gespeichert, z.B. nicht als "gesalzene" Hash-Werte mit einem sicheren Hash-Verfahren, selten bekommt man belastbare Infos dazu, und Fieslinge konnten Klartext-Passwörter abgreifen oder das verwendete schlechte Hashverfahren knacken. Die Fieslinge erlangen also Kenntnis von deinem "sicheren" Passwort-Teil und das Schema für den dienstebezogenen Teil ist "offensichtlich" oder leicht erratbar.

Damit fällt so ein managerloses Schema in sich zusammen und erlaubt Angreifern weitere deiner Konten anzugreifen.

Mit individuellen und zufälligen Passwörtern kann das nicht passieren und da managerverwaltet kannst du idR ohne Komforteinbußen lange Passwörter benutzen, Minimum 16, besser 20, aber 24 oder 32 Zeichen sind da auch kein Problem.


Aber, nicht ignorieren, ein Passwort-Manager ist dann immer auch ein sehr begehrtes Angriffsziel. Die wenigen guten Produkte stehen bei Bösewichten und deren potentieller Malware recht weit oben auf der Liste. Ich sähe hier einen bevorzugten Angriffsvektor über die bei Passwort-Managern übliche Browser-Integration.

Man kann hier nur hoffen, daß die Browser-Erweiterungen gescheit programmiert sind. Aber da Browser selbst kaum noch handhabbare Software-Ungetüme sind, dürften sich der eine oder andere Zero-Day-Bug immer wieder finden und ausnutzen lassen.

Funfact: Nicht wundern wenn du auf Seiten / Dienste triffst die keine 16+ Zeichen Kennwörter haben möchten oder sogar gewisse Zeichen ausschliessen.

Bzgl. KeyFile auf SyncDienst oder Share:

Grundsätzlich würde ich in drei Sicherheitsrelevante Bereiche unterteilen.

• A: Dein persönliches Passwort
• B: Deine 2FA Variante (KeyFile, YubiKey, Biometrische Daten via Windows Hello und co)
• C: Rechner auf welchem der Passwort-Manager genutzt wird

Habe ich dein Passwort fehlt mir die 2FA Variante und vice versa - Somit prinzipiell schon einmal nicht verkehrt.
Erbeute ich die Datenbank und/oder das KeyFile - Könnte ich Bruteforcen... also das RIG mit 20x RTX 4090 angeschmissen, hashcat(HC-Mod 13400 (KeePass 1/2AES) starten und testen:

Szenario Master-Passwort ist 16 Ziffern lang - Achtung, ungefähre Werte:

• Bei 16 Zeichen und (0-9 (N=10)): Ca. 24 Jahre
• Bei 16 Zeichen und (a-z,A-Z,0-9 (N=62)) : Ca. 105 Millionen Jahre
• Bei 16 zeichen und zufällig druckbare Zeichen (≈N=94) wären wir bei ≈ 8.9x10¹⁶ Jahren

Optional: Haben wir KDBX4 mit Argon2 als KDF (Argon2 reduzierst die Guess-Rate - "GPU unfreundlich") kann man die oben genannten Werte ca. x1650 Rechnen

Jetzt denkt man sich gut, dann kann ich ja GPU Power anmieten um die Wartedauer zu reduzieren, sagen wir ich möchte ungefähr die 100x Leistung meines RTX-Rigs und wir ballern die Leistung auf die 16 Zeichen mit (0-9) - denke das wäre ohne Argon2 das einzige halbwegs realistische Szenario:

• p5.48xlarge mit 8x NVIDIA H100 um die 100x Leistung zu erhalten bräuchte ich davon ca. 344 Instanzen was dann Kosten von $ 19'000 pro Stunde aufrufen würde und totale Kosten von ca. $ 39.9m
• p4d.24xlarge mit 8x NVIDIA A100 40GB etwas günstiger, dafür 588 Instanzen benötigt und dafür nur ca. $ 13'000 pro Stunde und totale Kosten von $ 27.2m

Somit kommen wir auf eine Dauer bis zur Lösung von ≈ 87.7 Tage und entsprechend ≈ 2106 Stunden oder eben ≈ x1650 mit Argon2

Im schlimmsten Falle ca. doppelt so teuer. Das sind dann reine Compute Kosten ohne Nebenkosten - Hier gibt es sicherlich noch bessere Möglichkeiten(Spot, Reserved oder saving plans usw...), (Verfügbarkeit?   ) soll nur als Beispiel dienen; hier bin ich jetzt zu faul  

Angemerkt soll aber sein: Die Dauer lässt sich durch kombinierte Angriffe (Wörterbücher, sinnvolle Regeln usw...) auch nochmals etwas reduzieren.

In kurz: Masterpasswort mind. 16 Zeichen lang Grossbuchstaben, Kleinbuchstaben Zahlen und Sonderzeichen - Keine Worte, Keine Abwandlungen und co - Mit den ungefähr bekannte PW-Regeln mehr oder weniger auf der sicheren Seite + Sinnvolle 2FA Variante und A sowie B sind ausgeschlossen.

Kommen wir nun aber zu C: was leider viele vergessen (In meiner bescheidenen Vorstellung das eher relevante Risiko):

Was man eher bedenken sollte ist, dass bei KeePassXC und vielen anderen Passwort-Managern sobald diese geöffnet sind, die Einträge (gesamte DB oder teilw. in der Session genutzte Einträge) im RAM - ! im Klartext ! "gespeichert" werden, ansonsten könnte KeePassXC diese nicht anzeigen oder z.B. durchsuchen.

Unter normalen Umständen kaum ein Problem(Sitzt jemand auf deinem Rechner oder hat Zugriff in irgendeiner Form - ist es eh schon mehr oder weniger gelaufen) - in der Theorie sieht das ganze aber etwas anders aus: Trojaner mit Zugriff auf RAM, Forensische Tools für RAM-DUMP und co. - ganz in der Theorie Cold-Boot Attacks... Das wird offen kommuniziert, wissen aber leider die wenigsten Anwender. Hervorgehoben werden sollte allerdings, dass die neueren KeePassXC Versionen zumindest die Einträge sauber "bereinigen" nach dem schliessen der DB. Auto-Lock (nach wenigen Minuten oder manuelles schliessen und öffnen zehren zwar am Komfort, bringen hier aber wiederum Sicherheit)

Das ganze könnte man natürlich nochmals weiter in div. Angriffsvektoren unterteilen - sollte aber einfach mal ein genereller Input sein.

EDIT: Ist immer ein Balance-Akt zwischen Sicherheit und Komfort...