Bester Passwortmanager auf mehreren Geräten

[DiamondDog]

Du meinst Autofill. Das musste nachrüsten in Keepass mittels Plugin. Out out of the box hat Keepass nur Autotype an Bord.

ja das kenn ich für den Browser, aber für Apps geht das ja nicht

 

[Autokiller677]

Soweit ich weiß muss die Hauptdomain korrekt sein bei dem Standard Match. Nur die Sub-Domains und alles nach der Hauptdomain wird ignoriert.
Das dürfte eine Pishingwebseite nicht hinbekommen, oder?

Schwieriger, aber nicht unmöglich.
Dafür muss dir der Angreifer halt noch einen falschen DNS Eintrag unterjubeln, oder die Domain sogar wirklich übernehmen.
Ist daher seltener, aber nicht, was nicht schon vorgekommen wäre.

 

[snaxilian]

aber für Apps geht das ja nicht

Kommt auf die App an. Nutze Keepass2Android mobil und bei manchen Apps klappt das ausfüllen bzw. wird angeboten. Ich vermute daher, die Username/Password Felder müssen entsprechende Beschreibungen o.ä. haben.

falschen DNS Eintrag unterjubeln

Wird denn wirklich aus der Adresszeile die Domain abgefragt oder gibt es nur eine Prüfung z.B. per RegEx? Dann würde ja auch https://computerbase.de.malicious-domain.com passen.

 

[Mosed]

Nein, weil bei deiner Beispieladresse die Hauptdomain "malicious-domain.com" ist und alles davor nur eine subdomain. Die Subdomain wird aber ignoriert.

Zumindest in der Standardeinstellung. Ändert man diese auf "Domain muss enthalten: Computerbase.de", dann wird so eine Adresse natürlich falsch zugeordnet.

Also Bitwarden prüft die Adresszeile. Soweit ich das weiß.

 

[snaxilian]

Du weißt es also auch nicht und stocherst im Nebel, vermuten kann ich selbst danke
Nach einem Blick in die Doku stimmt je nach gewählter Methode dein zweiter Satz nämlich nicht und genau zu diesem Szenario gab es im Januar 2020 einen Issue im Bugtracker. Ein Fix kam dann im September, also ~8 Monate später und bei self-hosted Systemen müsste der Betreiber dann noch das Update einspielen.
Anyway denn das ist ein Problem jeder Software, unabhängig ob offen oder nicht und welche Lizenz. Frage war ja ob unterjubeln von falschem DNS notwendig ist und die Antwortet lautet dann somit nein.
Die default match Regeln wurden zwar angepasst aber hab auf die Schnelle nicht gesehen ob dies auch für bestehende Accounts bzw. Installationen gilt oder nur für neue...

 

[foo_1337]

Ich nutze Enpass mit einem lokalen Keyfile, sollte jemand die Passwortdatenbank in die Hände bekommen, dann benötigt man immer noch das Passwort und das Keyfile, zumindest wenn die Implementierung sauber ist.

Enpass nutzt die sqlite encryption, da kann man dann, was das File auf der Platte betrifft, glücklicherweise nicht so viel falsch machen.

Die, die Bitwarden selbst hosten, sollten sich unbedingt bitwarden_rs anschauen. Im Vergleich zu dem c#/mssql monster ist das ein leichtgewicht und sauber in rust implementiert. Das ganze frontend geraffel kommt nach wie vor von bitwarden, man muss sich also auch nicht umgewöhnen.

Anonsten werde ich noch das auf gpg basierende pass in Form von gopass, passforios, Android-Password-Store, chrome-pass und browserpass ins rennen. Aus der Security Brille gesehen die sauberste Variante, da hier voll auf well-known Methoden gesetzt wird. Für die Synchronisation bietet sich ein git repo an.

 

[Autokiller677]

Die, die Bitwarden selbst hosten, sollten sich unbedingt bitwarden_rs anschauen. Im Vergleich zu dem c#/mssql monster ist das ein leichtgewicht und sauber in rust implementiert. Das ganze frontend geraffel kommt nach wie vor von bitwarden, man muss sich also auch nicht umgewöhnen.

Ich lese diesen Tipp immer wieder und finde es komisch.

Erst wird hier lang und breit diskutiert, dass man OpenSource, Audits usw. haben will, und dann empfiehlt man für's Backend plötzlich einen nicht-auditierten Nachbau von irgendeinem privaten Hansel, der im ggs. zu Bitwarden nichtmal ein Business / Monetäres Interesse daran hat, dass das langfristig und vertrauenswürdig läuft?
Und da der Server spätestens beim Zugriff übers Web-Vault die Website und damit den JavaScript-Code für die E2E Verschlüsselung ausliefert, kann der Server hier eine Backdoor einschleusen / das Master PW abgreifen. Es ist also nicht so, dass man sagen könnte "der Server ist ja nur eine bessere Cloud und kann keinen Schaden anrichten selbst wenn kompromitiert".

Nicht, dass ich dem Maintainer da was unterstellen will, ich hab keinen Grund zu glauben, dass er da was böses treiben will.
Verwunderlich finde ich dieses hin- und her aber trotzdem.

Und ja, die offizielle Version braucht (bei mir) ca. 1GB RAM, obwohl es nur 4 Nutzer gibt, das ist viel, und liegt einfach an der Microservice-Architektur.
Letztlich langweilen sich die 8GB RAM in meinem Server aber eh zu Tode, weil daneben nur noch eine Nextcloud läuft - und die wenigsten hier werden ihren Home-Server völlig auf Kante betreiben.
Und ich weiß auch nicht genau was "sauber in Rust implementiert" einem da jetzt sagen soll? Die offizielle Version ist größtenteils in C# implementiert, das kann man genauso sauber machen.

Dazu ist BW eigentlich auch ein Musterbeispiel von dem, was viele immer wieder fordern im Bezug auf Cloud-Dienste: OpenSource, selbst hostbar, mit Audit usw. Da zahle ich persönlich gerne ein paar € im Jahr für - statt mit irgendeiner Reimplementierung die Premium-Features kostenlos zu ziehen.

 

[snaxilian]

Und ich weiß auch nicht genau was "sauber in Rust implementiert" einem da jetzt sagen soll? Die offizielle Version ist größtenteils in C# implementiert, das kann man genauso sauber machen.

Genau dein letzter Satz hier zeigt den großen Vorteil von Rust. In C/C++/C# kann man es sauber machen, in Rust muss man es sauber machen.
Bisschen Einstiegslektüre: https://www.heise.de/hintergrund/En...ftware-und-Programmierfehler-ist-4879795.html

 

[Autokiller677]

Rust räumt mit manchen Legacy-Problemen auf und bietet interessante neue Konzepte um Flüchtigkeitsfehler zu vermeiden. Unsicheren oder schlechten Code kann man damit trotzdem schreiben, auch Rust schützt einen nicht vor einer schlechten Architektur, unsicherer Krypto oder sonstwas.

Code nur aufgrund der Tatsache, dass er in Rust geschrieben ist, als "sauber" oder "besser" zu bezeichnen ist ziemliche Augenwischerei.

 

[foo_1337]

@Autokiller677 Das Audit Argument zieht bei mir nicht. Prinzipiell müsste bei jedem Release ein neues Audit durchgeführt werden. Dazu kommt, dass es bei Audits halt wie immer so läuft: Wenn der Hersteller das Audit initiiert und bezahlt, darf (man muss man natürlich nicht) man an der Qualität durchaus zweifeln.
Der Code von bitwarden_rs ist schlank, gut nachzuvollziehen und mittlerweile sehr verbreitet. Das Backdoor "Argument" kann ich nicht mehr hören. Das ist völliger humbug und kommt in der Regel nur bei dubioser Software vor oder wenn ein Repo kompromittiert wurde. Viel wahrscheinlicher ist beschissener Code, der unbeabsichtigt geschrieben wurde. Und diese Wahrscheinlichkeit ist eben bei Rust deutlich geringer als bei C*.

Und ganz ehrlich: Wer davor angst hat, nimmt ohnehin nicht so ein Monster wie bitwarden, sondern wie oben vorgschlagen etwas schlankes wie pass, was auf well-known gpg basiert oder auch keepass.

 

[Autokiller677]

Es mag ja sein, dass du es für dich als irrelevant eingestuft hast.
Ich finde trotzdem, dass man darauf Hinweisen sollte bei einer Empfehlung. Es ist eben eine völlig neue Implementierung, ohne offiziellen Support, Audit oder sonstwas und mit anderen Stakeholdern und Interessen. Nicht einfach nur "wie das offizielle, nur schlannker".

 

[foo_1337]

Schau dir doch die Bitwarden Architektur mal genauer an. Die von dir beispielsweise angesprochene Crypto findet im Client statt. Das Backend sieht kein einziges Passwort im Klartext. Und wenn du keine Software ohne Audit in sensiblen Bereichen einsetzen willst, dann wird es wohl auch nix mit nem Bitwarden Server, egal welcher Implementation, da der Rest ja nicht auditiert wurde.

 

[KitKat::new()]

Erst wird hier lang und breit diskutiert, dass man OpenSource, Audits usw. haben will, und dann empfiehlt man für's Backend plötzlich einen nicht-auditierten Nachbau von irgendeinem privaten Hansel,

Eigentlich ist es eine Gruppe von 69 Leuten - 4 davon mit lang anhaltendem Mitwirken - von denen einer Mal das Projekt gestartet hat, und dann Leute dazu gekommen sind.
Ist übrigens ebenso Open Source und wird auch öffentlich entwickelt.

Ergänzung (19. März 2021)

Da zahle ich persönlich gerne ein paar € im Jahr für - statt mit irgendeiner Reimplementierung die Premium-Features kostenlos zu ziehen.

Kannst du das nicht auch mit dem offiziellen Server?

 

[Autokiller677]

Schau dir doch die Bitwarden Architektur mal genauer an. Die von dir beispielsweise angesprochene Crypto findet im Client statt. Das Backend sieht kein einziges Passwort im Klartext. Und wenn du keine Software ohne Audit in sensiblen Bereichen einsetzen willst, dann wird es wohl auch nix mit nem Bitwarden Server, egal welcher Implementation, da der Rest ja nicht auditiert wurde.

Ich kenne die Architektur, aber eigentlich ist das gar nicht nötig. Es gibt ein Web-Vault, und die Website wird nicht von irgendeiner Client-Aplikation ausgeliefert sondern kommt vom Server. Ja, die Verschlüsselung findet dann auch clientseitig im Browser statt, so dass das Passwort (wenn korrekt implementiert) nicht an den Server gesendet wird. Aber der Code für die Krypto kommt eben beim Aufruf der Seite aus der Serverkomponente.

Ergänzung (19. März 2021)

Kannst du das nicht auch mit dem offiziellen Server?

Nein, wenn man den offiziellen Server selbst hostet, muss man für Premium-Features, Family-Plan usw. auch zahlen, da muss man dann einen Lizenz-File reinladen. Wäre sonst auch schön blöd, am meisten werden die ja mit Firmen und co. verdienen, das Geld wird man sich durch "dann hosten wir halt selbst" sicher nicht einfach nehmen lassen.

 

[KitKat::new()]

Wäre sonst auch schön blöd, am meisten werden die ja mit Firmen und co. verdienen, das Geld wird man sich durch "dann hosten wir halt selbst" sicher nicht einfach nehmen lassen.

Ich gehe stark davon aus, dass man das mit gemäßigten Aufwand rauspatchen könnte.

 

[foo_1337]

Aber der Code für die Krypto kommt eben beim Aufruf der Seite aus der Serverkomponente.

bitwarden_rs ist nur eine re-implementation der API. Der Code für die Crypto ist der original Bitwarden Code, der nur minimal modifiziert werden musste:
https://github.com/dani-garcia/bw_web_builds/blob/master/patches/v2.19.0.patch

 

[Autokiller677]

Ich gehe stark davon aus, dass man das mit gemäßigten Aufwand rauspatchen könnte.

Natürlich könnte man. Aber dann betreibt man einen Fork und hat halt auch keinen Support mehr und muss bei jedem Update die Changes wieder mergen, Container selber bauen usw... Das wird es für die allermeisten Firmen einfach nicht wert sein.

 

[DiamondDog]

Kommt auf die App an. Nutze Keepass2Android mobil und bei manchen Apps klappt das ausfüllen bzw. wird angeboten. Ich vermute daher, die Username/Password Felder müssen entsprechende Beschreibungen o.ä. haben.

Ja bei Android habe ich damals es auch teils geschafft, aber ich bin nun seit 2016 wieder auf Apple.
Hier habe ich noch keine KeePass Alternative ausprobiert.

Teste mich jetzt etwas in Bitwarden ein... das übertragen der Daten aus LastPass hat schon mal super geklappt.

 

[DiamondDog]

ok... Bitwarden ist nicht derart in IOS integriert wie LastPass... das enttäuscht mich jetzt doch sehr

 

[foo_1337]

Ich habe Lastpass nie genutzt: Was hat Lastpass unter iOS ausgezeichnet?