Überlegungen zur Sicherheit des MyFRITZ!-Service im Internet

Der "MyFRITZ!"-Dienst war ja vermutlich Ziel von Angriffen, die nachträgliche Einführung von Captchas Ende Januar (damals noch mit eigener Implementierung, bevor der Dienst dann nach einiger Auszeit mit Google's ReCaptcha wiederbelebt wurde) - die ja jeder aktive MyFRITZ!-GUI-Benutzer bemerken mußte - war sicherlich auch nicht nur der (theoretischen) Erkenntnis geschuldet, daß man mit erbeuteten E-Mail-Daten (z.B. von Android-Geräten mit WebView-Lücke, wo man - ich habe es an anderer Stelle schon einmal angemerkt, aber es gehört auch hier her - dann bei vielen Leuten gleich die Information zur E-Mail-Adresse (i.d.R. == Store-Benutzer) und bei Vorhandensein einer FRITZ!-App auch zur Existenz einer FRITZ!Box erhält) vieler Kunden garantiert auch dort ein Login (automatisch) versuchen konnte.

Das liegt zu einem guten Teil eben auch daran, daß die Beschreibung/Information zum MyFRITZ!-Konto sowohl in der Webseite:

Anhang anzeigen 81572(Screenshot von www.myfritz.net vom 20.04.2015)

als auch beim Anlegen eines MyFRITZ!-Kontos in der Box

Anhang anzeigen 81573(aus FRITZ!OS 06.23 für die 7390)

dahingehend ungenügend sind, daß dort nicht ausdrücklich davor gewarnt wurde, für das Login in die FRITZ!Box und das Login in die MyFRITZ!-Seite dasselbe Kennwort zu verwenden. Die Formulierung im FRITZ!OS-GUI


ist zwar sachlich richtig und nicht zu beanstanden, aber erstens liest fast kein Mensch - jedenfalls keiner meiner eigenen Tester - diesen Satz (was wo hin soll, steht ja vor den Eingabefeldern) und zweitens fehlt - meine Ansicht - die explizite und optisch hervorgehobene Warnung, ein an anderer Stelle bereits verwendetes Kennwort hier erneut zu benutzen. Ganz im Gegenteil ... der enge optische Zusammenhang zwischen der Eingabe einer E-Mail-Adresse und eines Kennworts führt bei vielen Benutzern automatisch zu dem Reflex, dort ebenfalls das E-Mail-Kennwort einzugeben, einfach weil ihnen der Unterschied gar nicht klar ist.

Das ist beim Anlegen eines neuen Benutzers in der FRITZ!Box-Oberfläche noch viel krasser, da dort das Formular noch "verwirrender" (für den Laien) ist:

Anhang anzeigen 81575

Die optionale Angabe der E-Mail-Adresse beim Anlegen eines Benutzer assoziiert für viele - so "dumm" das in den Augen mancher auch sein mag - tatsächlich die Angabe des Mail-Kennworts im Formular. Ich bin jedenfalls schon oft genug gefragt worden, ob da das Mail-Kennwort eingegeben werden muß, wenn ich Hilfestellung beim Einrichten eines Benutzers geleistet habe. Auch die oben verwendete Formulierung


ist nicht einmal jedem "FRITZ!Box-Versteher" sofort eingängig, da es aufgrund des Satzbaus nicht eindeutig ist, ob da "... Benutzername [bzw. der E-Mail-Adresse] und des Kennworts ..." oder "Benutzername - bzw. der E-Mail-Adresse und des Kennworts - ..." gemeint sein soll.

Es sind aber zwei (bzw. drei) vollkommen getrennte Konten/Dienste und wer für alle nur ein gemeinsames Kennwort verwendet, muß sich am Ende nicht wundern, wenn er - sollte es tatsächlich mal soweit kommen, daß z.B. die Datenbank hinter MyFRITZ! gehackt wird, es hat schon ganz andere Kaliber der Branche getroffen, daß die Kundendaten zugänglich waren - unerwünschten Besuch auf seiner FRITZ!Box erhält. Gleiches gilt natürlich für die verwendeten E-Mail-Konten, wobei die Sicherheitsvorkehrungen bei den E-Mail-Providern (meist nach Vorfällen) inzwischen ja fast überall entsprechend erweitert wurden.


Nur der MyFRITZ!-Dienst hinkt in meinen Augen hier noch nach ... was nichts über die Sicherheit der Speicherung von MyFRITZ!-Konten bei AVM aussagen soll, da habe ich keine Ahnung, wie das umgesetzt ist und ob das angreifbar ist oder nicht. Aber die "übliche" Vorgehensweise beim MyFRITZ!-Dienst, E-Mails zum Zurücksetzen des Kennworts an die hinterlegte E-Mail-Adresse zu senden (die gleichzeitig der Benutzername bei diesem Dienst ist), läßt das Hacker-Herz höher schlagen, wenn am Ende vom Benutzer für das Login in die FRITZ!Box das Mail-Kennwort verwendet wird und genau dieses Mail-Konto sich bereits unter der Kontrolle des Hackers befindet.

Die oben erläuterte Wahrscheinlichkeit für identische Kennwörter ist - in meinen Augen - ein Lapsus (hinsichtlich Usability), den sich AVM zurechnen lassen muß. Wenn man das Anlegen eines Benutzers im Rahmen eines Usability-Tests nur mal mit 20 "unbelasteten" Testpersonen (das ist eben die schwäbische Hausfrau, bei der sich die Sparsamkeit auch auf die Anzahl der verwendeten Kennwörter auswirkt oder der "Ich muß mir wirklich Wichtigeres merken."-Typ, für den das Einrichten eines Kennwortes an sich schon eine Zumutung ist, weil das ja auch ohne funktionieren würde) ausgeführt hätte, sollte das eigentlich dabei bereits aufgefallen sein. Wenn es solche Tests tatsächlich gab und dieses "Problem" dabei nicht auftrat, waren die Testpersonen vielleicht schlecht gewählt.

Schon eine kleine Änderung im Formular (Verschieben des Kennwort-Felds hinter den Benutzernamen und Ändern der Beschriftung in einen eindeutigen Wert samt passender - farblich hervorgehobener - Erläuterung) würde da wahre Wunder wirken ... aber vielleicht es ist am Ende ja auch die Schuld des Kunden, wenn er sich so blöd anstellt, da kann AVM ja schließlich nichts dafür (auch wenn man keine Vorkehrungen gegen solche "Fehlbedienungen" trifft). Usability geht aber - zumindest meines Erachtens - anders ... und die FRITZ!Box richtet sich sicherlich weniger an Fachleute als an Laien, das muß man dann einfach auch beim Interface-Design berücksichtigen.

Aber auch dann findet ein Angreifer ja erst einmal die FRITZ!Box noch nicht ... selbst wenn die Adresse des E-Mail-Kontos, der MyFRITZ!-Benutzername und der FRITZ!Box-Benutzername (auch da ist die synonyme Angabe der E-Mail-Adresse beim Login ja möglich, solange sie beim Benutzer eingetragen wurde, selbst wenn die in der Select-Box bei der LAN-Anmeldung nicht angezeigt wird) ebenso übereinstimmen wie das E-Mail-Kennwort und das Kennwort für die Anmeldung in der FRITZ!Box. Ich kenne persönlich genug Leute, wo das der Fall ist und eine entsprechende Warnung nur Schulterzucken hervorruft. Solange dann niemand die passende FRITZ!Box lokalisieren kann, ist das sicherlich auch zu verkraften (trotzdem schlechter Stil), aber kommt dann auch noch der MyFRITZ!-Dienst als Bindeglied ins Spiel, ist diese Verbindung im Handumdrehen hergestellt.

Leider nutzt dann auch ein abweichendes MyFRITZ!-Kennwort nichts mehr, wenn man bei diesem Dienst einfach eine E-Mail-basierte Kennwort-Änderung veranlassen kann, ohne irgendwelche zusätzlichen Sicherheitsfragen (das übliche "Wie hieß der Mann der Frau dieses Malers?") beantworten zu müssen. Das Captcha schützt nur vor Bots, nicht vor "Click-Workern", der Rest (Auswertung der Rücksetz-Mail und "Klick" auf den dort angegebenen Link) ginge dann ohnehin wieder automatisch weiter ... das Eintragen eines neuen Kennworts will dann allerdings wieder ein Captcha gelöst sehen, das muß dann eben wieder ein "Click-Worker" übernehmen.

Einen notwendigen Zusammenhang zwischen der IP-Adresse, von der das Rücksetzen ausgelöst wurde und der IP-Adresse, von der der Link in der E-Mail geöffnet wird, konnte ich nicht feststellen - das ist ja manchmal auch nicht ohne weiteres umzusetzen. Ein mehrfaches Aufrufen des Links in der E-Mail ist ebenfalls möglich, allerdings verfällt der in dieser URL enthaltene "activationcode" offenbar bei seiner tatsächlichen Benutzung ordnungsgemäß, so daß eine mehrfache Änderung über diese eine E-Mail nicht funktioniert.

Es ist mir bisher nur ein einziges Mal gelungen, ein bereits gelöstes Captcha auf der Kennwort-Rücksetz-Seite für den Zugriff ohne erneutes Lösen (nur der "Klick" auf das Widget war noch erforderlich) mit anderen Werten in den Eingabefeldern zu verwenden ... das konnte ich nach dem Ende dieser Browser-Session bisher nicht reproduzieren, es könnte sich also auch um ein "Phantom" handeln, weil ich den richtigen Zusammenhang nicht gesehen hatte.

Wenn der Benutzer selbst die MyFRITZ!-Weboberfläche von AVM gar nicht regelmäßig benutzt und die Mail zum Zurücksetzen des MyFRITZ!-Kennworts vom Angreifer gelöscht wird, dann bemerkt das der legitime Benutzer unter Umständen nicht einmal oder erst viel später (sofern er dann nicht immer noch eher an einen eigenen Fehler glaubt, was bei seltener Benutzung ja auch nicht unwahrscheinlich wäre).

Selbst die DynDNS-Änderungen beim MyFRITZ!-Dienst würden meines Wissens weiterhin funktionieren (habe ich allerdings tatsächlich in letzter Zeit nicht mehr getestet), da dort jeweils eine zusätzliche Identität (box_id/box_id_passphrase aus dem "jasonii"-Abschnitt der ar7.cfg) verwendet wird (mindestens jedenfalls "wurde"), ebenso für jede einzelne MyFRITZ!-Freigabe.

Hier würde es Abhilfe schaffen (aber natürlich den "vergesslichen" Kunden zusätzlich fordern), wenn man mit einer solchen Kennwort-Änderung wenigstens auch die mit diesem Konto verbundenen Geräteeinstellungen löschen würde, damit der Kunde das tatsächlich neu einrichten muß.

Auch das wird aber (sicherlich wieder wegen der "unfähigen Kunden") niemand ohne Not so umsetzen, es braucht wahrscheinlich erst wieder die Katastrophe, damit etwas passiert. Dabei hat heutzutage jeder drittklassige Internetdienst mit Kontoverwaltung solche "Sicherheitsfragen". Die sind auch noch kein Allheilmittel, aber wenigstens wird der (von mir ja nur behauptete und nicht bewiesene) direkte Zusammenhang zwischen den E-Mail-Adressen und Kennwörtern bei den meisten "normalen" Benutzern durchbrochen. Selbst wenn diese Deckungsgleichheit bei Benutzername (bzw. E-Mail-Adresse) und Kennwort eines FRITZ!Box-Benutzers nur zum E-Mail-Konto bestehen sollte (Grund s.o.), dann macht sich bei dieser Umsetzung der MyFRITZ!-Service in meinen Augen zum Helfer eines Angreifers, denn spätestens durch den Zugriff auf die MyFRITZ!-Seite nach erfolgreicher Anmeldung liegt die Information zum "DynDNS-Namen" der Box vor, selbst wenn die FRITZ!-App auf unserem hypothetischen Android-Gerät diese Information ordentlich für sich behalten sollte.

Eine solche Sicherheitsfrage ist zwar über das - zum Anlegen eines MyFRITZ!-Kontos ja verwendete - FRITZ!Box-GUI mit zusätzlichen Änderungen in der Firmware verbunden (auch wenn man das in einem IFRAME ja von einem AVM-Server laden könnte, "cross origin resource sharing" (CORS) mit "*.avm.de" ist m.W. immer gesetzt in neueren Versionen des FRITZ!OS), aber in den sauren Apfel müßte man denn eben beißen.

Der Aufwand für solche Sicherungen beim Anbieter tendiert ansonsten gegen Null ... die paar zusätzlichen Datenbank- und Formularfelder sind schnell implementiert. Stimmt dann die Sicherheitsabfrage nicht (und zwar ohne daß der Initiator darüber informiert wird oder mit einem Zähler für Fehlversuche, nach denen dann auch der Rücksetzvorgang gesperrt wird, sonst ist auch da "trial and error" möglich), gibt es keine E-Mail. Das senkt zusätzlich auch (neben dem Captcha) die Begehrlichkeiten eines Angreifers (bzw. die Angreifbarkeit des Dienstes), wenn die beiden Sicherheitsmerkmale (E-Mail-Adresse und Sicherheitsfrage) voneinander unabhängig sind.

Bei einem kostenlosen Dienst wie MyFRITZ! sind alternative Wege für eine Zwei-Faktor-Authentifizierung beim Zurücksetzen eines Kennworts (z.B. die allseits beliebte SMS als zweiter Faktor) sicherlich eine Frage der Kosten ... aber ein Anbieter, der parallel in solch einer SMS auch noch Werbung unterbringen darf (keine Ahnung wofür, das interessiert bei den anderen derartigen Angeboten von "Free-SMS-Diensten" ja in aller Regel auch nicht), wäre vielleicht eine Alternative. Oder auch die Beschränkung auf einen Rücksetzversuch pro Benutzer/IP-Adresse pro Stunde (oder was man auch immer als Intervall wählt) zur Deckelung der potentiellen Kosten eines eigenen SMS-Versands ... eine FRITZ!Box ist ja auch eine Investition des Kunden und wenn AVM auf so einem Weg eine Art "Frühwarndienst" für Angriffe auf den MyFRITZ!-Service (der natürlich wegen der geballten Informationen bis hin zur Version der Box auch Begehrlichkeiten bei einem Angreifer, der sich auf FRITZ!Boxen "spezialisiert", wecken kann) erhalten würde.

Wie weit solche Hürden (Zugriffsbeschränkungen für Konten/IP-Adressen) bereits jetzt umgesetzt sind, kann man nur vermuten ... leider ist die deutsche Gesetzgebung an dieser Stelle etwas unfreundlich für die eigenständige Überprüfung solcher Annahmen und man kann sich unter ungünstigen Umständen schon durch einfache Tests dem Vorwurf eines (notfalls auch nur versuchten) Angriffs aussetzen. Daher sollte man davon die Finger lassen ... StGB §202a-c und 303a-b sind am Ende für ausländische Hacker nur ein schaler Witz, während sie die Untersuchung solcher Probleme wie oben skizziert für Deutsche nahezu unmöglich machen, solange die dazu notwendigen Anstrengungen über das zu erwartende Maß hinausgehen (eine "versehentliche" Eingabe eines falschen Wertes ist sicherlich noch kein Angriff, bei zehn solcher Versuche sieht das mancher StA vor der Anhörung des Beschuldigten vielleicht schon anders).

Ich darf mich zwar davon überzeugen, wie so etwas implementiert ist, soweit man das von außen auch "sehen" kann. Beim MyFRITZ!-Dienst landet man schnell bei JSF2 als Framework, ob das irgendwelche Rückschlüsse auf die TLS-Implementierung zuläßt und wenn ja, was das am Ende bedeuten könnte, muß schon jeder selbst einschätzen. Fakt ist mal, daß der MyFRITZ!-Dienst auf seiner Webseite auch heute mit Cookies arbeitet (für die Session-ID), damit wäre zumindest dieser Dienst ein Kandidat für die Poodle-Lücke (FRITZ!Boxen sind ja nicht betroffen, da dort keine Cookies zum Einsatz kommen). Jetzt kann man aber nicht einfach einen Web-Dienst auf diesen Server loslassen ... allerdings ist es absolut zulässig, die Verfügbarkeit der SSLv3-Methoden auf diesem Server einfach dadurch zu testen, daß man selbst mit einer entsprechenden Version gezielt auf den Server mit SSLv3 zugreift. Wenn dann der Server nicht die neueren TLS-Optionen gegen ein Downgrade der Verbindung unterstützt, dann steigt die Wahrscheinlichkeit eines möglichen Angriffs auf einen Cookie für eine MyFRITZ!-(Web-)Session schon stark an.

Testen darf ich auch, ob meine eigenen Daten bei AVM tatsächlich sicher sind/sein dürften/sein könnten ... wenn man mit fremden Kontodaten auf so einen Dienst (ohne Einwilligung des Konto-Berechtigten) losgeht, wird es aber schon heikel. Wenn tatsächlich ein Benutzer "[email protected]" existieren sollte (was ja offensichlich - trotz neuer gTLDs - keine gültige E-Mail-Adresse, mithin auch kein fremdes Konto ist), wäre das zumindest verwunderlich ... aber selbst ein "[email protected]" könnte ja (zumindest theoretisch) ein gültiger Benutzer sein.

Ab wann dieser schmale Grat überschritten ist, kann man auch nicht immer genau beurteilen. Wenn AVM tatsächlich auf die Idee kommen sollte, anhand der Log-Dateien Anmeldeversuche samt IP-Adresse zu protokollieren und dann aus einem Test der Sicherheit durch einen Kunden einen Angriff zu konstruieren, kann es sicherlich erst einmal ungemütlich werden (bis man die Lage dann klären könnte und sich ggf. dagegen wehren kann). Glücklicherweise werden die in den o.a. Paragraphen beschriebenen Straftaten nur nach Antrag verfolgt (StGB §303c) ... wenn der StA aber erst einmal die Technik beschlagnahmen läßt für die Dauer des Verfahrens, vernichtet das am Ende Existenzen.

Da warte ich lieber auf den nächsten tatsächlichen Angriff auf den Dienst und die Berichterstattung darüber. Wobei man sich darauf offensichtlich auch nicht mehr verlassen kann, selbst heise.de hat zu den Hintergründen des Ausfalls/der Umstellung des MyFRITZ!-Diensten Ende Januar/Anfang Februar meines Wissens keine Recherchen angestellt oder keine Antworten erhalten (das "Server kaputt" aus dem oben verlinkten heise.de-Artikel mag ja stimmen, erklärt aber das geänderte Erscheinungsbild des Dienstes nach der Reparatur des Server nur unzureichend) oder heise.de hat (vielleicht auch nur bisher?) keine auf anderen Antworten basierenden Artikel veröffentlicht.

Minimal-Lösungen sind jedenfalls die eine Sache ... wenn man gleich von Beginn an höhere Hürden setzt, nimmt man einem Angreifer auch zusätzlich etwas Antrieb, weil andere Ziele dann leichter angreifbar sind.

Apropos Google Recaptcha: Ist es schon einmal jemandem gelungen, auf einem Notebook mit durchschnittlich guten Lautsprechern tatsächlich den angesagten Text in einem "Audio-Captcha" zu verstehen? Ich kann nicht einmal genau sagen, ob das (bei deutschem Text im Google-Widget) am Ende Ziffern in Deutsch oder in Englisch sein sollen, da habe ich offenbar heftige kognitive Defizite oder das Audio-Captcha ist tatsächlich unbenutzbar. Das macht den ganzen Dienst dann für Menschen mit "disabilities" unbenutzbar ... was er ansonsten nicht sein müßte, denn die Darstellung verwendet in weiten Teilen tatsächlich CSS und ist somit (wahrscheinlich, ich habe es nicht selbst getestet) abseits des Captchas sogar ScreenReader-/Braille-tauglich.

Wenn sich also jemand durch den vorstehenden Text veranlaßt sehen sollte (weil er es vielleicht ebenso sieht wie ich), bei AVM diese Problematik (mangelnde Aufklärung bzgl. der möglichen und empfehlenswerten "Vielfalt" der Kennwörter bzw. zu einfaches Rücksetzen des MyFRITZ!-Kennworts) ebenfalls nachdrücklich ins Bewußtsein zu rufen, dann hätte ich mir die Arbeit mit diesem Beitrag nicht umsonst gemacht ... aber auch jeder Benutzer, der seine eigenen Daten unter Berücksichtigung meiner Darlegungen ändert (oder zumindest ab heute verschiedene Kennwörter verwendet, wenn er tatsächlich auch in diese Falle gegangen sein sollte), wäre ein Erfolg.

andiling schrieb:

die Verantwortung liegt aber letztlich beim Nutzer selbst.

Zum Vergrößern anklicken....

+1, bestreite ich auch nicht wirklich.

Aber wenn Oma Kasulske die dargestellten Formulare liest (das trifft garantiert sogar viele von den "digital natives"), dann ist meines Erachtens ohne Not ein Mißverständnis vorprogrammiert und hier könnte AVM gegensteuern. Das verstehe ich halt unter "Usability" und dazu gehört es für mich auch, dem Kunden das Einstellen potentiell gefährlicher Werte so schwer wie möglich zu machen, ohne ihn dabei übermäßig zu gängeln. Deshalb auch keine (JS-gesteuerte) "Sperre" solcher Eingaben (viele verstehen ja die "Abwehr" von Portweiterleitungen auf andere Interfaces als "dev lan" als solch eine Gängelung), aber ein deutlicher Hinweis auf die potentiellen Gefahren bzw. sinnvolle Einstellungen sollte schon drin sein anstelle von mißverständlichen Formulierungen. Mit etwas JavaScript-Spielerei (ausgeblendete "div", die erst nach einem "habe ich verstanden"-Button angezeigt wird), kann man bei vielen sogar erreichen, daß sie solche Warnungen tatsächlich zur Kenntnis nehmen.

@SF1975: Thema "Google-Suche nach MyFRITZ!-Namen"
Das kam durch frühere falsche Einstellungen/Entscheidungen in der Firmware zustande. Wenn eine FRITZ!Box extern auf TCP 443 reagiert, sendet sie ja auch immer ein Zertifikat. In dem steht dann wieder der MyFRITZ!-DynDNS-Name (zumindest wenn die Box es selbst generiert hat und MyFRITZ! aktiviert ist) und mit diesem hat Google dann solche Präsenzen (das "Abgrasen" von Port 80 und 443 ist ja Bread&Butter für einen Spider) auch indiziert. Seit einiger Zeit vermeldet die FRITZ!Box aber mit einer "robots.txt", daß sie nicht indiziert werden möchte. Ob jemals bereits existierende Kataloge von gültigen MyFRITZ!-Namen bei Google gelöscht wurden, würde mich aber auch interessieren ... ich würde aber eher auf "nein" tippen, allerdings bin ich wieder zu faul zum Prüfen. Ich würde aber auch beschwören wollen (aus dem Gedächtnis), daß dieser Name sich bei einer erneuten "Anmeldung" einer FRITZ!Box beim MyFRITZ!-Dienst (damit meine ich keine Aktualisierung der Adresse) bei mir geändert hat. Dann ist es vielleicht nur eine Frage der Zeit, bis der letzte solcher früheren Namen irgendwann auch mal erledigt ist.

Mangels Android-Gerät kann ich nicht einmal testen, ob die "FRITZ!App irgendwas" nicht beim Einrichten sogar den externen HTTPS-Zugriff selbst freischalten, wenn er nicht schon freigegeben ist. Einige Apps - wie z.B. FRITZ!App Ticker - sind ja eher auf lokale und mobile Benutzung ausgelegt, da könnte ich mir das - nach entsprechender Frage, die aber auch nicht jeder Benutzer richtig verstehen muß - tatsächlich als "Komfort-Merkmal" vorstellen, jedenfalls dann, wenn ich mir so ansehe, an welchen Stellen die FRITZ!App Fon (ich kenne nur die iOS-Variante) beim automatischen Einrichten von IP-Telefonen vergeblich versucht schlauer zu sein als ihr "Herrchen" und das auch noch ungefragt. Das läßt mich dann unter geeigneten Umständen sogar an einer Nachfrage der App vor solchen Aktionen zweifeln ... den Support-Aufwand bei Fragen der Art "Ich habe xyz installiert und kann von unterwegs nicht zugreifen." würde das garantiert senken.

Aber - wie geschrieben: Ich kenne die ganzen zusätzlichen Apps für Android nicht (für iOS gibt es ja nur "FRITZ!App Fon" und "MyFRITZ!"), daher kann ich da nur spekulieren und bei den iOS-Versionen habe ich bisher nur unerwünschtes Löschen und Anlegen von IP-Telefonen gesehen.

Technisch wäre das über die TR-064-Schnittstelle aber problemlos möglich. Vielleicht hat das ja jemand anderes tatsächlich schon mal probiert? Geht zwar von "MyFRITZ!" etwas weg, ist aber immer noch dicht am Thema ... denn bei vielen Benutzern dürfte der externe Zugriff für solche Apps ja anhand der MyFRITZ!-Adresse erfolgen und weniger anhand eines eigenen DynDNS-Dienstes/-Accounts.

@Canon:
Das steht eigentlich in rot überdeutlich da.

Du gehörst offenbar zu den Leuten, bei denen (richtigerweise) das MyFRITZ!-Kennwort und das Kennwort für das Login in die FRITZ!Box verschieden sind. Bei allen Deinen beschriebenen Versuchen erklärst Du aber immer wieder, daß der eine Satz Credentials (Benutzername und Passwort) auf Deiner FRITZ!Box garantiert funktioniert und führst alle möglichen Versuche/Beweise dafür an.

Das mag sogar alles stimmen, Du übersiehst aber leider, daß Dein MyFRITZ!-Konto (so komisch das in der Überspitzung auch klingen mag) eigentlich gar nichts mit dem Konto in der FRITZ!Box zu tun hat.

So einfach ist das ... ich verstehe die Verwirrung da ehrlich gesagt nicht so richtig. Auch wenn es genau diese Verwirrung ist (Du bist sicherlich nicht der Einzige, der das ständig durcheinander schmeißt), die ja ein grundlegender Kritikpunkt meinerseits an der derzeitigen Umsetzung und Beschreibung/Bedienungsanleitung des MyFRITZ!-Dienstes ist ...

@Joe_57:
Das bedeutet es hoffentlich nicht wirklich ... wer tatsächlich so leichtsinnig ist, sein MyFRITZ!-Kennwort und das FRITZ!Box-Kennwort identisch zu wählen, der braucht sich nicht wundern. Schon aus prinzipiellen Erwägungen, denn das Kennwort wird aus dem Formular (per HTTPS geschützt, das betrifft aber nur den Transportweg) zum AVM-Server übertragen und liegt damit dort im Klartext vor - zumindest für die Bildung eines Hash-Wertes, wenn AVM die Kennwörter nicht im Klartext speichert. Greift jetzt jemand erfolgreich die Java-Server-Faces-Anwendung auf dem AVM-Server an und fängt diese Klartext-Kennwörter ab, hat er damit den Einstieg in die FRITZ!Box beim Benutzer. Daß AVM selbstverständlich die Kennwörter auch ohne Angriff auf die Anwendung hat, versteht sich von selbst ... das heißt ja noch nicht, daß sie damit auch etwas anstellen bzw. diese persistent irgendwo speichern. Aber für die Dauer der Anmeldung liegt das Kennwort im Klartext vor und kann damit auch ausgespäht werden.

Trotzdem bzw. deshalb kann man nur so oft wie möglich betonen, daß das FRITZ!Box-Kennwort und das MyFRITZ!-Kennwort unterschiedlich sein sollten.