Keine Ahnung, ob es mittlerweile geschlossen ist. Allerdings begegne ich Proton als Firma mit großer Skepsis. Nicht nur, dass man von der einen Abhängigkeit (große US-Techfirmen) in die nächste Abhängigkeit (Proton) rutscht, sondern das gesamte Geschäftsmodell ist so sehr BWL-Like, dass ich da ein ungutes Gefühl habe. Dahinter steckt sehr viel Marketing. Und einiges ist einfach nicht korrekt, was sie sagen, insbesondere auf die Konkurrenz. Wenn man ein gutes Produkt hat, braucht man kein aggressives Marketing. Die Liste, was mir daran missfällt, könnte ich hier noch weiter ausführen, aber das ist ja nicht Thema.
Ich würde an deiner Stelle dir also zu Bitwarden raten.
Wobei ich selbst 1Password nutze, aber zunehmend unzufriedener werde. Stichwort: Enshittification.
Allerdings bietet es bspw. auf macOS und iOS bisher die beste Erfahrung und hat einige „Quality-of-life features“.
Das Marketing von Proton finde ich aber auch nicht immer gut. Gerade bei ProtonMail schmeißen sie sehr viel mit dem Wort „Verschlüsselung“ um sich, obwohl die allermeisten mit ProtonMail gesendeten E-Mails nicht Ende-zu-Ende-verschlüsselt sein dürften. Auch der Schweizer Datenschutz ist so ein bisschen ein Ammenmärchen.
Zurück zu On-Topic - nach Kenntnisnahme dieses Artikels des bekannten Sicherheitsforschers Tavis Ormandy habe ich mich dazu entschlossen, den Passwortmanager im Browser zu nutzen:
Warum? Die Verwendung von Browser-Plugins für Passwortmanager finde ich tatsächlich eine sehr ungute Kombination, egal von wem sie kommen. Ständig manuell reinkopieren ist mir aber auch zu blöde. Und Lösungen, die für den Enterprise-Sektor als ausreichend sicher gelten, langen mir allemal.
Danke für den Link! Leider ist das ein bisschen wie die Wahl zwischen Pest und Cholera (Sicherheit und Datenschutz). Loggt man sich zur Synchronisierung der Passwörter bei den ersten beiden Browsern dauerhaft ein, die Ormandy nennt (Chrome und Edge), wird man dauerhaft ausspioniert. Loggt man sich beim dritten in der Reihe ein (Firefox Sync), riskiert man unter Android neue Sicherheitsprobleme, wenn das, was Mike dazu geschrieben hat, noch aktuell ist.
Klar sind Browser-Addons nicht gut darin, Prozesse voneinander zu isolieren. Autotype und Copy-Paste sind in der Hinsicht aber auch nicht besser. Bin zwar kein Linux-Kenner, aber Wayland mit seinem verbesserten Rechtemanagement schließt Autotype AFAIK konzeptuell aus, so dass z.B. für KeePassXC nur noch das Browser-Addon übrig bleibt. Trotz des von Ormandy beschriebenen (großen?) Restrisikos empfiehlt zumindest die XC-Doku das Addon als zuverlässiger gegenüber Autotype. Eine zuverlässige Erkennung der Login-URL ist auch als Phishing-Schutz wichtig, damit man am Ende nicht mit CTRL-V Passwörter irgendwo einfügt, wo sie nicht hingehören. Kann gut sein, dass in dieser Hinsicht der browsereigene Manager tatsächlich besser wäre.
Najaaa, nicht unbedingt. Man kann Web- und App-Aktivitäten im Google-Konto deaktivieren, oder zumindest den Chrome-Verlauf nicht mit einschließen (so hab ich das konfiguriert). Den Inkognito-Modus hat man als Option auch noch. Ob das so viele Leute machen ist ne andere Frage, aber man ist auch mit Chrome nicht komplett ausgeliefert, sondern kriegt das einigermaßen unter Kontrolle. Und für die Passwörter kann man die on-device-Verschlüsselung aktivieren, so hat Google auch keinen Zugriff darauf.
Soll jetzt aber nicht Werbung für meine Lösung sein, nur eine Erklärung, wie man’s auch machen kann.
Den Punkt hier finde ich tatsächlich sehr wichtig, ich kenne einige Leute, die das mal in letzter Sekunde gerettet hat.
Danke für Euer Feeback und Eure Meinungen. So wie ich es herauslesen kann, sollte man grundsätzlich auf die „autofill“ Funktion der Passwort Manager verzichten und der Sicherheit wegen lieber die Zugangsdaten mittels Copy & Paste einfügen
Also für mich ist es das genaue Gegenteil. Wenn der Passwortmanager anhand der URL korrekte von falschen Loginseiten unterscheidet, ist man signifikant weniger anfällig für Phishing. So hatte nick das auch geschrieben.
Wo hat Mike das denn geschrieben bzw. dass er den Firefox für Android NICHT empfiehlt? Ich meine, dass er den Firefox immer noch für Android empfiehlt. Somit werden die Dinge, die im direkten Vergleich zu Brave sind (den er ja auch für Android empfiehlt) schlechter sind, nicht so schlecht oder gravierend sein, da er sonst den Firefox für Android nicht empfehlen würde.
Chrome-basierte Browser haben (unter Android) derzeit einen Sicherheitsvorsprung gegenüber den Gecko-basierten Browsern, dank Funktionen wie der Partial-Site-Isolation (auch Per-Site-Process-Isolation genannt). Dieser Sicherheitsmechanismus kann es einer bösartigen Website erschweren, Daten (bspw. Authentifizierungs-Cookies) von anderen Websites zu stehlen. Das ist ein starkes Argument – so stark, dass es sich lohnt, Chrome-basierte Browser auf Android zu bevorzugen.
Und wo steht da, dass Mike den Firefox für Android nicht empfiehlt?
Etwas anderes zu bevorzugen beutet nicht, dass die andere Alternative automatisch abgelehnt wird oder nicht empfohlen wird.
Und wenn man in den Blog guckt, wird man folgendes finden:
Aus der Sicht des Datenschutzes ist Firefox – auch wenn die Standardeinstellungen in dieser Hinsicht nicht optimal sind – derzeit die beste Wahl. Nach Anpassungen in der Konfiguration würde ich Firefox als datenschutzfreundlich bezeichnen. Nachholbedarf hat Mozilla bei der Sicherheit, insbesondere unter Android (bspw. fehlendes Fission).
Er sagt also, dass Brave hierbei besser ist, aber rät nicht vom Firefox ab oder warnt gar davor. Auch würde er sonst den Firefox in diesem Artikel bzw. der Artikel-Serie nicht aufführen.
Aber wir können ihn ja direkt fragen: @kuketzblog Rätst du vom Firefox auf Android explizit ab?
Nirgendwo – da hast Du recht. „Nicht empfehlen“ und „explizit abraten“ war Deine Wortwahl, nicht meine. Meine war schlicht „Sicherheitsprobleme riskieren“.
Habe Proton via E-Mail kontaktiert und folgende Antwort habe ich als Feedback erhalten:
Fragen Sie, ob Pass-Daten unverschlüsselt im Arbeitsspeicher gefunden werden können?
Alle Passwortmanager speichern Daten unverschlüsselt im Arbeitsspeicher. Sie können die Daten im Speicher nicht verschlüsseln, da die Anwendung sie dann während der Ausführung nicht verwenden kann. Dies ist ein allgemeines Problem bei Passwortmanagern und lässt sich nicht beheben.
Wenn Sie die PIN-Sperre aktivieren, werden die Daten lokal verschlüsselt und beim Aktivieren der PIN-Sperre aus dem Speicher gelöscht. In früheren Versionen von Proton Pass konnte es nach der PIN-Sperre bis zu 30 Minuten dauern, bis die Daten aus dem Speicher gelöscht wurden. In der neuen Version werden sie sofort gelöscht. Zuvor dauerte es sofort, aber eine Code-Regression setzte dies auf bis zu 30 Minuten zurück. Dies wurde nun behoben.
Um dies überhaupt nutzen zu können, müsste jemand Zugriff auf das Gerät und den Gerätespeicher haben. In diesem Fall ist die PIN wirkungslos, da das Gerät bereits kompromittiert ist. Leider kann Proton Pass (oder ein anderer Passwort-Manager) diese Art der Gerätekompromittierung nicht verhindern.
Kind regards,
Jovan
Customer Support
Proton Mail
@kuketzblog hast du dich mit dem Thema seit deinem Blogeintrag generell beschäftigt?
Ein Verordnungsentwurf in der Schweiz sieht vor, dass User aller größeren Plattformen eine Ausweis- oder Führerscheinkopie oder eine Telefonnummer vorlegen.
Der Entwurf wurde meiner Erinnerung nach gemäß jüngsten Informationen mittlerweile von den dortigen großen politischen Parteien abgelehnt. Im Auge behalten sollte man die Destination natürlich dennoch
Die Aussage ist bezogen auf Passwortmanager gleichen Typs sicherlich richtig, ist aber m.E.n. nicht allgemeingültig für Passwortmanager.
Beim Passwortmanager pass (https://www.passwordstore.org/) z.B. sind zu keiner Zeit alle Passwörter entschlüsselt im Speicher.
Nein. Copy & Paste ist definitiv keine gute Idee. Höheres Risiko auf Phishing hereinzufallen und von anderen Programmen einsehbares Clipboard. Autofill sollte aber so eingestellt sein, dass es nur nach Nutzeraktion ausfüllt.
Einen Browser der auf Android 10 Jahre hinter den Sicherheitsfeatures von Chromium ist, würde ich jedenfalls nicht verwenden. Die genannte Site Isolation ist ja nur ein Teil des Problems.