Microsoft-Authenticator-Fehler überschreibt MFA-Konten und sperrt Nutzer aus

 (csoonline.com)
2 Punkte von GN⁺ 2024-08-18 | 1 Kommentare | Auf WhatsApp teilen
  • Angesichts der zunehmenden Nutzung von MFA kann Microsoft Authenticator Nutzer aussperren, weil neue per QR-Code hinzugefügte TOTP-Konten bestehende Konten überschreiben
  • Der Kern der Kollision liegt in einem Design, das zur Kontounterscheidung nur das Label verwendet, statt wie Google Authenticator, Okta und andere Issuer und Label gemeinsam zu nutzen
  • Da das Überschreiben nicht sofort auffällt, erleben Nutzer möglicherweise erst Wochen oder Monate später beim Zugriff auf das bestehende Konto, dass der Zugriff nicht möglich ist
  • Workarounds sind die Nutzung einer anderen Authenticator-App oder die manuelle Eingabe des Secret Key, sind für normale Nutzer in Unternehmensumgebungen aber wenig praktikabel
  • Microsoft erklärt, es handle sich um beabsichtigtes Verhalten und es werde eine Warnmeldung angezeigt; später verwies das Unternehmen auf fehlende Issuer bei einigen Ausstellern und ließ lediglich die Möglichkeit künftiger Verbesserungen offen

Wie ein QR-Scan bestehende MFA-Konten überschreibt

  • Microsoft Authenticator kann beim Hinzufügen eines neuen Kontos per QR-Scan ein bestehendes Konto mit demselben Nutzernamen überschreiben
  • Da häufig E-Mail-Adressen als Nutzernamen verwendet werden, teilen sich MFA-Konten mehrerer Dienste oft dasselbe Label
  • Google Authenticator und die meisten anderen Authenticator-Apps vermeiden Kollisionen, indem sie zusätzlich den Issuer-Namen verwenden, etwa den Namen einer Bank oder eines Autoherstellers
  • Microsoft Authenticator verwendet den Issuer nicht mit und identifiziert Konten nur anhand des Nutzernamens
  • Nach dem Überschreiben können sowohl beim neu erstellten Konto als auch beim überschriebenen bestehenden Konto Authentifizierungsprobleme auftreten

Schwer nachvollziehbare Aussperrung

  • Wenn eine Aussperrung auftritt, können Nutzer fälschlicherweise annehmen, das Problem liege beim Unternehmen, das die Authentifizierung bereitstellt, statt bei Microsoft Authenticator
  • In der Folge müssen Unternehmens-Helpdesks Zeit darauf verwenden, ein Problem zu lösen, das sie nicht selbst verursacht haben
  • Es ist schwer, einfach festzustellen, welches Konto überschrieben wurde
  • Dass ein bestehendes Konto verschwunden ist, fällt möglicherweise erst auf, wenn der Nutzer dieses Konto wieder verwenden will
    • Das kann Wochen oder Monate später sein

Workarounds und langjährige Beschwerden

  • Der einfachste Workaround besteht darin, statt Microsoft Authenticator eine andere Authenticator-App zu verwenden
  • Wer den QR-Code-Scan nicht nutzt und den Secret Key manuell eingibt, kann das Problem vermeiden
  • Bei Authenticator-Konten, die zu Microsoft-Konten gehören, scheint dieses Problem nicht aufzutreten
  • CSO Online konnte Beschwerden zu diesem Problem bis ins Jahr 2020 zurückverfolgen; das Problem selbst scheint seit der Veröffentlichung von Microsoft Authenticator im Juni 2016 zu bestehen
  • 2020 erwähnte ein Nutzer den Workaround, den Secret Key des Identity Providers manuell einzugeben, sah es aber nicht als hilfreich an, wenn durchschnittliche Endnutzer in Unternehmen mit zufälligen Zeichenketten umgehen müssen

Im Feld reproduziertes Überschreiben

  • Der australische IT-Berater Brett Randall erlebte in einer Vendor-Schulung, dass Teilnehmer beim Scannen von MFA-QR-Codes mit Microsoft Authenticator TOTP-Keys anderer Anwendungen überschrieben
  • Laut Randall erzeugen MFA-QR-Codes eine Zeichenkette mit mehreren Werten, und andere Apps kombinieren Label und Issuer, um eine eindeutige ID für den jeweiligen Key zu erstellen
  • Microsoft Authenticator verwendet statt dieses standardmäßigen Verhaltens nur das Label, das normalerweise eine E-Mail-Adresse ist
  • Der letzte TOTP-Key, der dieselbe E-Mail-Adresse verwendet, kann durch den neuen Key überschrieben werden
  • Randall beschrieb es als nahezu unmöglich, Microsoft dazu zu bringen, dieses Problem wahrzunehmen und Maßnahmen zu ergreifen

Reaktionen von Sicherheits- und IT-Experten

  • CSO Online bat mehrere Sicherheits- und IT-Experten, das Problem zu reproduzieren; allen gelang dies
  • Gary Longsine, fractional CTO von IllumineX, sieht darin einen Designfehler und sagte, er werde Microsoft Authenticator nicht empfehlen
  • Tim Erlin, VP of Product bei Wallarm, sagte, dass beim Hinzufügen eines zweiten Eintrags mit derselben E-Mail-Adresse eine Kollision entstehe und nach dem Überschreiben nicht erkennbar sei, welches Konto überschrieben wurde
  • Erlin merkte an, dass Nutzer die Ursache möglicherweise nicht kennen, weshalb das Problem weniger bekannt sein könnte, als es tatsächlich ist
  • David Meltzer, Chief Product Officer von Netography, reproduzierte das Verhalten selbst und hält es für einen klaren Bug sowie für ein Problem, das Microsoft vergleichsweise einfach beheben könnte
  • Google-Sprecherin Kimberly Samra erklärte, Google Authenticator überschreibe keine Codes, und dies sei eine bewusste Entscheidung

Microsofts Position und Warnhinweis

  • Microsoft bestätigte das Problem, erklärte aber, es sei kein Bug, sondern beabsichtigtes Verhalten
  • In der ersten schriftlichen Stellungnahme hieß es, Nutzer erhielten eine Bestätigungsmeldung, bevor sie durch das Scannen eines QR-Codes Kontoeinstellungen überschreiben könnten
  • Der tatsächliche Warnhinweis lautet: “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
  • Dieser Hinweis sagt Nutzern, sie sollten fortfahren, wenn sie die Aktion selbst gestartet haben und die Quelle vertrauenswürdig ist
    • Wenn Nutzer den QR-Scan selbst bei einem legitimen Dienst wie einer Bank oder einem Hotel starten, sind beide Bedingungen in der Regel erfüllt
    • Wer der Anweisung folgt, kann damit ein Konto überschreiben
  • Das Warnfenster bietet keine Möglichkeit, das Überschreiben zu vermeiden, außer den Authentifizierungsversuch abzubrechen

Streit um fehlende Issuer

  • In einer späteren, längeren zweiten Stellungnahme erklärte Microsoft, einige Websites oder Anbieter nähmen den Issuer, also den Namen der Website oder des Identity Providers, nicht in das Label auf
  • Wenn bereits ein bestehendes Konto mit demselben Label vorhanden ist, kann die App versuchen, das bestehende Konto mit dem neu gescannten TOTP-Konto zu überschreiben
  • Microsoft erklärte, Nutzer erhielten in solchen Situationen immer eine Bestätigungsmeldung zum Überschreiben und könnten entscheiden, ob sie fortfahren
  • Der Satz „Wir verbessern das Produkt kontinuierlich und werden dies bei künftigen Verbesserungen berücksichtigen“ war der einzige Teil, der andeutete, dass Microsoft das Problem möglicherweise beheben könnte

Vergleich mit anderen Authenticator-Apps

  • Randall sieht zwei Möglichkeiten, zu verhindern, dass Endnutzer versehentlich Keys anderer Apps überschreiben
    • Das otpauth aller Anwendungen auditieren und jedes Unternehmen davon überzeugen, seine fehlerhaften Implementierungen zu korrigieren
    • Microsoft nimmt einmalig eine Änderung vor, sodass man sich künftig keine Sorgen mehr darüber machen muss
  • Randall sagte, er habe dasselbe Kollisionsverhalten in 14 anderen Authenticator-Apps getestet, aber keine habe sich wie Microsoft Authenticator verhalten
  • Zu den getesteten Apps gehörten Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth und Authenticator 2FA Sentinel

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-18
Hacker-News-Kommentare

  • Ein kleines Beispiel, das sehr anschaulich das große Problem von Sicherheit ohne Nutzbarkeit zeigt
    Man muss nur an all den absurden Dingen denken, die man im Namen der „Sicherheit“ ertragen muss: erzwungene regelmäßige Passwortwechsel, irrsinnige Passwortregeln, undokumentierte Anforderungen, die man nur per Trial-and-Error herausfindet, komplizierte Fehlermeldungen voller Sicherheitsjargon oder „Sicherheitsfragen“, deren Antworten man sich nicht merken kann
    Gleichzeitig sind genau diese Systeme selbst sicherheitstechnisch oft löchrig wie ein Sieb. Datenlecks und Informationsabflüsse sind fast täglich in den Nachrichten, und ich frage mich oft, wie das immer wieder durchgeht

    • Capital One hat irgendwann „Benutzernamen“ eingeführt und damit den Login per E-Mail-Adresse kaputtgemacht, ohne das zu dokumentieren und ohne zu verhindern, dass man als Benutzernamen eine E-Mail-Adresse verwendet
      Über Monate musste ich bei jedem Login „Konto finden“ nutzen und habe den Benutzernamen jedes Mal wieder auf meine E-Mail-Adresse gesetzt. Das war nur natürlich, weil das fast 10 Jahre lang meine Anmeldedaten gewesen waren
      Die Einschränkung, dass man im Benutzernamen kein @ oder . verwenden darf, wurde nie erzwungen, bis man sich tatsächlich einloggen wollte, und erst Monate später wurde mir klar, dass ich einen anderen Wert setzen musste
      Das ursprüngliche Konto war ING Direct, dann Capital One 360, bevor es vollständig in den restlichen Capital-One-Zirkus integriert wurde, und ich vermute, dass dieses Problem mit dem Benutzernamen damit zusammenhängt
    • Ich hatte gestern ein gutes Beispiel dafür
      Website: „Bitte wählen Sie ein komplexes Passwort mit mindestens 8 Zeichen, einschließlich Sonderzeichen und Zahlen“
      Ich öffne den Passwort-Manager und erzeugte selbstzufrieden ein zufälliges Passwort mit 128 Zeichen
      Beim nächsten Besuch dann die Website: „Bitte geben Sie das 31., 98. und 102. Zeichen Ihres Passworts ein“
      Das war eine britische Hypotheken-Website
      Wenn ich jetzt darüber nachdenke, heißt das wohl, dass sie das Passwort im Klartext speichern oder es zumindest verschlüsseln statt hashen, damit es jederzeit wieder entschlüsselt werden kann
    • Ich hasse besonders dieses Muster: Man weiß, dass man auf einer Website, die man länger nicht benutzt hat, ein Konto hat, geht hin, gibt die korrekte, algorithmisch aus E-Mail und Site-URL erzeugte Passwortvariante ein, und es schlägt fehl
      Dann probiert man es noch einmal mit der früheren Version des Algorithmus, falls das Passwort damit erzeugt wurde, und es schlägt wieder fehl. Also klickt man am Ende auf Passwort zurücksetzen, holt die E-Mail, klickt auf den Link und trägt das algorithmisch erzeugte Passwort als neues Passwort ein, worauf dann kommt: „Dieses Sonderzeichen ist nicht erlaubt“
      Ersetzt man dieses Sonderzeichen nach der eigenen Regel durch das nächste Zeichen, kommt stattdessen: „Mit dem aktuellen Passwort kann nicht zurückgesetzt werden“
    • Das Schlimmste, das ich bisher gesehen habe, war https://studentaid.gov/. Ich wollte dort keine falschen Angaben eintragen, und ich konnte auch kein zweites Konto anlegen, um die Anforderungen noch einmal nachzusehen
      Soweit ich mich erinnere, gab es „keine Wörter“, „keine Wiederverwendung der letzten 24 Passwörter“, „bestimmte Sonderzeichen ausgeschlossen“, „5 Sicherheitsfragen“ und diverse weitere Passwortanforderungen
      Ob bei den Sicherheitsfragen Groß- und Kleinschreibung beachtet wird, weiß niemand
      Es stand sogar dabei, dass man bestätigen müsse, dass die Informationen zur Kontoerstellung wahr und korrekt seien, und dass falsche oder irreführende Angaben mit Geldstrafe oder Gefängnis oder beidem geahndet werden könnten
    • Die gute Nachricht ist: Alles Aufgezählte gilt unter Leuten, die Endnutzer und Sicherheit verstehen, als schlechte Idee. Leider gehört der Großteil der Menschen, die Sicherheitsrichtlinien umsetzen, nicht dazu
      Mit vier oder mehr Wörterbuchwörtern bekommt man eine hervorragende Passwortsicherheit, und dieselbe Methode kann man auch für Antworten auf Sicherheitsfragen verwenden. Es gibt viele kostenlose und kostenpflichtige Passwort-Manager, die das Problem lösen, sich all diese Geheimnisse merken zu müssen. Auch für Backups von Geheimnissen der Zwei-Faktor-Authentifizierung sind sie gut
      Wenn mit „komplizierten Fehlermeldungen“ Fehler gemeint sind, die der Nutzer selbst beheben soll, könnte man stattdessen lieber eine allgemeine Fehlermeldung plus eindeutige ID zurückgeben und auf den Support verweisen. Jargon-Bombardement ist nervig, wirkt hier aber eher wie gewöhnliche menschliche Unfähigkeit, Fehler zu erklären, als wie ein speziell sicherheitstypisches Problem
      Die meisten Organisationen machen gleichzeitig sehr viele Dinge falsch, selbst wenn das Geschäft insgesamt erfolgreich ist, und Sicherheit ist nur eines davon. In einer ausreichend großen Organisation lässt es sich wohl kaum vermeiden, dass unfähige Leute unfähige Dinge tun

  • Das ergibt auf mehreren Ebenen keinen Sinn. Bedeutet das, dass Microsoft Authenticator Einträge nur anhand des Labels speichert? Legt es nicht einmal so etwas wie einen internen Schlüssel an?
    Und dann soll das Problem angeblich sein, dass die Website den Aussteller in das Label schreibt statt in das dafür vorgesehene issuer-Feld?
    Ich frage mich, ob bei Microsoft überhaupt irgendjemand den eigenen Authenticator tatsächlich benutzt. Wenn ich nicht irgendetwas übersehe, wäre er für fast jede Anwendung unbrauchbar, weil man in dem Moment, in dem man dieselbe E-Mail-Adresse auf einer Website verwendet, sie auf einer anderen nicht mehr hinzufügen könnte

    • Ähnlich dazu hat der Suchgigant Google Google Authenticator für Android ohne Suchleiste veröffentlicht und sie trotz mehrerer Feature-Requests absichtlich weiterhin nicht eingebaut
      In der iOS-Version gibt es jedoch eine Suchleiste. Warum, ist mir völlig unklar
      Irgendwo im riesigen Piper-Repository müsste es doch längst eine lokale Suchbibliothek geben, die sich mit einer einzigen Changelist einbauen ließe, auch wenn das kein großes Sprachmodell ist
    • Dem Artikel zufolge meinte Microsoft, dass man es nicht beheben werde, weil es ein kostenloses Produkt sei und keinen Umsatz generiere
    • Falls Microsoft-Mitarbeiter ihren eigenen Authenticator nutzen, dann vermutlich höchstens für die Arbeit in einer Umgebung, in der Microsoft der einzige Aussteller ist
      Und sehr viele werden ihn wahrscheinlich überhaupt nicht verwenden
    • Irgendetwas passt hier nicht zusammen. Ich habe mehrere Konten mit derselben E-Mail-Adresse und habe die Codes in Authenticator als Backup-TOTP-App mit den korrekten Codes verglichen; sie stimmten überein
      Ich habe allerdings ein UI-Problem gefunden, durch das Nutzer falsche Codes sehen können. Die Codes der ersten paar auf dem Bildschirm sichtbaren Konten werden alle 30 Sekunden aktualisiert, die außerhalb des Bildschirms jedoch nicht
      Scrollt man zu Codes, die vorher außerhalb des sichtbaren Bereichs waren, sieht man veraltete Werte; in einem Fall war der angezeigte Code dem korrekten sogar um 4 Intervalle hinterher
    • Wahrscheinlich verwenden viele ihn nur für das eine von der Firma erzwungene MS-Arbeitskonto. Für irgendetwas anderes wohl eher nicht, weil sie wissen, dass er schlecht ist

  • Seltsamerweise kam eine E-Mail von Microsoft, die wie Phishing aussah, aber wohl keines war.
    Darin stand „Aktion erforderlich: Aktivieren Sie Multi-Faktor-Authentifizierung für den Tenant bis zum 15. Oktober 2024“, und es hieß, ich würde sie als „Globaler Administrator“ erhalten, wobei statt eines Organisationsnamens nur eine UUID angegeben war.
    Es war der Hinweis, dass ab dem 15. Oktober 2024 für die Anmeldung am Azure-Portal, im Microsoft Entra Admin Center und im Intune Admin Center MFA erforderlich sei und man MFA bis dahin aktivieren solle. Falls das nicht möglich sei, solle man eine Verschiebung des Einführungsdatums beantragen.
    Das Problem ist, dass ich bei Microsoft überhaupt keine Organisation verwalte. Ich habe nur so etwas wie ein persönliches Office365 Family-Konto, und für das Konto ist die Zwei-Faktor-Authentifizierung bereits aktiviert.
    In der E-Mail standen weder mein Name noch der Name der angeblichen Organisation, sondern nur eine ID, daher hatte ich überhaupt keine Ahnung, was gemeint war. Trotzdem war es tatsächlich eine E-Mail von Microsoft.

    • Wenn man sich im Azure-Portal anmeldet, sieht man wahrscheinlich eine ähnliche Meldung und kann zu den zugehörigen Ressourcen wechseln.

  • Nachdem ich einige Gmail-Konten erstellt hatte und dann Land und Computer wechselte, habe ich ein paar davon verloren. Als ich mich anmelden wollte, sagte Google, das Passwort sei korrekt, aber Gerät und IP-Adresse seien unbekannt.
    Warum die Wiederherstellung über die Wiederherstellungsadresse nicht funktionierte, weiß ich nicht mehr genau, aber sie scheiterte, obwohl ich weiterhin Zugriff auf die Wiederherstellungs-E-Mail-Adresse hatte. Vermutlich verlangte Google, dass ich die Wiederherstellungs-E-Mail-Adresse nenne, und ich hatte dort möglicherweise ein zufälliges +-Suffix verwendet.
    Früher habe ich für Gmail-Konten Google Authenticator verwendet, aber weil Google in solchen Situationen kaum Abhilfe bietet, habe ich es deaktiviert, da ich Angst hatte, noch eine weitere Fehlerquelle hinzuzufügen.
    Das Passwort hat mehr als etwa 96 Bit Entropie: Ich ziehe 256 Bit aus /dev/urandom, mache daraus eine Ganzzahl mit Mehrfachpräzision, wähle dann mit divmod jeweils ein Zeichen aus Ziffern, Kleinbuchstaben, Großbuchstaben und Symbolen, ziehe den Rest aus dem gesamten Alphabet und verwende die verbleibende Entropie für einen Fisher-Yates-Shuffle, damit das erste Zeichen nicht immer eine Ziffer ist.
    Es ist ein passwort pro Website und wird in einem gpg-basierten Passwortmanager gespeichert, den ich Anfang der 2000er selbst gebaut habe.
    Multi-Faktor-Authentifizierung hilft bei einigen laufenden aktiven Kompromittierungen, aber nicht bei Passwort-Hash-Dumps infolge eines Datenbankeinbruchs. Dass eine Wiederherstellung über die Wiederherstellungs-E-Mail-Adresse nicht möglich ist, obwohl man das Passwort kennt, ist wirklich unerquicklich.
    Wenn man sich monatelang nirgends angemeldet hat und das richtige Passwort besitzt, sollte man einen zumindest nicht zwingen, die Wiederherstellungsadresse anzugeben, sondern einen Bestätigungslink oder Code an diese Adresse senden. Wohin gesendet wird, muss man ja nicht verraten, aber die Wiederherstellungsadresse in ein weiteres auswendig zu merkendes Passwort zu verwandeln, ist wirklich nervig.

    • Das wusste ich nicht. Um das Risiko noch zu erhöhen, hatte ich die Wiederherstellungsadresse auf ein anderes inaktives Gmail-Konto gesetzt.
      Ich vertraue Google inzwischen nicht mehr mit mehr Daten als denen, die ich bereits gegeben habe oder zwingend geben muss.
      Da ein internationaler Umzug ansteht, sollte ich den Wechsel zu Proton Mail beschleunigen, einem kostenpflichtigen Konto, mit dem ich mein E-Mail-Leben teste, bevor ein ernstes Problem auftritt.
      Als Gmail noch harmlos wirkte und die Digitalisierung der Verwaltung begann, fing ich an, Gmail als Kontaktadresse bei Steuern, Gesundheitswesen und Behörden anzugeben. Das funktionierte gut, sodass Gmail über mehrere internationale Umzüge hinweg zu einem wichtigen Verwaltungswerkzeug wurde.
      Ich habe hier und da noch ruhende Konten, aber es gibt wichtige Dinge, die eines Tages noch gebraucht werden könnten. Zum Beispiel australische Reisegenehmigungen, die mehrere Jahre gültig sind.
      Auch nachdem die Massenüberwachung zugenommen hatte, wirkte Gmail noch einigermaßen harmlos, und abgesehen davon, mit welchen Stellen ich zu tun hatte, gab es dort kaum echte Geheimnisse oder sehr persönliche Inhalte.
      Aber jetzt, wo Online-Verwaltung faktisch Pflicht ist und andere Wege kaum noch bleiben, steht Gmail auf eine unerträglich zentrale Weise im Mittelpunkt. Wegen der beunruhigenden Dinge, die automatisierte Bots arglosen Nutzern ohne Gnade und ohne Einspruchsmöglichkeit antun, blieb mir nichts anderes übrig, als mit dem Umzug zu beginnen.
      Es ist so weit verbreitet, dass mir die Zeit fehlt, alles aufzuspüren, und bei vergessenen Konten fühlt es sich wie Folter an, vage Erinnerungen auszugraben. Trotzdem muss es getan werden.
      Ich möchte nicht, dass meine Zwillingsmädchen, wenn sie alt genug sind, E-Mail für amtliche Angelegenheiten zu brauchen, der Gnade der Google-Bots ausgeliefert sind.
    • Als du die Wiederherstellungs-E-Mail hinzugefügt hast, solltest du eine Benachrichtigungs-E-Mail an dieses Konto erhalten haben. Wenn du diese Nachricht im Posteingang findest, kannst du im to-Feld vielleicht das zufällige Suffix herausfinden.
    • Mir ist etwas Ähnliches passiert. Ich wurde zu einer Google-Domain eines Open-Source-Projekts hinzugefügt und bekam dadurch eine E-Mail-Adresse, aber Google verlangt eine Telefonnummer, sodass ich mich nicht anmelden kann.
      Vermutlich könnte ich einen Administrator bitten, das zurückzusetzen, aber es ist ziemlich unangenehm, dass das Konto faktisch als Geisel gehalten wird, bis man persönliche Daten herausgibt.
    • Dadurch, dass es niemanden gibt, mit dem man sprechen kann, ist Schluss, sobald der Computer sagt, es geht nicht.

  • Ich habe es wegen des Arbeitskontos bisher mit Microsoft genutzt. Da ich ohnehin tief in Office365 stecke, gab es keinen wirklichen Grund, es nicht zu verwenden.
    So einen Dialog habe ich nie gesehen, und auch bei den hinzugefügten Konten gab es keine Probleme. Da es ein Arbeitskonto ist, teilen in 99 % der Fälle mein Firmenkonto und ich meine geschäftliche E-Mail-Adresse als Kontonamen.
    Heißt das also, dass ich einfach Glück hatte, weil die von mir genutzten Websites ausreichend eindeutige Labels bereitgestellt haben? Ich habe das Gefühl, das genaue Problem nicht vollständig zu verstehen.

    • Ich wollte Hardware-Keys für die Zwei-Faktor-Authentifizierung verwenden, aber nicht alle Systeme unterstützen das, und selbst wenn, dann oft nicht richtig. Wenn man zum Beispiel nur maximal einen registrierbaren Schlüssel zulässt, fragt man sich schon, was das soll.
      Am Ende vergeht die Zeit, und das ist nicht die Arbeit, die meine Familie ernährt, sondern nur lästiges Herumprobieren, um überhaupt herauszufinden, wie man sich einloggen kann, also habe ich mich für das MS-Ding entschieden, das im vorherigen Job vorgeschrieben war.
      Ich habe bereits viel zu viel Zeit damit verschwendet, an so etwas herumzubasteln, statt mit Online-Konten etwas Sinnvolles zu tun.
      Das gesamte Thema Online-Identitätsnachweis ist zutiefst unzuverlässig und voller großer Lücken und noch größerer Risiken, und trotzdem bauen wir unser ganzes Leben darauf auf.
      Obwohl es seit Jahrzehnten durch Passwortschwächen schwere Schäden gibt, verwenden wir immer noch Passwörter und versuchen nur, das Problem mit Pflastern oder einem neuen Anstrich zu kaschieren.
      Fast jede Woche leakt irgendein Online-System große Mengen personenbezogener Daten, die leicht ausgenutzt werden können, und wir sitzen trotzdem wie in dem Meme mit dem Hund, der mitten im brennenden Raum Kaffee trinkt, da und sagen: „Alles gut, alles gut.“
      Wir glauben einfach weiter, es werde schon gutgehen, solange wir für jedes System unterschiedliche Passwörter mit mindestens 8 Zeichen verwenden.
    • Dieser Bug scheint nur beim Scannen eines QR-Codes in der iOS-App aufzutreten.
    • Bei mir genauso. Drei persönliche Konten verwenden dieselbe E-Mail-Adresse, zwei davon sind bei FAANG, und seit fast zehn Jahren läuft das ohne Probleme.
    • Wenn man die Antwort von Microsoft liest, gibt Microsoft den Unternehmen, die MFA ausstellen, die Schuld, weil sie den „Issuer“ nicht im Label unterbringen. MSFT erwartet offenbar, dass der Aussteller dort steht.
      Wenn das wirklich die Erwartung ist, würden Microsoft-Produkte den Aussteller dort selbst eintragen, und dann gäbe es kein Problem.
      Das Problem entsteht bei anderen Anbietern, die dieselbe E-Mail-Adresse als Kennung verwenden und den Aussteller in das issuer-Feld eintragen, das genau dafür da ist, den Aussteller zu speichern. Wirklich eine seltsame Sache.

  • Safari hatte einen ähnlichen Bug, der Passkeys überschrieb, ohne überhaupt zu warnen, und mich dadurch vollständig aus meinem Konto ausgesperrt hat. Das wurde später behoben, aber ich habe deshalb den Zugriff auf GitHub verloren.
    https://bugs.webkit.org/show_bug.cgi?id=270553
    In Safari gibt es außerdem immer noch einen Bug, durch den Websites auf unterschiedlichen Subdomains nicht unterschieden werden können, außer über fest eincodierte Ausnahmen, sodass das Passwort einer Subdomain mit dem einer anderen überschrieben wird. Das passiert mir jeden Monat.

    • Dass Keychain mich gewarnt hat, ich würde Passwörter zwischen den StackOverflow- und StackExchange-Subdomains wiederverwenden, war einer der Gründe, warum ich zu einem Passwortmanager eines Drittanbieters gewechselt bin, bei dem man mehrere Websites manuell zu einem Eintrag hinzufügen kann.
      Ich wusste allerdings nicht, dass sich diese Dummheit noch tiefer fortsetzt.

  • Genau deshalb ist SMS-MFA bei Nutzern trotz Sicherheitsproblemen beliebt.
    Solange man normalerweise nicht Ziel eines SIM-Swapping-Angriffs wird, ist es meist gut genug. Die meisten werden kein gezieltes Opfer, aber die Wahrscheinlichkeit, Probleme durch verlorene MFA-Schlüssel zu bekommen, ist ziemlich hoch.

    • Genau. Es ist einfach und fast jeder versteht es. Ganz ähnlich wie das Passwort selbst.
      Das ist auch der Grund, warum sicherere Methoden wie YubiKey in der breiten Masse nie richtig angekommen sind. Es ist umständlich und verwirrend.
    • Ich habe es zweimal aktiviert. Beim ersten Mal ist mein Handy direkt nach der Aktivierung komplett kaputtgegangen, beim zweiten Mal wurde es gestohlen.
      Inzwischen verlasse ich mich einfach auf zufällig generierte Passwörter.
    • Ich denke, der Weg nach vorn sind FIDO und sehr günstige NFC-Kartenschlüssel.
      Wenn man sich irgendwo anmelden muss, nimmt man einfach eine Karte aus dem Portemonnaie und hält sie ans Handy oder den Laptop.
      Für Unternehmen mit zahlenden Kunden müsste das so günstig sein, dass es sinnvoller ist, Kunden im Notfall physisch eine Karte per Post zu schicken, als alternative Authentifizierungsmethoden zu unterstützen.
      Die meisten Dienste brauchen vielleicht nicht einmal eine zweite Authentifizierungsebene. Wenn jemand dein Portemonnaie stiehlt, interessiert ihn dann wirklich auch noch dein Reddit-Konto?

  • Ich habe es getestet und zwischen mehreren Konten mit demselben Kontonamen bzw. derselben E-Mail-Adresse keinen Konflikt festgestellt.
    Bei jedem Eintrag wird auch das Aussteller-Icon korrekt angezeigt, und der Aussteller ist jeweils im Eintrag hinterlegt.
    Ich benutze MS Authenticator seit Jahren und habe nie Probleme dieser Art erlebt, und selbstverständlich verwende ich als Kontonamen oder Benutzernamen immer dieselbe E-Mail-Adresse.
    Ich schreibe nur mein Testergebnis auf. Das wird meine Meinung zu Authenticator oder Microsoft vermutlich nicht ändern.

    • Auf welcher Plattform? Ich habe gehört, dass dieses Problem oder diese „Funktion“ auf die iOS-Version beschränkt ist.

  • Das ist mir auch passiert, als ich MS Authenticator nach längerer Zeit ohne Updates aktualisiert habe.
    Alle Daten wurden gelöscht, und ich wurde aus allen Konten ausgesperrt. MS Authenticator ist kein sorgfältig entwickeltes Produkt.

  • Vor etwa einem Jahr ist mir etwas Ähnliches passiert, als die Google Authenticator-App automatisch auf eine neue Version aktualisiert wurde.
    Im Zuge des Updates habe ich alle Konten verloren, und ich habe definitiv ein paar Lehren daraus gezogen.

    • Wegen dieses Albtraums sichere ich immer die MFA-QR-Codes und füge sie zusätzlich in eine Open-Source-App ein, mit der sich die Daten auch an anderer Stelle sichern lassen.