• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

keepass: Passworte im Klartext in den Logs

gehrke

Administrator
Teammitglied
Moin *

Mit einigem Erschrecken musste ich heute feststellen, dass beim Kopieren eines Passwortes vom Passwortmanager keepass ins Clipboard das Passwort im Klartext im System-Journal gelogged wird!

Dort liegt es üblicherweise lokal, aber möglicherweise loggt ja jemand auch remote, dann wird es noch weiter verteilt. In meinem Fall werden die Logs wie alles andere auch dann spätestens beim täglichen Backup an anderer Stelle vorgehalten. Ein schönes Beispiel für '... und verschlüsselt immer schön eure Backups!'.

Offenbar ist das ganze auch schon seit 2018 bekannt und dokumentiert:
https://sourceforge.net/p/keepass/discussion/329220/thread/33d6afdc/

Das ist IMHO ziemlich fatal.
Bei Verwendung des Passwortmanagers Seahorse (Gnome) beispielsweise passiert so etwas nicht. Ich vermute eine Abhängigkeit zu Mono als Ursache.

Mich würde interessieren, ob das noch in anderen Konstellationen nachvollziehbar ist.

Mein System:
*Fedora 35
*Gnome/Wayland
*keepass installiert aus den Fedora-Repos

Glückauf, gehrke
 
OP
gehrke

gehrke

Administrator
Teammitglied
Code:
# dnf info keepass
Letzte Prüfung auf abgelaufene Metadaten: vor 4:05:48 am Di 04 Jan 2022 10:33:22 CET.
Installierte Pakete
Name         : keepass
Version      : 2.48.1
Release      : 3.fc35
Architecture : x86_64
Size         : 3.3 M
Quelle       : keepass-2.48.1-3.fc35.src.rpm
Repository   : @System
Aus Paketque : fedora
Summary      : Password manager
URL          : https://keepass.info/
Lizenz       : GPLv2+
Description  : KeePass is a free open source password manager, which helps you to
             : remember your passwords in a secure way. You can put all your passwords in
             : one database, which is locked with one master key or a key file.  You
             : only have to remember one single master password or select the key file
             : to unlock the whole database.
 
OP
gehrke

gehrke

Administrator
Teammitglied
marce schrieb:
Switch auf KeePassXC?
Das ist sicher der naheliegende Schritt, weil die Password-Files verwendet werden können.

Aber nun werde ich wohl sämtliche Logs und Backups löschen dürfen und mir wohl überlegen, für welche Systeme ich nun neue Passworte generieren muss. :zensur:

Aber was mich interessiert:
gehrke schrieb:
Mich würde interessieren, ob das noch in anderen Konstellationen nachvollziehbar ist.
 

stka

Guru
Keepass wird eh schon länger nicht mehr gepflegt. Geh auf KeepassXC und richte dir das ganze dann mit einem Yubikey ein und schon hast du keine Passwörter mehr die du eingeben musst. Klappt super, beim Login, bei ssh, bei updates und natürlich im Browser. Ich kenne keines meiner Passwörter mehr. Ich bin alt und bin froh, dass ich meinen Yubikey finde :D :p ;)
 
Obgleich ich, beruflich bedingt, auch einen Yubikey im Einsatz habe, würde ich auf die Alternative Nitrokey verweisen. Open Source Hard- und Software empfinde ich als echtes Argument. Wenn man keinen zwingenden Grund für einen Yubikey hat, sollte man Nitrokey zumindest in Betracht ziehen.

Um auf die Ursprungsfrage zurück zu kommen: Ich verwende seit Jahren keepassx und hab gerade mal nachgesehen aber unter debian sid scheint kein Content des clipboards ins journal geschrieben zu werden. Da die Entwicklung von keepassx jetzt offiziell eingestellt wurde, werd ich wohl auch auf keepassxc umsteigen.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Um auf die Ursprungsfrage zurück zu kommen: Ich verwende seit Jahren keepassx und hab gerade mal nachgesehen aber unter debian sid scheint kein Content des clipboards ins journal geschrieben zu werden.
Danke fürs Nachschauen.

Ein Wechsel ist unter den Umständen ja komplett alternativlos. Ich habe schon keepassxc installiert, wahrscheinlich wird es das werden.

Aber ich habe ja weiterhin die Kombination von Mono mit Systemd und Wayland in Verdacht und würde das gerne verifizieren. Mono gibt es AFAIK ja nur beim Original 'keepass'. Eigentlich geht es mir darum in diesem Thread - und um eine Warnung an andere User.

Also falls jemand mit einer anderen Kombi als Gnome@Fedora die Möglichkeit hat, keepass zu testen...
 

/dev/null

Moderator
Teammitglied
Guten Morgen allerseits!

Ich habe mir ausgelöst von diesem Thread gestern Abend mal den "Spaß" gemacht, und bei einem meiner internen Geräte (meinem pi-hole) das beliebte hochsichere Passwort "mmm123!" festgelegt und mich mehrfach dort mit meinem Passwortmanager angemeldet. Auch, was ich ja sonst nicht nötig ist, via Zwischenablage.
Dann habe ich die Zwischenablage gelöscht und eine Volltextsuche nach diesem String über das gesamte System angestoßen.
Ergebnis am heutigen Morgen: NIX zu finden. (Die Gegenprobe mit einem bewusst in einer Datei hinterlassenen anderen String war positiv.)

Ach ja, ich nutze von Anfang an KeepassXC. (Mit lokaler Speicherung und Remote-Zugriff für außerhäusig betriebene Geräte über mein Wireguard-VPN.)

Die Anmeldung daran erfolgt mit einem trivialen 8-stelligen Passwort und meinem YubiKey.
Ich habe auch schon versucht, meinen neuen "Nitrokey 3A NCF" dafür zu nutzen, aber es ist mir leider nicht gelungen. (Gibt es andere/bessere Erfahrungen?)

Wayland nutze ich auf meinen Rechnern (noch) nicht.

Tipp für gehrke: IMHO ist ein auch sonst nicht schadender Passwortwechsel einfacher, als sämtliche betroffenen Dateien zu finden und zu löschen. Ich mache das immer noch in gewissen Abständen (auch wenn es Stimmen gibt, die da anderer Meinung sind). Ich muss ja meine langen und hochkomplexen PW niemals (!) von Hand eintippen. Und sie müssen ja auch nicht "merkbar" sein.

vy 73 de Peter
 
OP
gehrke

gehrke

Administrator
Teammitglied
/dev/null schrieb:
Tipp für gehrke: IMHO ist ein auch sonst nicht schadender Passwortwechsel einfacher, als sämtliche betroffenen Dateien zu finden und zu löschen.
TNX

Nur damit das klarer wird: Suchen muss man da nicht. Die Passworte werden eindeutig in das Journal von systemd geschrieben - kann man einfach beobachten mit:
Code:
journalctl -f
Genau so wie es in dem oben verlinkten Beitrag von 2018 dokumentiert ist.
 

/dev/null

Moderator
Teammitglied
Ich wollte mit meiner Suche bewusst feststellen, ob die PW "irgendwo" ungewollt gespeichert werden.
Und JA, ich kenne die Optionen für journalctl und ich weiß auch, dass sich so manches in der Auslagerungsdatei verstecken kann. ;)
Und obwohl mir nach mittlerweile 6 Jahren als Pensionär immer noch gewisse Unterschiede in den Sicherheitsanforderungen für die einzelnen Vertraulichkeitsstufen gut bekannt sind, versuche ich auch heute noch, ein gewisses Optimum zwischen Aufwand und Nutzen (also nicht mehr das früher von mir geforderte Maximum!) bei meinen jetzt nur noch als "pillepalle-privat" eingestuften Daten durchzusetzen. Und manchmal nehme ich mir dafür auch Zeit ....

vy 73 de Peter
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Also falls jemand mit einer anderen Kombi als Gnome@Fedora die Möglichkeit hat, keepass zu testen...
Ich habe mal die Live-ISOs von openSUSE Leap 15.3 in den Varianten KDE und Gnome in VMs ausgeführt und dort keepass installiert.

Zumindest die Gnome-Variante scheint auch Wayland zu verwenden.

Resultat: Das beobachtete Verhalten tritt dort nicht auf!
 
OP
gehrke

gehrke

Administrator
Teammitglied
Noch ein Test mit Debian 11.2 Gnome Live als VM.

Auch dort ist das Verhalten nicht zu beobachten.
 
gehrke schrieb:
Nur damit das klarer wird: Suchen muss man da nicht. Die Passworte werden eindeutig in das Journal von systemd geschrieben - kann man einfach beobachten mit:
Code:
journalctl -f
Genau so wie es in dem oben verlinkten Beitrag von 2018 dokumentiert ist.
Ist bekannt, erlebt mit gpg vor einigen Jahren.
gpg (GNU Privacy Guard) ist das PGP für Linux zum Verschlüsseln und Signieren von Files.
gpg bietet eine kleine Erweiterung mit dem Namen "pinentry" an, das zur Eingabe von Passwörtern und Pin-Nummern gedacht ist. Für das Signieren und Entschlüsseln braucht man den secret key und für die Verwendung dieses keys natürlich das password, das über pinentry eingegeben wird. Signiert oder Entschlüsselt man nun einen bulk von files mit einem script, konnte man dieses password in eine Variable exportieren und für alle Vorgänge in dieser einen session verwenden. Das ist sicher und zwar aus einem ganz einfachen Grund: jede session ist privat. Keine andere session kann auf Variablen einer anderen session zugreifen und beim Schließen der session ist die Variable weg. Das ist eines der Grundprinzipien von Unix seit Jahrzehnten. Wir konnten aber feststellen, dass systemd die session in ein file exportierte und damit auch die Variable mit password. Warum die das tun und ob dieses File wieder gelöscht wird, diese Fragen müssen erst gar nicht gestellt werden weil dieser Export eine grundsätzliche Sicherheitsmaßnahme zur Gänze aushebelt. Wir haben alles entfernt, was auch nur nach systemd riecht.

Gruß
Gräfin Klara
 
OP
gehrke

gehrke

Administrator
Teammitglied
Hhmm, aber nur an systemd allein kann es in meinem Fall ja auch nicht liegen, denn das nutzen die anderen getesteten Distributionen ja auch. Irgendwas muss speziell Fedora vergeigt haben.
 

marce

Guru
Gerade mal mit einer frischen Installation von Fedora 35 mit KDE in einer VM ausprobiert - das Passwort taucht beim kopieren und manchmal auch wenn Keepass die Zwischenablage löscht in journalctl -f auf...
 
OP
gehrke

gehrke

Administrator
Teammitglied
marce schrieb:
Gerade mal mit einer frischen Installation von Fedora 35 mit KDE in einer VM ausprobiert - das Passwort taucht beim kopieren und manchmal auch wenn Keepass die Zwischenablage löscht in journalctl -f auf...
Ah, vielen Dank für das Testen. Wenn KDE ebenfalls betroffen ist, dann wird es wohl auch nicht an Gnome liegen.
 

Jägerschlürfer

Moderator
Teammitglied
Ich nutze seit Jahren keepassxc und hatte bisher keinerlei solcher Probleme.

Hast du mal ein Bugreport eröffnet? Sinn und Zweck eines Passwortmanagers sollte es nicht sein, Passwörter in ein Log zu schreiben.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Nun, das Problem ist ja schon seit 2018 in SourceForge bekannt und dokumentiert - siehe Link im Intro.
Ich habe nach keepassxc migriert.
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Nun, das Problem ist ja schon seit 2018 in SourceForge bekannt und dokumentiert - siehe Link im Intro.
Auch im Bugtracking von RedHat ist die Problematik für Fedora spätestens seit 26.10.2020 bekannt:
https://bugzilla.redhat.com/show_bug.cgi?id=1891592

Passiert ist scheinbar gar nichts. :zensur:
 
Oben