Ein 32-stelliger Secret Key wird zusätzlich erzeugt, ohne den man sich nicht an neuen Geräten/Clients anmelden kann. Außerdem ist eine zusätzliche, optionale Einrichtung von „klassischer“ 2FA (OTP oder U2F) möglich. ↩︎
Die Tresordatei kann standardmäßig über eine Cloudverbindung oder alternativ mit WebDAV bei einem beliebigen Cloudanbieter geräteübergreifend synchronisiert werden. ↩︎↩︎
Die Tresordatei kann in einer Cloud abgelegt und darüber mit anderen Geräten synchronisiert werden. Die Nutzung kann jedoch zu pfadabhängigen Problemen führen. ↩︎↩︎↩︎↩︎↩︎
Seit Juni 2024 veröffentlicht Strongbox nicht mehr alle Inhalte und Quellcodes. Damit erfüllt Strongbox nicht länger die Definition der Open Source Initiative (OSI). ↩︎
LessPass ist ein Passwort-Manager, der Passwörter auf der Grundlage von benutzerdefinierten Kriterien und einem Master-Passwort generiert. Dabei werden keine Passwörter oder Daten gespeichert, was die Sicherheit und den Datenschutz erhöht. Früher gab es einen Cloud-Dienst, mit dem man die Kriterien für verschiedene Domains speichern konnte, dieser wurde jedoch eingestellt. Heute ist es möglich, die Kriterien entweder lokal zu speichern oder das System selbst zu hosten, wobei die lokale Speicherung ausreicht. ↩︎
Ich habe es mal alphabetisch sortiert (würde ich auch beibehalten und bspw. KeePass-Forks dem unterordnen), 1Password hinzugefügt und dazu noch die Spalte bzgl. Passkey-Support ergänzt.
Darüber hinaus könnte man evtl. neben dem Aspekt von Open Source auch angeben, ob es freie Software ist und wer hinter der Software sitzt. Denn wenn es keine Firma ist, kann man den Firmensitz auch weglassen, um das aufzugreifen was @Selena schrieb.
Mir fehlt hier, so wie überall sonst, noch Lesspass. Von dem gibt es auf Linux eine Kommandozeilen-Variante, welche ich in einem Bash-Skript nutze. Dadurch werden die Passwörter generiert und mittels xdotool abgetippt. Ist super komfortabel in der Nutzung, man braucht kein extra Browserplugin, welches den Fingerabdruck ändert und es funktioniert quasi überall.
Wegen des CLOUD-Acts eigentlich nicht. Da Bitwarden in den USA ansässig ist, sehe ich bei einem EU-Server keinerlei Vorteile gegenüber einem US-Server, denn amerikanische Behörden können sich in beiden Fällen Zugriff verschaffen.
Das Risiko halte ich wegen des Verschlüsselungsmechanismus sämtlicher PW-Manager, die ich kenne, trotzdem für gering, erst recht bei Open-Source-Software wie Bitwarden. Theoretisch könnte es aber bei jeder Software as-a-service eine Backdoor geben, denn auch wenn ich mir den Sourcecode herunterladen kann, weiß ich nicht, welche Version davon auf dem Server läuft, den ich schließlich nur gemietet habe. Genauer gesagt: auf dem ich nur ein Konto besitze, neben vielen anderen Usern auch.
KeePassXC ist eher US.
Der Main Developer ist ein US Amerikaner, welcher hauptberuflich bei der U.S. Coast Guard arbeitet.
Ansonsten gibt es nicht viel weitere Entwickler, die nur ähnlich so viel beitragen, wie der Main Developer.
Keepassxc hat keine Cloud-Synchronisation. Einfach die Datei auf ein Netzlaufwerk schieben wird dem nicht gerecht, da so pfadabhängige Probleme auftreten können. Das „optional“ sollte also entfernt werden.
Bitwarden kann passkeys und es gibt zum selbst hosten sogar mehrere Optionen: Vaultwarden und Bitwarden.
Die Angabe stammt aus dem Impressum. Dort ist Janek aus Weimar als ladungsfähige Person angegeben. Wenn die Angabe nicht korrekt ist, gerne anpassen. Jeder darf mitmachen.
Müsste bei allen KeePass-Forks dann rausgenommen werden, richtig? Wobei wiederum KeePassXC dieses Vorgehen vorschlägt, wenn man seine Daten über mehrere Geräte hinweg synchronisieren will.
Habe ich für dich ergänzt. Da ich kein Android nutze, kann ich die Angaben nicht verifizieren.
Gerne die Daten, die oben benötigt werden mitteilen oder selbstständig ergänzen.
Und vor allem: Wenn die Tresor-Datei clientseitig verschlüsselt ist mit Zero-Knowledge beim Anbieter (wie bei Bitwarden und Proton, die anderen kenne ich nicht), dann ist es schön egal, wo der Server steht. Der einzige Kasus knaxus wäre, wenn der Anbieter den Dienst einstellt. Für den Fall legt man sich halt in passenden Abständen lokale Kopien an. Die SW ist ja FOSS (etwas anderes würde ich eh nicht anfassen).
Passwortmanager: Lesspass (https://lesspass.com)
Open Source: Ja
Cloudanbindung: optional / selbst gehostet
Lokale Tresordatei: Nein
Verschlüsselungsart: keine
Passkey-Support: nein
Lesspass generiert dein Passwort anhand von bereitgestellten Kriterien und anhand eines Master-Passworts. Nichts wird gespeichert. Es gab mal einen Cloud-Dienst, wo man seine Kriterien für die verschiedenen Domains speichern konnte, der wurde aber eingestellt. Jetzt muss man selbst hosten, das ist aber nicht notwendig, weil man die Kriterien auch lokal speichern kann.
Für mich nur nutzbar als Werkzeug, das ich in meinem eigenen Skript für Passwörter nutzen kann. Dann aber in Verbindung mit dmenu und xdotool absolut genial
Ich stelle mir gerade am Beispiel von Proton Pass eine Kernfrage:
Wenn ich es richtig verstehe, dann wird für Proton Pass ein asymetrischer Benutzerschlüssel erzeugt, der über einen aus dem Benutzer Passwort abgeleiteten und mit einem Account Salt bycrpt hash verschlüsselt wird.
Dieses bedeutet, wenn ich den Benutzernamen und Passwort des Proton Pass habe, dass man hierüber den bei Proton gespeicherten Benutzerschlüssel nutzen und dann Zugriff auf alle im Proton Pass gespeicherten Informationen erhalte.
Da jedoch der Benutzernamen und Passwort bei der Anmeldung an Proton Pass genutzt wird, kann doch der Betreiber Proton prinzipiell die Authentisierungs-Daten durch die Anwendung ausleiten und mit diesen dann selbst oder eben eine berechtigte Behörde auf die Proton Pass Daten zugreifen.
Ich selbst nutze Enpass wo ich zwei unterschiedlichen Passwörter für
a.) die lokale Entschlüsselung des Passwort-Safe
b.) eine Anmeldung an einem Cloud-Service für die Synchronisation der verschlüsselten Daten habe
Das erste Passwort für die Entschlüsselung des Passwort-Safe gebe ich nur lokal an meinen Endgeräten ein, sodass dieses niemals zu einem Anbieter übertragen werden muss.
Dieses Verfahren leuchtet mir ein, während ich bei Proton Pass irgendwie ein sehr ungutes Gefühl in Hinsicht auf die Sicherheit habe.
Habe ich hier einen Denkfehler? Oder müsste ein solche Vorgehensweise, wo das Entschlüsselungskennwort an die Anbeiter übertragen werden muss, nicht automatisch eine Abwertung erhalten die aus der Tabelle ersichtlich sein sollte? Oder ist dieses sogar schon mit dem Spalte „lokale Tresordatei“ gemeint?
Ist es nicht aber trifft in diesem Fall zu. Die Spalte bezieht sich simpel auf die Frage, ob es eine lokale Tresordatei gibt, die ich sehen und auch bewegen kann (s. KeePass).
Die Tabelle soll alle wichtigen Informationen, die man anfänglich gebrauchen könnte darstellen ohne diese wiederum zu verkomplizieren. Tatsächlich sind deine Gedankengänge bezüglich Proton Pass zutreffend. Ich verstehe das genauso.
Das bedeutet dann also, dass Proton Pass und andere Passwortmanager mit Web-Zugriff keine Ende-zu-Ende-Verschlüsselung der gespeicherten Daten sicherstellt, bei denen nur meine Endgeräte Zugriff auf die Daten haben.
Es ist eher ein „ich vertraue dem Anbieter, dass er mein Passwort nicht ausleitet“ Sicherheitsniveau.
Ich habe eben eine wichtige Änderung bei Strongbox vorgenommen:
Strongbox ist seit Mitte 2024 nicht länger im klassischen Sinne Open-Source und veröffentlicht nicht mehr alle Inhalte zur Überprüfung. Der Entwickler von Strongbox hat sich bei Reddit dazu geäußert.
Seit dem 15. März 2025 ist der neue Eigentümer die Applause Group, Inc. ein us-amerikanisches Unternehmen.
Ich muss mich korrigieren. In der Zwischenzeit habe ich über das Login-Verfahren bei Proton Mail erfahren, dass das eigene Zugangs-/Schlüssel-Passwort nicht an Proton übertragen wird, sondern aus diesem ein Zugangs-Passwort errechnet wird. Der Anbieter bekommt also im Rahmen des Konzeptes keinen Zugriff auf das Passwort. Ich gehe davon aus, dass dieses Verfahren bei Proton Pass identisch genutzt wird.
Mir war bisher nicht bewusst, dass Proton kein normales Anmeldeverfahren mit übertragenen Passwörtern nutzt und daher der Server niemals das Anwenderpasswort erfährt. Damit kann Proton ohne eine Veränderung des Anmeldeprozesses wirklich das Passwort nicht erfahren.
Damit hätte sich mein Einwand in Hinsicht nicht vorhandene Ende-zu-Ende-Verschlüsselung in Proton Pass zuvor erledigt.
