#weekend Magazin Steiermark mit einem Artikel zu digitalem Frühjahrsputz.
An sich gute Vorschläge paaren sich mit einer Empfehlung, die #Passwörter in der #Cloud zu speichern. 🤦🖕
Leute, es gibt super #Passwortmanager mit lokaler Datenhaltung wie #KeePassXC, die ihr beispielsweise mit #Syncthing selbst zwischen euren Geräten synchronisieren könnt. 👍
@publicvoit Als kleine Ergänzung: Passkeys kann man auch wunderbar auf einem externen Stick speichern (zB 250 auf Google Titan; ca. 20 auf Yubikey). Der wichtigste Cloud-Anbieter hier ist vermutlich 1Password (und nicht MS, Google oder Apple). Und die Sicherheit hier wird ähnlich wie bei KeePassXC mit Synthing sein.
Gegen Google und Apple für Passkeys spricht auch, dass dann ein Umstieg auf andere Systeme schwer wird (keine Google Passkeys in macOS/iOS, keine Apple Keychain auf Win/Android).
@publicvoit Ich dachte du nutzt KeePassXC und Syncthing? Ist das nicht das gleiche? Beides E2E verschlüsselt und nur mit lokalem Passwort zu öffnen etc.
Siehe auch https://1password.com/de/security/. Es gibt viele andere Gründe, die gegen 1Password sprechen - aber Sicherheit ist es imho (bisher) noch nicht.
@laotang Wenn etwas für Sicherheit wichtig ist, muss es FOSS sein und darf unter keiner fremden Kontrolle sein.
1password ist in jeder Beziehung außerhalb dieser Grenze, da du deren proprietären Code und Werbeaussagen 100% vertrauen musst.
Es gab schon ausreichend dokumentierte Incidents, die zeigten, dass deine Daten bei solchen Firmen niemals gut aufgehoben sind. Und Passwörter sind wohl das Wichtigste, das man digital besitzt. Hier sollte es keine Kompromisse geben.
@publicvoit Sobald deine Daten das Netz berühren, egal auf welche Art, gibt es die 100% Sicherheit nicht mehr.
Zwischen 1Password und Lastpass gibt es jedoch riesige Unterschiede (siehe auch externe Zertifizierung, E2E, welche Daten verschlüsselt werden etc). Es gibt mE viele Gründe, die langfristig gegen 1Pwd sprechen, ua auch die Sache mit dem propritärem Code. Aber mir ist lieber jemand nutzt 1Pwd als das gleiche Pwd überall.
FOSS hat leider ebenfalls Einfallstüren, siehe xz Tools.
Wenn das Schlüsselmaterial nachweislich in meiner Hand bleibt (bei PassKeys als auch Closed Source nicht der Fall), kann ich davon ausgehen, dass ein standardisiertes und sorgsam implementiertes Kryptoverfahren meine Geheimnisse schützt.
@laotang Bei Passkeys sieht das Protokoll vor, dass die Geheimnisse nicht nur auf der lokalen Seite liegen (HW/SW ist egal).
Der Serviceprovider vom Passkeys entscheidet, ob er sich die Geheimnisse holt oder nicht. Der Client kann es nicht verhindern. Und die Clients müssen - im Gegensatz zu FIDO2 - auch nicht so gestaltet sein, dass die Geheimnisse gegen Auslesen geschützt werden.
Geht also mehr in die Richtung "Zentralschlüssel liegt unter der Fußmatte" und ich vertraue allen Passanten.
Es basiert auf den selben Protokollen, ja. Allerdings danach gibt's wesentliche Unterschiede wie zB die Aufgabe des Schutzes der Geheimnisse, damit man der Bequemlichkeit der User einen Gefallen tut, die nicht mehr alle ihre Tokens bei allen Services registrieren müssen, sondern das über die Cloud machen lassen.
Deshalb gibt's ja auch zuhauf Passkeys in SW aber kein FIDO2 in SW.
Mit entsprechendem Verlust an Sicherheit, wie schon ausführlich erwähnt.
@publicvoit Ich bin mir nicht sicher, ob ich das System/deine Kritik hier nicht richtig verstehe (oder etwas übersehe).Hast du da einen Link? Bisher habe ich noch keinen Artikel aus seriöser Quelle gesehen, der diese Punkte vertritt.
Aber im Endeffekt scheint es wieder ein Frage des Vertrauens zu sein. Vertraue ich darauf, dass 1Password (oder Apple & Google etc) die private keys E2E verschlüsselt in der cloud hat, oder nicht. Und wenn ich den Passkey local auf einem USB Key speichere, dann kann ich die Problematik umgehen.
@laotang Ja klar, wenn du den Kreis der Parteien, denen du vertraust maximal machst, dann ist alles innerhalb deines Risk Appetite.
Wir haben diesbezüglich offenbar andere Einschätzungen und überlege mir im Gegensatz zu dir sehr genau, wen ich in den Vertrauenskreis hineinnehmen möchte und wen nicht.
Bei Passkeys verstehe ich wenigstens noch, dass man den Verlust an Sicherheit akzeptiert, da Schutz gegen Phishing und Apple/MS/Google möchten diejenigen ohnehin absolut vertrauen, die das nutzen.
@laotang Ad Quellen: meine Blogartikel haben Quellen verlinkt. Da ist eine LV der TU Graz verlinkt und Artikel von Google und heise. Ich weiß nicht, was dein Kommentar meint. 🤷
@laotang Ist ja nicht so, dass das, worüber ich blogge, immer nur auf meinem Mist gewachsen ist. 😆
Da ist schon viel von anderen Menschen dabei, auf deren Arbeit ich aufsetze. Wäre sonst wirklich viel Aufwand für einen Einzelnen. Beruflich habe ich auch etwas damit zu tun aber darüber kann ich halt leider nicht viel schreiben.
@publicvoit Das wollte ich auch nicht unterstellen. Nur war das Argument bisher hauptsächlich ein "trust me" 😉 und Google & Apple & co ist aus Prinzip nicht zu trauen.
Die sind dazu da, Shareholdervalue zu maximieren. Abgesehen von US-Gesetzen, die Industriespionagemöglichkeiten vorschreiben, sind deine Daten im direkten oder abgeleiteten Verkauf massiv viel Geld wert und das wird auch so gelebt. Das ist eine eigene Industrie, die du nicht ignorieren kannst.
Du bist das Produkt. Inzwischen auch, wenn du zahlst.
@laotang Wenn man etwas böse denkt, möchte man meinen, dass das massiv von Geheimdiensten gepusht wird, da man so - ganz legal laut US Gesetzgebung - auch an die Keys der Konsumenten kommt, die bei FIDO2 gut geschützt sind.
Trotzdem: Passkeys ist neben FIDO2 aktuell das einzige Verfahren, das gegen Phishing schützt. FIDO2 ist top aber dann kommt leider schon Passkeys mit entsprechenden Einschränkungen beim Vertrauen.
@laotang Wie man letztens bei LastPass gesehen hat, kann man bei Closed Source keinesfalls darauf vertrauen, dass die Herstellerangaben stimmen, die Cryptoverfahren auch überall und auf alle Daten angewendet werden, dass es keine zusätzlichen Zugriffsmöglichkeiten gibt (Schlüsselschwächung, Backdoors, ...).
Insofern priorisiert man Vertrauen und Bequemlichkeit auf Marketingaussagen über Sicherheit. Wenn das kein Problem ist, brauchen wir auch nicht diskutieren. Ich bin hier wegen anderer Prios.
@publicvoit Was mich stört ist die absolute Gleichsetzung verschiedener Akteure. Ein Unternehmen, welches sich extern Zertifizieren lässt, verschiedene Passwort/Verschlüssungssysteme aktiv mitentwickelt hat (Fido2/Passkeys) mit einer Kascheme, die all dies nicht tut.
Wo wir uns wohl einig sind ist die Sache mit dem Vertrauen. Ich nehme an, dass du dir den Code von KeePassXC oder Synthing selbst nicht angesehen hast? Auch bei FOSS ist es schließlich meistens Vertrauen in andere Akteure.
@laotang Sorry, das klingt in meinen Ohren nach Ausreden. Ich weiß, was Zertifizerungen bedeuten - glaub' mir. 😜
Die Sache mit dem FOSS-Vertrauen ist NICHT, dass ich höchstpersönlich den Code verifizert habe. (Was in dem Fall sogar nur teilweise stimmt, da ich in Umgebungen arbeite, wo sehr wohl Code vorm Einsatz geprüft wird.)
Der Punkt ist, dass unabhängige Experten, denen ich vertauen kann (oder nicht) den Code für mich mitprüfen.
Nur setze ich höheres Verrtauen in unabhängige Sicherheitsexperten im Vergleich zu kommerziellen Firmen, die fast immer lügen. Über Marketing und Sicherheitsvorfälle muss ich dir ja nix sagen.
Für mich ist das Ungleichgewicht hier extrem offensichtlich.
@laotang FOSS kann Einfallstüren haben. FOSS ist kein Garant für Sicherheit. Es ist aber gleichzeitig notwendige Voraussetzung für Sicherheit, denn bei Closed Source kann bei jeder neuen Version etwas gänzlich anderes drinnenstecken und niemand Unabhängiger kann es prüfen. Bei FOSS kann jede(r) prüfen.
Insofern ist Closed Source niemals zu trauen. FOSS nach Kontrolle und Nachvollziehen des Deployments.
@publicvoit Ich hatte früher auch mal eine KeePass-Datenbank per Syncthing verwendet, aber das hat nicht zuverlässig funktioniert, es kam sogar zu einem Lost-Update-Datenverlust.
Daher bin ich inzwischen auf den iCloud-Schlüsselbund umgestiegen. Ich muss Apple ohnehin vertrauen, sonst könnte ich nicht deren Geräte benutzen.
Add comment