Beiträge von zedtea

    Guten Morgen harob ,

    ich bin mir da nicht sicher aber könnte es nicht zu Problemen kommen wegen der Verifizierung?

    Man muss sich beim Wechsel von Post- zu Prepaid-Vertrag ja schließlich erneut Identifizieren. Wenn man dann keinen offiziellen Wohnsitz mehr in Deutschland hat (und Bankverbindung?), dürfte das dann mit dem Abgleich schwierig werden.

    Ich bin mir da aber nicht sicher, deshalb dieser Einwand nur unter Vorbehalt.

    Gruß, zedtea

    Gibt es hier dann aus Kulanz immer nur 10 % oder gibt es da inzwischen den jeweiligen bzw derzeit aktuellen Rabatt, also 25 %?

    Hey Meefranke , aus meiner Erfahrung kann ich dir sagen, dass bei CB der jeweils aktuelle Rabatt gewährt wird, welcher mit dem Coupon verbunden ist.

    Das heißt, wenn du zuvor einmal einen Tarif mit x% CB-Rabatt abgeschlossen hast und nun einen Tarifwechsel anfragst, bei dem zur Zeit y% CB-Rabatt angeboten werden, wird der neue Tarif auf y% CB-Rabatt geändert.

    Das kann mehr oder weniger sein.

    Trotzdem musst du das unter Vorbehalt betrachten. Jeder Wechselwunsch wird von der Fachabteilung manuell geprüft und dann entweder bestätigt oder abgelehnt. Darüber erhälst du dann von der Fachabteilung einen Bescheid per Mail

    Gruß, zedtea

    Ich habe bereits einen Rabattcode genutzt. Bitte teile mir kurz mit, falls ich für den Wechsel einen weiteren Code benötige und wo genau ich diesen hinterlegen kann.

    Hey, Linda meinte damit, dass du erneut einen Rabattcode angeben musst, wenn ein Tarifwechsel stattfinden soll und dieser Rabatt weiterhin gewährt werden soll.

    Dazu im Forenprofil unter "Handy / Router" den neuen Rabattcode hinterlegen. Der Support leitet den dann mit weiter an die zuständige Fachabteilung. Die geben dir dann per Mail Bescheid. (Landet gerne mal im Spam)

    Gruß, zedtea

    Hey zedtea,

    uns liegen leider (noch) keine Informationen dazu vor. Bleibt auch für uns erstmal nur abwarten, was wird.

    Gruß
    Oliver

    Vielen Dank für die Antwort.

    Wenn du sagst "(noch)", heißt das dann, dass ihr intern nachgefragt habt und man hier über die weiteren Entwicklungen diesbezüglich etwas erfahren wird?

    Solange ist meine Anfrage ja noch nicht gelöst.

    Das wäre sehr nett. 🙂

    Gruß, zedtea


    merlin1986 Danke dir für das Kompliment 😊

    Hallo, als kleiner Ideen-Einschub:

    Sofern man einen VoIP- bzw. SIP Client nutzt, bei der man über eine Mobil- oder Festnetznummer via App auf dem Smartphone erreichbar ist, kann man in diesem Fall bereits in Deutschland netzseitig eine absolute, unbedingte Umleitung auf die entsprechende Nummer festlegen.
    (Bei bedingten Rufumleitungen fallen hier Kosten kann, da der Anruf erst in die Schweiz geht, dann ggf. zurück nach Deutschland verwiesen wird usw.)

    Die Anruf erfolgt dann auf der Rufnummer der entsprechenden App und der Anrufer bekommt davon i.d.R nichts mit. Rückrufe können dann ggf. von der SIP/VoIP Rufnummer erfolgen. Hier greift bei der Telefonie also das Datenroaming und der Anruf erfolgt darüber.

    In dem Beschrieben Fall kann man das dann so für den gesamten Urlaub belassen, egal ob man gerade in Österreich oder der Schweiz ist. Man ist telefonisch erreichbar und muss keine Kosten fürchten. Wenn man dann zurück in Deutschland ist, Rufumleitung deaktivieren.

    Allerdings dürften keine SMS-Zustellung erfolgen und soweit ich weiß ist RCS noch bei keinem Netzbetreiber in der Schweiz vollständig aktiviert.

    Da aber eine netzseitige Umleitung eingerichtet ist, dürften auch so keine Kosten anfallen und man ist telefonisch erreichbar.

    Gruß, zedtea

    Bitte Torc , hast du dich damit mal ernsthaft auseinandergesetzt?
    Du bringst ständig Input der am Ende das eigentliche Thema verwässert, weil man dir erst einmal erklären muss, wie die eigentliche Sachlage ist. Am Ende folgt eine lange Diskussion und dann ziehst du dich zurück. Das zieht das ganze unnötig in die Länge.

    Was du zitierst, ist das was ich bereits geschrieben habe.

    Un nochmal alles beisammen und einige Infos dazu:

    • RCS hatte bisher keine standardmäßige Verschlüsselung integriert
    • Google hat seine eigenen Verschlüsselung draufgepackt, (ging aber nur untereinander bei Google Messages)
    • Apple hat RCS integriert und sich dafür bei der GSMA eingesetzt, dass eine systemübergreifende Verschlüsselung zum RCS-Standard hinzugefügt wird, die unabhängig vom jeweiligen Messenger Dienst ist.
    • GSMA hat RCS weiterentwickelt und ab Version 3.0 eine systemübergreifende Verschlüsselung integriert
    • Apple testet aktuell mit iOS 26.4 beta RCS Protokoll 3.0 mit Verschlüsselung
      (Beta 1 war noch mit Verschlüsselung nur unter iOS Geräten, seit Beta 2 wird die Verschlüsselung auch zu Android getestet)
    • ! Auch Google wird in Richtung Apple zukünftig verschlüsselt kommunizieren können und zwar über die RCS-Verschlüsselung, alternativ hätte Apple Googles Verschlüsselung nutzen müssen.
    • !!! Wenn es alle so handhaben würden wie Google, dann würde die Kommunikation nur immer im eigenen Ökosystem verschlüsselt bleiben.
    • !!!!! Apple will, dass alle mit allen verschlüsselt kommunizieren können und zwar ohne dass die die einzelnen Anbieter sich auf eine Verschlüsselung verständigen müssen und voneinander abhängig sind. Es soll systemseitig integriert sein was es nun ist.

    Und da kommen die Mobilfunkanbieter ins Spiel. Sie ermöglichen die Kommunikation via RCS über ihre Server überhaupt erst (so wie SMS und MMS) und müssen die Verschlüsselung erst aktivieren und implementieren.

    Wenn ich zukünftig iOS 26.4 installiert habe mit RCS 3.0, dann ist die Verschlüsselung noch nicht automatisch aktiv. Es würde bei aktiver Verschlüsselung ein kleines Schloss-Symbol angezeigt werden an den Nachrichten. Das kann man alles im Internet Recherchieren.

    congstar / Telekom (sowie alle anderen Netzbetreiber) müssen es also anbieten.

    Deshalb meine Frage: Ist da was bekannt zu, irgendetwas geplant?

    Gruß, zedtea

    Hallo congstar , gibts denn so gar keine Infos dazu?

    ich denke, das dürfte für einige schon relevant und interessant zu wissen sein, ob man das erwarten kann.

    Vielen ist eine sichere Kommunikation wichtig und wenn das nicht gegeben ist, wird sich RCS gewiss schwieriger tun, gegenüber den vielen Messengern zu behaupten.

    RCS ist fester Tarifbestandteil bei congstar und es obliegt dem congstar/Telekom die Verschlüsselung zu gewährleisten.

    Gruß, zedtea

    Torc Das Ist soweit richtig und genau das, worauf ich hinaus möchte. Wie dem Artikel ebenfalls zu entnehmen ist, war Apple "bei der Einführung der Ende-zu-Ende-Verschlüsselung in die RCS-Spezifikation federführend beteiligt".

    Aber was nicht diesem Artikel zu entnehmen ist, sich aber an anderer Stelle recherchieren lässt:

    Zur plattformübergreifenden verschlüsselten Kommunikation via RCS müssen die Mobilfunkanbieter diese Funktion zusätzlich auf ihren Servern implementieren und anbieten.

    Das auf vielen Android-Geräten vorinstallierte Google Messages unterstützt zwar eine eigene Ende-zu-Ende-Verschlüsselung, aber nur bei der Kommunikation zwischen zwei Google-Messages-Clients – und nicht plattformübergreifend zwischen iOS und Android.

    Gruß, zedtea

    Hallo, ich habe eine Frage bezüglich des RCS Standards, also dem Nachfolger von SMS und MMS.

    Seit einiger Zeit wird dieser Standard auch von Apple unterstützt, was es nun ermöglicht, Nachrichten und Medieninhalte kostenlos, in hoher Qualität und ohne Messenger einer weiteren Firma zwischen iOS- und Android-Geräten auszutauschen.

    Der Funktionsumfang von RCS bietet mittlerweile die relevantesten Möglichkeiten, die man von Messengern wie WhatsApp kennt.

    RCS muss zusätzlich auch von den Mobilfunkanbietern ermöglicht werden, was bei congstar im Telekom-Netz ebenfalls der Fall ist. (Sowie bei allen anderen Mobilfunkanbietern in Deutschland, soweit ich weiß.)

    Nun wird RCS fortwährend von der GSMA (Global System for Mobile Communications Association) weiterentwickelt und Apple hat bisher noch nicht die aktuellste Version dieses Standards in sein System implementiert.
    Das soll allerdings mit einer der nächsten Updates erfolgen - möglicherweise mit iOS 26.4, da es hier bereits in den Beta-Versionen getestet wird.

    Besonders relevant ist hier der Punkt der verschlüsselten Kommunikation. Die ist bisher noch nicht gegeben und soll mit der neueren Version möglich werden. Das war eine Anliegen, für dessen standardmäßige Implementierung sich Apple eingesetzt hat.

    "Ermöglichen" schreibe ich deshalb, weil auch in diesem Fall ein mitwirken der Mobilfunkanbieter notwendig ist. Diese müssen diese Funktion zusätzlich aktivieren bzw. implementieren.


    Nun zu meiner Frage: Wird congstar bzw. die Telekom die verschlüsselte Kommunikation via RCS ermöglichen?

    Ist da was geplant?


    Wenn nicht, halte ich das persönlich für einen gravierenden Mangel, da die Mobilfunkanbieter so jede Nachricht und jeden Inhalt ungefragt mitlesen könnten. Selbst WhatsApp aus dem Hause Facebook verschlüsselt die Kommunikation.

    Gruß, zedtea

    Mal eine Frage in die Runde.
    Da ich zur Zeit keine eSIM aktivieren muss, könnte mir jemand erklären, wie sich die eSIM-Aktivierung im Vergleich zu vorher vereinfacht haben soll?

    Betrifft es nur Neuverträge oder auch die Umwandlung einer physischen SIM in eine eSIM?

    Das würde mich doch sehr interessieren, ggf. für die Zukunft.

    Gruß, zedtea

    Das ist nun auch nicht das Forum um über Tarife der Telekom zu debattieren.

    Congstar bietet das zur Zeit nicht an, hat es aber auf dem Schirm und es scheint auch da was in Planung zu sein für die Zukunft, sofern man das hier verfolgen konnte bisher.

    Ob das konkurrenzfähig ist sei dahingestellt, denn die technischen Hürden und damit verbundenen Kosten für die Provider sind ja nun bekannt.

    Letztendlich hat jeder die freie Wahl und kann dahingehen, wo er möchte. Congstar und die Telekom sind aber so gut aufgestellt, dass es für sie keinen Grund gibt die günstigen Mitbewerber preislich mit Wumms zu unterbieten.

    Denn klar ist auch, günstiger geht immer aber dafür wird an anderer Stelle gespart. Und viele wollen eben mehr als nur das billigste Angebot. Wäre dem nicht so, könnte sich Telekom und congstar nicht auf einem derart umkämpften Markt halten.

    In der Regel sind die 5€ ja auch durchgestrichen und die 3€ werden als Rabatt/Aktion beworben.

    Würde sich daran nie etwas ändern, wäre es kein Rabatt/Aktion sondern der Normalpreis.

    Gruß, zedtea

    Das sind zwei von einander getrennte Login Verfahren.

    Ich denke, man konnte meinen Kommentaren hier entnehmen, dass ich den Unterschied zwischen PW mit 2FA und PK kenne. Folglich auch weiß, dass es sich dabei um verschiedene Verfahren handelt und eben wie diese funktionieren.

    Dennoch kann kein Anmeldeversuch abgebrochen werden, der mangels ausgelöster Challenge gar nicht erst stattfindet. Das war der eigentliche Kontext meiner Aussage zu deinem Kommentar.

    Auch wenn wir in der Sache etwas aneinander vorbeigeredet haben, komme ich zum gleichen Entschluss. Die Implementierung von Passkeys bei congstar hat hier und da noch ein paar Ecken und Kanten.

    Aber die Vorschläge wurden ja übermittelt. Bleibt nur zu wünschen, dass neben einem Management gleichzeitig auch offiziell die Möglichkeit kommt, mehrere Passkeys zu erstellen.

    Gruß zedtea

    Trotzdem, das erneute Einrichten sollte vom Server zugänglich gemacht werden, wenn nicht automatisiert nach klassischem Passwort/Nutzername Login bei dem der bisherige öffentliche Schlüssel überschrieben wird oder als „Karteileiche“ liegen bleibt, dann eben angestoßen durch zurücksetzen des Passworts <- wo es gerade zu knirschen scheint.

    Ein Management zur einfachen Verwaltung (auch mehrerer Passkeys) wie hier geschrieben und gewünscht, wäre schon sinnvoll. Nicht ohne Grund haben die meisten Anbieter das implementiert.

    Und nebenbei wenn der Anmeldeversuch mit Passkey fehl schlägt muss der Server davon ausgehen dass sich jemand falsches versucht anzumelden und muss den Anmeldevorgang abbrechen und nicht ein neues Passkey erstellen anbieten.

    Steht für mich im Widerspruch zur Aussage:

    Der Server kann dabei nicht fest stellen ob der Passkey auf dem Gerät gelöscht wurde da bei dieser Funktion gar nicht die Challange an das Gerät geschickt wird wenn man sich mit Passwort anmeldet.

    Wird nichts ausgelöst (Challenge), da ja kein Passkey vorhanden auf dem Gerät, wie soll der Server davon ausgehen, dass jemand Falsches versucht sich anzumelden?

    Das würde keinen Sinn ergeben. Ohne gespeicherten Passkey kann keine digitale Signatur übermittelt werden, die den Server wiederum veranlasst den entsprechenden öffentlichen Schlüssel zu übermitteln.

    Ich möchte noch einen Gedankengang hinzufügen. Denn meiner Ansicht nach hat Torc vielleicht gar nicht so unrecht, wenn es vielleicht auch anders gemeint sein könnte.

    Denn klar ist, dass es keine direkte Kommunikation zwischen Passwortmanagern und den jeweiligen Diensten im Hintergrund gibt, dennoch findet beim Versuch sich einzuloggen Kommunikation zwischen Smartphone/PC und dem entsprechenden Dienst statt. Es wird mitgeteilt, wer man ist (digitale Signatur) und der öffentliche Schlüssel wird übermittelt und mit dem eigenem abgeglichen. Passt das, wird ein Ok übermittelt und man wird reingelassen - das mal vereinfacht gesagt. Da ist der zweite Sicherheitsfaktor quasi ohne eigenes agieren integriert.

    Wird nun beim Dienst angefragt, nachdem man den eigenen Passkey gelöscht hat, kann diese Kommunikation nicht stattfinden. Der dienst wüsste also auch gar nicht mit wem er es zu tun hat und könnte den öffentlichen Schlüssel für den Abgleich nicht herausrücken. Folglich kann der Dienst nur anbieten einen neuen Passkey einzurichten.

    Das könnte durchaus so gewollt sein, allerdings muss das der Server das auch anbieten und anscheinend macht er das bei congstar nur nach dem zurücksetzen des Passworts (oder auch nicht) 😉

    Ich habe mich mit der Thematik noch einmal mehr etwas vertraut gemacht, weil ich denke, dass das ganze doch ziemlich undurchsichtig ist und nicht so leicht verständlich. Vielleicht hilft es dem ein oder anderen weiter.


    Erklärung: Smartwatch-Unterstützung im Mobilfunk
    (und warum congstar nicht einfach nur künstliche Hürden eingebaut hat um diese zu verhindern)

    Smartwatches wie die Apple Watch benötigen eine Multi-SIM im eSIM-Format. Die Rufnummer muss identisch sein mit der des gekoppelten Smartphones. Nur über das gekoppelte Smartphone lässt sich die SIM-Funktionalität auf der Watch aktivieren. Dieser Aktivierungsprozess lässt sich nicht umgehen, die Watch kann folglich nicht autark mit einer eigenen Rufnummer betrieben werden. (Außer für Familienmitglieder, dazu unten mehr)

    Das eigentliche Problem: Multi-SIM ist nicht gleich Multi-SIM.

    • Es gibt die klassische Multi-SIM, welche quasi ein Klon einer anderen SIM-Karte ist. Dies ist die Variante, die congstar aktuell anbietet. Diese Karten teilen sich ein Datenvolumen und Anrufe können vom Netzbetreiber an beide SIM-Karten gleichzeitig „gelenkt“ werden, sodass beide Karten klingeln. SMS können jedoch nicht aufgeteilt an beide Karten gleichzeitig gesendet werden, hier muss vorab entschieden werden, wo sie landen soll. Dabei sind zwei eigenständige Karten mit gleicher Nummer im System des Netzbetreibers gelistet – zwei Identitäten mit gleicher Rufnummer.
    • Zusätzlich gibt es die sogenannten MSI-Multi-SIM (MSI = Multi Device Single Identity). Bei diesem Standard bilden Smartphone und Watch eine einzige Identität (Single Identity) im Netz.
      Dieser Service wird durch zusätzliche Serverdienste gewährleistet, die von einem sogenannten Entitlement Server (prüft die Berechtigung) bereitgestellt werden. Beide Karten klingeln ebenfalls gleichzeitig, das Datenvolumen wird ebenso geteilt aber auch SMS können synchron an beide SIM-Karten gesendet werden. Der Server sorgt auch dafür, dass Anruflisten und SMS-Benachrichtigungen im Gegensatz zur klassischen Multi-SIM auf allen Geräten synchron bleiben.

    Entitlement Server (ES):
    Der Server wird vom Mobilfunkanbieter bereitgestellt und muss von Apple autorisiert sein.
    Er kommuniziert mit Apple-Servern, die dann wiederum der Watch das entsprechende SIM-Profil zum Laden anbieten, sofern der gebuchte Tarif dies ermöglicht. Dabei sorgt er dafür, dass die eSIM der Watch mit der des iPhones im Netz des Mobilfunkanbieters verknüpft werden und als eine Einheit auftreten (MSI, s.o.).

    Technisch relevant!: Smartwatches checken aufgrund der geringen Batteriekapazitäten seltener nach eingehenden Signalen als Smartphones. Der Entitlement Server weist das Netz bzw. den Funkmast dabei an, die Signale in einem speziellen Rhythmus zu senden, der auf den der Uhr abgestimmt ist. Ohne diese Anpassung durch den Server würde der Funkmast die Verbindung zur Uhr regelmäßig verlieren. Alternativ müsste die Uhr im Rhythmus eines Smartphones nach Signalen Prüfen und die Batterie wäre innerhalb kürzester Zeit leer.

    Theoretisch könnte die Telekom congstar zwar gewähren, die eigenen Entitlement Serverkapazitäten mit zu nutzen aber auf jedem iPhone ist eine spezielle Konfigurationsdatei gespeichert, die von Apple für jeden Anbieter individuell signiert und zertifiziert wird. Diese Zertifizierung lässt sich Apple bezahlen und andere Provider im gleichen Netz müssen diese ebenfalls durchlaufen. Man kann zudem davon ausgehen, dass bei diesem Prozess auch gewisse Bedingungen, z.B. die Abnahmemenge an Apple Hardware zur Vermarktung durch den Mobilfunkanbieter, ausgehandelt werden.

    Die Identität der SIM-Karte verrät dem Server sofort, dass es sich um eine congstar SIM (oder die eines anderen Anbieters im gleichen Netz) handelt, woraufhin in der Watch App auf iPhone im entsprechenden Einrichtungsmenü folgende Info erscheint: „Dein Telekom.de-Account ist nicht zur Aktivierung des Mobilfunks auf der Apple Watch berechtigt. Weitere Informationen sind von Telekom.de erhältlich.“

    Daran wird sich also auch nichts ändern, wenn die Gerätehersteller dazu übergehen, ihre Geräte nur noch mit eSIM auszustatten oder congstar die 2-Faktor-Authentifizierungen via SMS durch ein anderes Verfahren ersetzt. Auch dann wird es weiterhin die Unterscheidung zwischen der klassischen Multi-SIM und der MSI-Multi-SIM geben und den damit einhergehenden, unterschiedlichen Netzdiensten.

    Und noch zu guter letzt: Die Idee, die Watch über die Einrichtung für Familienmitglieder mit einer eSIM auszustatten ist zwar möglich aber bringt wahrscheinlich nicht den gewünschten Komfort. Schaut man unter der offiziellen Quelle von Apple, sieht man, dass auch hierfür nur unterstütze Anbieter mit entsprechenden Tarifen in Frage kommen sollen.

    Nutzt man dies, wird die Uhr aber wie ein eigenständiges Mobilfunkgerät behandelt. Das heißt, sie wird in ihren Fähigkeiten stark beschnitten und muss dann gleichzeitig deutlich aktiver mit dem Mobilfunknetz kommunizieren. In Foren wird bei diesem Modus über eine deutlich reduziertere Akkulaufzeit berichtet.

    Die Watch hat dann eine eigene Nummer für Anrufe und SMS, es findet also auch keine Synchronisation mit der Rufnummer des dazugehörigen iPhones statt (Anruflisten/SMS) auch kein iMessage.

    Einige Gesundheits-Apps funktionieren zwar aber die Daten dazu werden dann in einem eigenen Profil gespeichert und nicht mit denen des eigenen Profils auf dem iPhone synchronisiert. Die folgenden Funktionen und Apps sind nicht verfügbar: Medikamente, Atemfrequenz, Mitteilungen bei unregelmäßigem Herzrhythmus, EKG, Vorhofflimmern-Protokoll, Zyklusprotokoll, Schlaf, Temperatur am Handgelenk, Blutsauerstoff, Stabilität beim Gehen, Hörbücher, News, Kurzbefehle, die Doppeltippen-Geste und internationales Roaming.“ Auch Apple Pay geht dann nicht.

    Gruß, zedtea

    Mich macht das ganze noch stutzig wie es hier zu einer eSIM Umstellung nach der Schnellstart Einrichtung kommen kann, vor allem weil ich vorher keine eSIM genutzt habe.

    Hey, zur technischen Frage: Das ist eine Funktion von iOS. Beim überspielen der Daten von einem iPhone auf ein anderes wird einem angeboten, die physische SIM umzuwandeln und als eSIM auf das neue Gerät zu übertragen. Soweit ich weiß, wird dieser Weg auch von Congstar unterstützt, neben der Umwandlung in der congstar-App.

    Die physische wird dabei deaktiviert. Kommt es bei der Übertragung zu Problemen oder wird sie vorzeitig abgebrochen, ist die physische Karte deaktiviert und die eSIM nicht funktionsfähig.

    Der Support wird in so einem Fall eine neue physische SIM schicken.

    Gruß, zedtea

    Mal eine kleine Zusatzinfo, da mich die Thematik interessiert hat.

    Es ist anscheinend tatsächlich so, wie Spooner82 geschrieben hat. Bei Android ist das teilen von Passkeys nicht vorgesehen.

    Grundsätzlich ist das eigentlich in diesem Standard so festgelegt. Heißt also, Passkeys sollen gerätegebunden und nicht wie Passwörter teilbar sein. Das dient dem Sicherheitsaspekt, da Passkeys somit nicht wie Passwörter abgegriffen werden können.

    Apple (und externe Anbieter wie z.B. Bitwarden, 1Password) bieten aber zusätzlich eine sichere Übermittlung von Passkeys innerhalb des eigenen Kosmos an. Im Rahmen der Familiengruppe von Google lassen sich Passkeys aber nicht teilen und Samsungs Passwortmanager auf Android ermöglicht dies ebenfalls nicht.

    Eigentlich ist vorgesehen, dass man für den gleichen Account auf unterschiedlichen Geräten auch unterschiedliche Passkeys einrichten muss. Das bedeutet dann jeweils ein eigener Einrichtungsprozess und dient ebenfalls der Sicherheit, weil man erstmal Zugang zum entsprechenden Account haben muss. Entscheidend ist hier, dass dies vom entsprechenden Diensteanbieter angeboten bzw. ermöglicht werden muss.

    Anscheinend bietet congstar diese Option (noch) nicht an, weshalb es in diesem Fall zu den beschriebenen Problemen kommt.

    Hier hilft aktuell nur das ausweichen auf alternative Passwortmanager oder alternativ dann auf einem Gerät die 2-Faktor-Authentifizierung via SMS und auf einem anderen parallel Passkey zu nutzen.

    Das beschränkt dann jedoch die Nutzung eines Accounts auf 2 Geräte bzw Nutzer.

    Gruß, zedtea