News Google Authenticator: Passwort-Synchronisation überträgt Daten im Klartext

Fegr8 schrieb:
Naja das Update wird in Wellen verteilt. Ich habe es noch nicht erhalten, aber wenn ich so in den Foren lese wir nach dem Update gefragt ob du es Snchronisieren möchtest und da kann man es verneinen und es bleibt deaktiviert. Und vermutlich gibt es dann bei den Einstellungen ein zusätzlichen Punkt.

Ah ok. Dann gab es das Update bei mir wohl noch nicht.
 
WoFNuLL schrieb:
Wenn ich ein Backup meiner Auth Codes machen will, generiert mir das Teil einen QR Code, welchen ich aus mir NICHT NACHVOLLZIEHBAREN GRÜNDEN! nicht Screenshotten kann
Die Gründe sind schon nachvollziehbar. Es soll Phising Attacken erschweren - wo man Leute dazu bringt, den QR Code an eine dritte Person zu senden. Es gibt leider sehr viele Enduser, die auf so etwas hereinfallen. Wenn Du technisch noch so affine/versierte Familienmitglieder hast, erlebst Du das leider regelmäßig.
Du musst immer bedenken, die Mehrheit der Nutzer hat viel weniger Ahnung von Sicherheit als Du.

Lord Horu$ schrieb:
Es is ja auch nicht eine kreuzdämliche Idee seine PASSWÖRTER in der der Cloud zu speichern...
Wenn Sie ausreichend verschlüsselt sind, kannst Du sie offen im Internet ablegen.
Und die Cloud beginnt auf Deinem PC oder Smartphone sobald es mit dem Internet verbunden ist. Ich verstehe immer nicht, das Leute glauben ihre privaten Geräte sind nicht Bestandteilt der Cloud und sicherer als die Außenwelt.

machiavelli1986 schrieb:
Trotzdem würde ich deshalb niemals auf eine 2FA verzichten. Und ja, einloggen wird mühsamer mit 2FA, aber was solls?
Das ist genau der Punkt. 2FA bringt einen erheblichen Sicherheitsgewinn. Problem ist allerdings auch, dass man das Risiko steigert, sich selbst auszusperren. Wenn man 2FA für einen Dienst einrichtet, sollte man sich unmittelbar und sofort damit auseinandersetze, wie das Recovery geht, und z.B. Recovery Codes sicher abspeichern oder sicherstellen das die Telefonnummern für Verifizierungs-SMS aktuell sind, usw.

Ein Backup des Seed zu machen, ist immer eine Kompromiss bzgl. Sicherheit, aber man muss immer abwägen was wichtiger ist:
  • Sicherstellen das immer Zugriff auf die geschützte Konto möglich ist
  • Höchstmögliche Maß an Schutz vor Zugriff Dritter auf das Konto
Für einen Studenten kann z.B. der Verlust des Zugriffs auf das Online Konto der Hochschule bedeuten, dass Termin gebundene Abgaben oder Anmeldungen nicht mehr möglich sind (hatte gerade so einen Fall im privaten Umfeld, 2FA Recovery ging nur durch persönliches Erscheinen beim IT Helpdesk, blöd wenn man gerade 500km von der Hochschule entfernt auf Heimatbesuch ist...)

Man kann das Backup der Seeds definitiv besser implementieren als Google das nun gemacht hat.
Insofern ist die Empfehlung von Heise schon richtig, allerdings sollten Authenticator Anwender auch nicht in Panik geraten und sicherstellen, dass sie sich beim Reset der OTP nicht aussperren.

Bigeagle schrieb:
Google kann also sehen wo ihre Kunden Accounts haben und bei Bedarf Sicherheitsbehörden auch gleich noch das Passwort dazu liefern? Praktisch ...
Das Passwort nicht, sondern den OTP Seed - theoretisch. Um die Vorlieben seiner Kunden (also Leute mit Google Account) zu kennen, braucht Google aber sicher nicht die Metadaten des Authenticators, da haben die bessere Infos (z.B. Browserverlauf)
eSportWarrior schrieb:
Schwachstelle ok egal, aber absichtlich eine Schwachstelle?!?
Wenn die Stellungnahme von Google nicht eine nachträglich hinterhergeschobene Rechtfertigung war, würde ich sagen keine Schwachstelle, sondern bewusste Designentscheidung.
Ich kann mir nicht vorstellen, das Google nicht eine Risikobewertung gemacht hat, und die Schwächen der Implementierung kennt.
Ich würde es eher als "Kommunikationspanne" bezeichnen. Denn eigentlich muss Google klar sein, das eine so relevante Software wie der Google Authenticator sofort untersucht und diese Schwäche sofort gefunden und veröffentlich wird.

So blöd können die eigentlich nicht sein....
 
  • Gefällt mir
Reaktionen: Bigeagle, DNS81 und rosenholz
Nilson schrieb:
Die fehlende Synchonisation/Backup-Funktion war ein Ausschlusskriterium für mich.
Es besteht schon lange die Möglichkeit, einen QR Code in der App zu erzeugen, den Du dann auf dem neuen Gerät scannen kannst, der dann die Daten überträgt. Meines Wissens nach ist das eine reine Offline-Funktion.

Persönlich habe ich ohnehin alle QR Codes für alle 2FA Dienste "old-school" ausgedruckt und sicher verwahrt mit anderen wichtigen Dokumenten.
 
dem Laden trau ich keinen Zentimeter über den Weg , hier und überhaupt sowieso ist der Gute alte Zettel die bessere Alternative
 
  • Gefällt mir
Reaktionen: der Unzensierte
Google macht Werbung und sammelt eure Daten. Der Rest ist lediglich Beiwerk und hält die Nutzer bei Laune.
 
machiavelli1986 schrieb:
Meine Passwörter habe ich alle lokal gespeichert in einer KeyPass Datei. Für den 2FA nutze ich Google. Was gibt es für sinnvolle Varianten wo man dann wirklich sagen kann, dass ist besser und vertrauenswürdiger?
Ich habe TOTP ebenfalls in KeepassXC eingerichtet, da spare ich mir irgendwelche Äpps. Es mag sinnfrei erscheinen, Passwort und OTP am selben Ort zu haben. Aber ich erachte mein Keepass als hinreichend sicher: die Home-Partition ist mit langer Passphrase LUKS-verschlüsselt, die Datenbank selbst hat nochmal eine andere Passphrase und meine Backup-Festplatten haben nochmal eine andere, lange LUKS-Passphrase.
 
Plonktroll schrieb:
dem Laden trau ich keinen Zentimeter über den Weg , hier und überhaupt sowieso ist der Gute alte Zettel die bessere Alternative

Dann mach das mal mit Hunderten Accounts, viel Spaß. Solche Lösungen verleiten nur dazu, dasselbe Passwort zigfach zu verwenden und das ist ein viel größeres Problem, als mit AES-256 verschlüsselte Dateien in der Cloud aus einem Passwort-Manager.
 
Könnte mir mal jemand erkläre wofür diese Synchronisation eigentlich gut ist? Ich habe den Google Authenticator schon ewig auf zwei Smartphones und einem Tablet und alle zeigen die gleichen Einmalcodes für meine Websites/Dienste an. Da die Sync-Funktion ja wohl neu, habe ich sie ja offensichtlich bisher gar nicht genutzt. Wozu braucht es denn dann überhaupt irgendeine Synchronisation?
 
Donnerkind schrieb:
Ich habe TOTP ebenfalls in KeepassXC eingerichtet, da spare ich mir irgendwelche Äpps.
Da ich als iPhone Nutzer schon länger strongbox nutze, nutze ich seit kurzem die 2fa Funktion von strongbox/keepass.

Lässt sich so einfach dediziert sichern.
Bin nur am überlegen ob ich die 2fa Einträge in eine eigene keepass Datenbank Speicher und dessen Passwort im der regulären DB.

Ob es da nen Sicherheitsgewinn gibt ? Ich mein wenn jemand wirklich mein PW erraten/oder sonst wie beschaffen kann, ist das eh hinfällig..Das dürfte dann eher nicht in der DB sein xD
 
Macht Microsoft es genauso?
 
Ich gehe einfach davon aus das alle Daten die man PC, Smartphone etc. anvertraut kompromittiert sind. Der sicherste Passwort - Manager ist und bleibt ein Blatt Papier - Vervielfältigung egal welcher Art (Kopieren, Drucken (@MaverickM) und Fotografieren) verboten. Und wer hunderte Accounts hat hat die Kontrolle über sein Leben verloren.
 
Ich kann nicht glauben, dass das ein Versehen wer.
Da tippe ich doch eher auf den Einfluss von einer Dreibuchstaben-Organisation.
 
Gibt ja noch andere Programme und Keepass mit einer Datei als zweiter Faktor ist ebenfalls sicher...
 
Die Überschrift ist schon arg fehlleitend. Die Daten sind sowohl in Transit, als auch at Rest verschlüsselt. Nichts wird per Definition im Klartext übertragen, wenn der Transport Layer verschlüsselt ist.
Das eigentliche Problem ist, dass die Daten nicht durch einen User-Key verschlüsselt sind, der nur auf dem Client existiert. Somit hat Google Zugriff auf die Daten. Der ganze Rest ist Click-Bait.
Für eine MITM-Attacke müsste der Angreifer ein fake Zertifikat ausstellen. Da der Authenticator SSL-Pinning nutzt, ist dieser Angriffsvektor praktisch ausgeschlossen.
 
  • Gefällt mir
Reaktionen: SSD960, Seven2758, piepenkorn und eine weitere Person
Euphoria schrieb:
Oh Mann was für Anfänger arbeiten denn bei Google?
Genau deswegen vertraue ich keinem Onlinedienst wenn es um Passwörter/MFA geht (im Sinne von Speicherung/Backup)

Alles nur lokal in eigener Keepass Datenbank.
Halte ich für mindestens genauso fahrlässig. Ein Zettel mit allen Passwörtern in der Schublade ist da genauso sicher. "Generation Digital" hat leider keinerlei Bewusstsein mehr was "digital" bedeutet. Einmal auf dem Computer oder Handy - und es ist potentiell überall.

Für dein Passwort in der Schublade muss zumindest jemand persönlich zu dir ins Zimmer und an deinen Schreibtisch gehen statt es bequem aus Timbuktu per Skript von deinem Desktop zu fischen.
 
Authy ist komfortabel, es gibt aber gute Gründe, einen Bogen um die Firma zu machen.
 
Falc410 schrieb:
Ich frag mich halt immer wie sinnvoll es ist, beide Faktoren (TOTP und Passwort) im selben Passwortmanager zu speichern.
Sehe ich jetzt weniger kritisch, denn zum Entsperren der Datenbank von Bitwarden brauchst du ja immer noch ein Passwort (und 2FA lässt sich zusätzlich auch noch einstellen, sodass du zusätzlich ein TOTP brauchst). Heißt also, wenn man ganz viel Angst hat, kann man die Datenbank sich automatisch schließen lassen, wenn man sie für ein Passwort und TOTP gebraucht hat. Wenn man dann wieder ein Passwort und TOTP aus der Datenbank abrufen will, muss man erst wieder das Master-Passwort eingeben und hinterher das TOTP für Bitwarden. Für dieses TOTP musst du dann sowieso zu einem anderen Gerät greifen.
Von dem her macht es das nur bequemer, an das TOTP aus dem Eintrag in Bitwarden ranzukommen. Man musste ja sowieso schon zu einem anderen Gerät greifen, um die Datenbank entsperren zu können, da man das TOTP für Bitwarden brauchte. So muss man nicht noch ein zweites Mal zu einem anderen Gerät greifen, auf dem man sowieso schon Zugriff auf die TOTPs hat, da man da schon das TOTP für Bitwarden abrufen musste.
 
Zurück
Oben