Werden alle 2FA-Secrets zu Google übermittelt?

  • Hi,


    ich wollte eben die 2FA aktivieren und habe dabei gemerkt, dass der QR-Code nicht angezeigt wird. Als ich dann das Bild in einem getrennten Tab aufgerufen habe, habe ich gesehen, dass die URL https://chart.googleapis.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth%3A%2F%2Ftotp%2FCCP%3A58368%3Fsecret%3DNW76GSUQQ334PHCR lautet. In der URL steht ja das Secret für die 2FA drin und als normaler Query-Parameter landet das dann bei Google in den Logs.


    Also bei mir wird der Abruf auch blockiert, sonst wäre mir das wahrscheinlich überhaupt nicht aufgefallen. Aber so allgemein erscheint mir das nicht als sinnvoll, diese Daten an Google zu übermitteln – ein Schelm, der jetzt denkt, die haben diesen Dienst eingerichtet, um Daten abzufischen und otpauth://totp ist nun nicht, was man nicht aus Log rausgreppen könnte.

  • Hi,


    ich wollte eben die 2FA aktivieren und habe dabei gemerkt, dass der QR-Code nicht angezeigt wird. Als ich dann das Bild in einem getrennten Tab aufgerufen habe, habe ich gesehen, dass die URL https://chart.googleapis.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth%3A%2F%2Ftotp%2FCCP%3A58368%3Fsecret%3DNW76GSUQQ334PHCR lautet. In der URL steht ja das Secret für die 2FA drin und als normaler Query-Parameter landet das dann bei Google in den Logs.


    Also bei mir wird der Abruf auch blockiert, sonst wäre mir das wahrscheinlich überhaupt nicht aufgefallen. Aber so allgemein erscheint mir das nicht als sinnvoll, diese Daten an Google zu übermitteln – ein Schelm, der jetzt denkt, die haben diesen Dienst eingerichtet, um Daten abzufischen und otpauth://totp ist nun nicht, was man nicht aus Log rausgreppen könnte.

    Macht für mein Verständnis Sinn und würde ich auch so sagen... ist mir aber bisher gar nicht aufgefallen.


    Im Beschwerdeformular wurde hier auch ewig lang der komplette Formularinhalt (mit pbD noch und nöcher) als GET Parameter in einem Referrer an einen CDN Betreiber weitergegeben... daher würde mich sowas hier nicht wundern. Da hat halt mal wieder ein Entwickler gepennt oder keinen Plan von Web Application Security gehabt.


    Ich würde dir da aber raten, mal bitte ein Ticket beim Support aufzumachen, auf den Thread hier zu verweisen und nochmal deutlich reinzuschreiben, dass das eindeutig eine Sicherheitslücke ist.

    Mein oben beschriebener Fall wurde dann ein paar Tage nach Meldung/Ticket behoben...

  • Also bei mir wird der Abruf auch blockiert, sonst wäre mir das wahrscheinlich überhaupt nicht aufgefallen. Aber so allgemein erscheint mir das nicht als sinnvoll, diese Daten an Google zu übermitteln – ein Schelm, der jetzt denkt, die haben diesen Dienst eingerichtet, um Daten abzufischen und otpauth://totp ist nun nicht, was man nicht aus Log rausgreppen könnte.

    Ich verwende das Firefox Addon "Decentraleyes", das leitet die anfragen auf eine lokale resource um, das JavaScript von googleapis kannst du dann getrost aktivieren, da keine google abfrage stattfinden wird. Mit 2FA hatte ich nie Probleme (hat also auch ohne die Server Abfrage funktioniert)

  • Guten Abend.


    Aktuell wird der QR-Code mit Hilfe einer Google API erstellt und dazu auch an diese übertragen, das ist korrekt. Es ist klar, dass hier Optimierungspotenzial besteht. Natürlich ist aber eine Account-Übernahme nur durch Zugriff auf einen erstellten 2FA-Token nicht möglich. Dennoch verstehe ich euer Anliegen natürlich.


    Ich habe ein Ticket bei unseren Entwicklern erstellt, damit dies im Rahmen zukünftiger Verbesserungen evaluiert und optimiert werden kann.

  • Geben das denn die Datenschutzbedingungen her? Gerade auch nach Schrems II?


    So ein QR-Code sollte doch auch lokal erzeugbar sein. Oder ihr könntet es zumindest als Proxy "durchleiten".


    Erklärt aber auch wieso dies damals bei mir nicht ging...

  • Ich vermute mal, dass es hier um den "google-authenticator" für SSH 2FA auf einem Server geht?

    In der URL steht ja das Secret für die 2FA drin und als normaler Query-Parameter landet das dann bei Google in den Logs.

    Das stimmt natürlich (falls man den Link aufruft und annimmt, dass Google das loggt).

    So ein QR-Code sollte doch auch lokal erzeugbar sein.

    Klar, da gibt es CLI Tools wie qrencode. Man müsste eben den Inhalt des QR-Codes aus den Einzelparametern zusammenbasteln und dann als Input an qrencode schicken. Das TOTP-Secret sollte auf dem Server in der ~/.google_authenticator liegen.


    Geben das denn die Datenschutzbedingungen her? Gerade auch nach Schrems II?

    (Keine Rechtsberatung durch mich) Ein TOTP-Secret sollte erst einmal kein personenbezogenes oder personenbeziehbares Datum sein. Also fraglich, ob dies aus Sicht Datenschutz relevant ist. Informationssicherheit ist etwas anderes.


    Und nebenbei: Die DSGVO schreibt nicht vor, dass man jede einzelne Datenübermittlung und jeden einzelnen Empfänger von Daten nennt – es reichen Kategorien. Es muss also nicht zwingend Google hier irgendwie genannt werden, falls es eben überhaupt relevant ist.

  • In den Parametern stehen keine Bezugsdaten. Interessant wäre hierbei der Referrer und andere Header. :/

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Ich vermute mal, dass es hier um den "google-authenticator" für SSH 2FA auf einem Server geht?

    Nein. Es geht um die Erzeugung des QR-Codes im CCP. Hierfür wird ein Service von Google genutzt, obwohl es vermutlich hunderte kostenlose, öffentlich verfügbare Bibliotheken zum Selbsthosten gibt. Ich lehne mich außerdem aus dem Fenster und behaupte, dass sich der Implementierungsaufwand auf nicht mehr als 5 Tage belaufen würde. Wäre mit Sicherheit auch ein schönes Azubi-Projekt.

  • sdellenb bist Du Dir da sicher? Kundennummer?


    janxb hast Du eine alternative zu dem genannten URL?

    z.B. https://chart.googleapis.com/chart?chs=400x400&chld=M|0&cht=qr&chl=otpauth://totp/PayPal:max.mustermann%40moritz.com?secret=HUGO007&issuer=PayPal


    ich selbst nutz das um die so erhaltenen QR-Codes zu 'normen', sprich dass ich dann wirklich im OTP-Generator sehe, was ich sehen will;


    was die Datensicherheit bei Google angeht muss man hier unterscheiden;

    die Daten die z.B. jemand in seinem Gmail Account liegen hat, gelten grundsätzlich als unsicher - Brute Force und ab die Post;

    hingegen die Daten, welche Google generiert - es wurden die Logs angesprochen - die sind sicher;

    spätestens wenn jemand Passwort-Safes udgl. verwendet wo die Safe-Datenbank ohnehin im Internet liegt - klar mit primitivsten Mitteln abgesichert - ist es eher witzlos;


    und die Schwachstelle sitzt sehr oft auch dahinter, die Problematik mit der rethorischen Frage erklärt:

    "was nützt Dir die sicherste Kommunikation mit der Bank, wenn die Bank selbst Dein Geld veruntreut?"


    der Einwand, diese QR-Codes lokal generieren zu können, was meint ihr wie unsicher 2FA damit wird, wenn Sites, sich an Stelle von APIs wie z.B. dem kritisierten URL zu bedienen einfach nur Text präsentieren, und dem Benutzer auftragen, sich das lokal darstellen zu lassen, oder manuell einzugeben;

    ich wette dass es dann genug gibt, die sich so doof anstellen, dass deren Secrets auf Fratze, Zwitscher und sonstigen Nachrichtenseiten landen;:D


    jetzt mal ehrlich, hätt hier netcup einfach einen Apache Host z.B. chart.netcupapis.de gemacht, welcher als 1:1 Proxy zu dem Google Host fungiert, und dann folgenden URL https://chart.netcupapis.de/.... im CCP verwendet, hätt niemand was gesagt;:/


    ich bin durch diesen "Unfall" auf dieses Feature erst aufmerksam geworden;:)

  • hast Du eine alternative zu dem genannten URL?

    Ich verstehe nicht, wo hier das Problem liegen soll. Der von dir genannte Link generiert einfach einen Standard QR-Code für die URL "otpauth://totp/PayPal:max.mustermann%40moritz.com?secret=HUGO007". Jede QR-Code Bibliothek kann solche Codes generieren. Und da sollte es nun wirklich für jede Server- und Clientsprache etwas passendes geben. Wieso man dafür einen externen Anbieter nutzt, erschließt sich mir nicht.

  • Wieso man dafür einen externen Anbieter nutzt, erschließt sich mir nicht.

    genau aus dem selben Grund warum man anderartigen Content von 3rd Party einbindet an statt ihn selbst zu hosten;

    oder anders: warum das 2mal erfinden?


    Der von dir genannte Link generiert einfach einen Standard QR-Code für die ....

    was ist an der Verwendung daran verwerflich?


    oder anders: diese Thematik ist eine Alles od. Nichts Frage und kein "Ja, aber ... " bzw. "Nein, aber ...", sprich: entweder man läßt es gänzlich bleiben 3rd Party zu nutzen, welcher erst am Client zusammengeschustert wird, oder man stößt sich bei dieser Thematik eben nicht daran ...

  • oder anders: warum das 2mal erfinden?

    Vielleicht reden wir aneinander vorbei, aber auch wenn Netcup die Codes selbst generieren würde, würde hier nichts "zwei mal erfunden" werden. Es würde weiterhin eine bereits existierende Bibliothek verwendet, nur verzichtet man auf die unnötige Übermittlung von (sicherheitskritischen) Daten an einen externen Service.


    Und das ist auch schon die Überleitung zu deiner zweiten Frage zum Unterschied gegenüber dem generellen 3rd-party Hosting: Hier wird keine Bibliothek eingebunden (wie z.B. bei einem Javascript-CDN) sondern hier werden echte, kritische Nutzerdaten an einen externen Anbieter übermittelt, der diese verarbeitet. Für mich sind das zwei komplett verschiedene Dinge. Bei meinem Arbeitgeber haben wir über ein externes CDN auch schon nachgedacht, das Einbinden eines externen SERVICES würden wir allerdings aus (m.M.n) guten Gründen in der Form niemals in Betracht ziehen. Zumindest nicht für diesen simplen Einsatzzweck. Hier wird faktisch für das (einmalige) Einsparen von wenigen Personentagen Entwicklungszeit eine (dauerhafte) Abhängigkeit zu einem externen Dienstleister eingegangen, mit dem man darüber hinaus keinerlei Vereinbarungen oder SLAs hat.

  • Hier wird keine Bibliothek eingebunden (wie z.B. bei einem Javascript-CDN) sondern hier werden echte, kritische Nutzerdaten an einen externen Anbieter übermittelt, der diese verarbeitet.

    ich unterscheide hier nicht was eingebunden wird, sondern ob etwas eingebunden wird; entweder man bindet generell NICHTs von Dritten ein,

    oder man akzeptiert das auch bei dieser Thematik;


    und das was Du als kritische Nutzerdaten bezeichnest, hast Du quantitiativ z.B. bei sowas im HTML-Code bei eeiner Seite (nur schematisch)

    <A HREF="anypage.html"><IMG SRC="https://reklamedomain.de/icon.png"></A>

    deutlich mehr; sprich eine Seite anzusehen kommt deutlich öfter vor, als sich einen QR code generieren lassen;


    von daher sehe ich das nicht derart kritisch; weil die Website zeigst mir, die zur Gänze ohne 3rd Party funktioniert:

    keine Fonts, keine APIs, keine Werbung, keine ...; und vor allem kein Tracking;


    und Dein Hinweis, dass sowas ein schönes "Azubi Projekt" ist - 5 Minuten als Projekt zu bezeichnen ist jetzt aber etwas übertrieben :D


    zuerst ein yum install qrencode -y

    bzw. das analoge bei einer anderen Linux Distri, dann einfach einen virt. Host, z.B. charts.netcup.de definieren,

    ein index.cgi mit folgendem Inhalt ins Rootverzeichnis.


    #!/bin/bash

    echo -e -n "Content-type: image/svg+xml\r\n\r\n"

    qrencode -t SVG "$1"


    mit mod_rewrite ein wenig ummodeln, dass des gleich brauchbar ankommt;

    und das wars;


    das Problem: das muss gepflegt/gewartet werden ..., und den Aufwand f. die Zukunft kann jetzt keiner Abschätzen;

  • das Problem: das muss gepflegt/gewartet werden ..., und den Aufwand f. die Zukunft kann jetzt keiner Abschätzen;

    Das muss die externe eingebundene Lösung aber auch. Nur dass man dort keinerlei Einfluss darauf hat, wenn es plötzlich (bei einigen) Usern nicht mehr den erwarteten Inhalt ausliefert. Dann muss man erst unter Zeitdruck irgendwas anderes nutzen oder selbst implementieren…

  • Das muss die externe eingebundene Lösung aber auch.

    aber das macht man auch nicht selbst sondern in dem Fall Google, das ist der Unterschied; egal ob da jetzt sowas wie ich es da als quick and dirty angedeutet habe, verwendet wird od. ein PHP Skript(konvolut); das darfst dann selbst pflegen, und beten/hoffen dass ein yum update -y das nicht ruiniert;;)

    Nur dass man dort keinerlei Einfluss darauf hat, wenn es plötzlich (bei einigen) Usern nicht mehr den erwarteten Inhalt ausliefert.

    dann hat das sicher Ursachen, welche auch nicht unter der eigenen Kontrolle sind; siehe OP

    ich mein, ich kann bei meinem Smartfilter so ziemlich einiges blockieren, und wen mach ich verantwortlich, wenn was nicht geht?8o

  • entweder man bindet generell NICHTs von Dritten ein, oder man akzeptiert das auch bei dieser Thematik;


    und das was Du als kritische Nutzerdaten bezeichnest, hast Du quantitiativ z.B. bei sowas im HTML-Code bei eeiner Seite (nur schematisch)

    Ich versteh das "Schwarz/Weiss"-Denken an dieser Stelle nicht. Ist doch wohl ein erheblicher Unterschied, ob ich ein externes Bild in einer Webseite einbinde oder **sicherheitskritische** Informationen an eine externe Firma weitergebe.


    Soweit ich das richtig verstanden habe, ging es in diesem Post nicht (nur) darum, dass kein externes Bild eingebunden werden soll, sondern, dass das 2FA-Secret nicht nach außen weitergegeben werden soll.

  • Ist doch wohl ein erheblicher Unterschied

    ist es eben nicht; warum?

    weil es ein subjektives Empfinden jedes einzelnen ist, was jeder für sich als "sicherheitskritisch" betrachtet;¹


    (1) es gibt welche, die sehen sich bereits durch die Einbindung jeglichen Inhalts Dritter in deren Privatsphäre gestört;

    (HTTPS macht das nicht besser)


    (2) und andere denen ist das egal; ebenso ob es HTTPS ist oder nicht; einzig bei Electronic Banking achten diese pingeligst darauf;


    (3) und wieder andere empfinden irgendwas dazwischen;


    wie ich ja oben bereits geschrieben habe ...

    hätt hier netcup einfach einen Apache Host z.B. chart.netcupapis.de gemacht, welcher als 1:1 Proxy zu dem Google Host fungiert, und dann folgenden URL https://chart.netcupapis.de/.... im CCP verwendet, hätt niemand was gesagt;


    ¹ es ist auch legithim, wenn jemand ein Electronic Banking, welches sämtliche Techniken die es da so gibt - JavaScript, Cookies, ... - als problematisch ansieht;

    (in den Anfängen hatte ich so ein Electronic Banking, da war die Session im URL, und da brauchte es nur den URL in einem anderen Browser zu öffnen und fortzufahren, wie wenn nichts gewesen wäre)