Werden alle 2FA-Secrets zu Google übermittelt?

  • aber das macht man auch nicht selbst sondern in dem Fall Google, das ist der Unterschied

    So war es aber nicht (nur) gemeint ;-)


    Auch ein extern eingebundenes Bild muss schlimmstenfalls getestet und aktualisiert werden, weil man es sich mit irgendeinem Update unfreiwillig zerstören oder verstecken könnte. Eine Rundumsorgloslösung gibt es dafür nicht.


    So ganz kann ich Deinen Standpunkt bei diesem Thema nicht verstehen. Vor allem, da es um ein 2FA-Secret geht. Wir sprechen hier nicht über irgendwelche Emojis oder Wetterdaten, die extern eingebunden werden. Hier wird aktiv ein String, den definitiv nur zwei Seiten kennen sollen, an eine dritte Stelle weitergegeben. Was dort damit passiert liegt außerhalb des Einflussbereichs der beiden Parteien. Das ist nicht gerade der Sinn von 2FA, außer man verwendet SMS & Co. - da wäre es auch schon fast egal…

  • Auch ein extern eingebundenes Bild muss schlimmstenfalls getestet und aktualisiert werden, weil man es sich mit irgendeinem Update unfreiwillig zerstören oder verstecken könnte.

    das kann Dir auch bei einer selbstentwickelten Lsg. passieren;;)


    So ganz kann ich Deinen Standpunkt bei diesem Thema nicht verstehen.

    um es salopp zu formulieren, bei dem vielen was ohnehin an Google's Daten(-Müll)-Kippe geschickt wird,

    kommt es auf das beim QR code-API auch nicht mehr an;

    mir ist schon klar, was ein 2FA Secret ist, und dass dieser Dritten nichts angeht, aber ist dem auch bei jedem so?


    ich mein, wer einen Passwort-Safe f. 2FA nutzt, der die Datenbank im Netz (Internet) ablegt ¹

    darum hab ich ja oben geschrieben, unterscheidet um welche Daten es sich handelt;

    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;

    bis auf eine hoffentlich überschaubare Menge an Website/System-Admins gilt das generell und nicht nur bei Google;


    ¹ daher: "lege nichts im Netz ab, von dem Du nicht willst, dass es in fremde Hände fällt"

    ls Abschwächung von: "speichere nichts auf Deinem PC², was Du nicht im Netz sehen willst";


    ² das gilt hier auch f. Heizflossen, Eierbretter und sonstige techn. Errungenschaften;


    ja ich bin bei meiner Argumentation nicht speziell auf netcup eingegangen sondern hab es allgemeiner/breiter gesehen; aber ja natürlich soll man derartiges vermeiden, aber es spricht auch nichts dagegen, wenn man ohnehin f. andere Zwecke von Google APIs Gebraucht macht;

    weil sobald man z.B. im Smartfilter Google blockiert, mutiert eine derarige Site ohnehiun in den IE1.0-Modus und ist unbrauchbar³;


    ³ zumindest meine Erfahrung hat dies gezeigt, nachdem ich meinen Smartfilter mittlerweile immer mehr lockern habe müssen, und beinahe bei Lücken wie dem Schweizer Käse angekommen bin;

  • /edit: ich glaube hier stand Unfug. Dann schreibe ich mal was Neues..


    Wir drehen uns anscheinend im Kreis. Ich bin von meiner Meinung überzeugt (natürlich - ist ja auch das Internet!) und deine Argumentation wechselt ständig die Richtung und ist selten besonders ausschweifend. Datenübermittlung nach Extern ohne SLA oder sonstige Regelungen ist ein No-Go. Ich wusste nicht, dass man sich über solche Basics streiten muss. Und da du selbst gesagt hast, dass es sich um wenige Stunden Arbeit handeln würde - wieso dieses Risiko der externen Verarbeitung eingehen?

  • Wir drehen uns anscheinend im Kreis.

    Nö, Du pickst Dir nur einzelnes heraus und das läßt es dann so erscheinen


    darum zusammengefasst: entweder Du verzichtest zur Gänze auf die Einbindung von Content Dritter¹ (vor allem Fratze, Google, Zwitscher, ...), welche erst beim Client zusammengeflickt werden, oder es spielt eben keine Rolle, dass man auch hier auf bereits fertiges Dritter zurückgreift;

    ¹ dazu zählen Images, Clips, CSS, JS.... alles wo Daten an Dritte gehen, ohne dass der User irgend eine Kontrolle hat, und bei Blockierung des Dritten die Seite in den IE1.0-Modus zurückfällt; soll heißen, einzig erlaubt sind das Setzen von Links per <A HREF="https://3rdparty/...">

    Datenübermittlung nach Extern ohne SLA oder sonstige Regelungen ist ein No-Go.

    stimmt, und wieviele Sites unter Beachtung von ¹ darüber kennst Du, bei denen dieser Codex gilt?


    Und da du selbst gesagt hast, dass es sich um wenige Stunden Arbeit handeln würde

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

    und weiter siehe hier: https://forum.netcup.de/anwend…%BCbermittelt/#post154078


    und daher um die Diskussion abzurunden: da ja die Entwicklung von Applikationen immer mehr in Richtung Web-Technologie geht, sollte es Deiner Meinung nach Firmen untersagt sein, derartige Lsg.en Dritten - egal ob kostenfrei od. kostenpflichtig - anzubieten bzw. zur Verfügung zu stellen?

    soll heißen, nicht über die Wirkung bzw. Symptome dass es jemand verwendet - hier netcup, und ich wette auch andere - diskutieren, sondern über die Ursache, dass es überhaupt angeboten wird zu nutzen ...

  • mainziman IMO macht es immer noch einen gewaltigen Unterschied, ob man "nur" ein Grafiken und JavaScript von extern einbindet oder aber beispielsweise Passwörter im Google Passwordsafe ablegt.


    Da kannst du auch noch zehn mal hier schreiben, dass es keinen Unterschied macht :-).


    P.S.: Sollte ich dich missverstanden haben, so kläre mich bitte auf ...

  • cltrmx das ist eine Frage zu welchem Typ Du zählst;

    von welchem Google Passwordsafe sprichst Du hier?

    den nutzt ja eh freiwillig, oder?


    wobei um Deinen ersten Satz aufzusplitten, der gewaltige Unterschied liegt hier:

    durch die Einbindung von "nur" Grafiken und JavaScript nötigst Du andere zur Weitergabe von Daten oder hast eine Seite im IE1.0-Modus8o;

    hingegen wenn Du Deine Passwörter im Google Passwordsafe ablegst, betrifft das einzig und alleine Deine Daten;);

  • Du hast Recht, den Passwordsafe nutzt man freiwillig. Das war vielleicht kein gut gewähltes Beispiel meinerseits.


    Es ist doch trotzdem zu differenzieren, ob du als Anbieter IP-Adressen/User-Agent-basierte Daten bei fremden Firmen ablegst (durch Einbinden von Grafiken/JavaScript/...) oder ob du sensiblere Daten weitergibst.


    Auch du wirst mir zustimmen, dass es bestimmt ein Unterschied wäre, wenn Netcup Schriftarten aus der Google Font API einbinden würde versus wenn Netcup deine Passwörter an Google weitertragen würde. Ich verstehe bei deiner Argumentation schlichtweg nicht, wieso du nicht zwischen "generischen Daten" und "sicherheitskritsichen Daten" unterscheiden kannst.

  • cltrmx das ist alles eine Frage, welcher Typ Du bist;

    und Deine Unterstellung nicht zwischen 'generischen' und 'sicherheitskritischen' Daten unterscheiden zu können, werfe ich damit zurück,

    dass es vielen einfach nicht zugänglich ist, dass auch 'generisch Daten' eine Form von 'sicherheitskritischen Daten' darstellen, Stichwort: Bewegungsprofil;

    (nur weil es nicht der Staat selbst ist, der die Daten erhebt, ist es deswegen nicht harmloser oder zu vernachlässigen)


    darum von der Umkehrung, nutzt ein Website-Admin nichts von Dritten¹, dann hat er auch die Finger von z.B. Google's QR code API zu lassen;

    nutzt er hingegen bereits einiges an APIs von Dritten, dann macht diese Google QR code API das Kraut auch nicht mehr fett;

  • Quote

    und Deine Unterstellung nicht zwischen 'generischen' und 'sicherheitskritischen' Daten unterscheiden zu können, werfe ich damit zurück,

    dass es vielen einfach nicht zugänglich ist, dass auch 'generisch Daten' eine Form von 'sicherheitskritischen Daten' darstellen, Stichwort: Bewegungsprofil;

    Ich stimme dir zu, dass viele nicht verstehen, dass beispielsweise Metadaten auch sicherheitskritisch sein können!


    Du wirst mir aber doch hoffentlich auch zustimmen, dass ein Faktor, der beim Zugang für das Nutzer:innen-Konto benötigt wird, schwerer wiegt, als eine IP-Adresse beim Aufruf einer externen API.

    Quote

    darum von der Umkehrung, nutzt ein Website-Admin nichts von Dritten¹, dann hat er auch die Finger von z.B. Google's QR code API zu lassen;

    nutzt er hingegen bereits einiges an APIs von Dritten, dann macht diese Google QR code API das Kraut auch nicht mehr fett;

    Das sehe ich nicht so. Wie du bei deinen "Typen" schon beschrieben hast, kann man doch hier auch etwas feiner abstufen als "ganz oder gar nicht". Der Punkt ist doch hier, dass Zugangsdaten der Nutzer:innen an Google weitergegeben werden und nicht, dass ein Bewegungsprofil o.Ä. erstellt werden kann.

  • Du wirst mir aber doch hoffentlich auch zustimmen, dass ein Faktor, der beim Zugang für das Nutzer:innen-Konto benötigt wird, schwerer wiegt, als eine IP-Adresse beim Aufruf einer externen API.

    nein da stimme ich Dir nicht zu; wie gesagt, es macht keinen Unterschied ob Du permanent die Datenhalde Google fütterst, und dabei das eine mal vielleicht mit etwas 'besondere' Daten fütterst, mit denen isoliert betrachtet eh keiner was anfangen kann;

    soll heissen, entweder man kann Google rausfiltern, ohne dass die Site in den IE1.0-Modus fällt od. man kann es eben nicht;


    Der Punkt ist doch hier, dass Zugangsdaten der Nutzer:innen an Google weitergegeben werden und nicht, dass ein Bewegungsprofil o.Ä. erstellt werden kann.

    das ist ja eben so nicht richtig, damit ist wirklich 'nur' der 2te Faktor etwas aufgeweicht, wenn überhaupt; wie gesagt, Du vertraust beim Electronic Banking ja auch der Bank, dass sie schon nichts anstellen ...;)


    die Frage ist doch eher: "sollte es Firmen untersagt sein, derartige Lsg.en Dritten - egal ob kostenfrei od. kostenpflichtig - anzubieten bzw. zur Verfügung zu stellen?"


    schon mal der Gedanke gekommen, wäre es so eine Katastrophe wie alle tun, dann hätte doch die EU dem Google Laden das längst untersagt, es innerhalb der EU 'anzubieten' ..., Stichwort: DSGVO

    und noch was: man darf doch bitte niemanden (auch nicht netcup) an den Pranger stellen, nur weil er/sie was fertiges nutzt; und somit Aufwand f. eine eigene Entwicklung, die es damit nicht braucht, gespart hat;

  • Quote

    nein da stimme ich Dir nicht zu; wie gesagt, es macht keinen Unterschied ob Du permanent die Datenhalde Google fütterst, und dabei das eine mal vielleicht mit etwas 'besondere' Daten fütterst, mit denen isoliert betrachtet eh keiner was anfangen kann;

    soll heissen, entweder man kann Google rausfiltern, ohne dass die Site in den IE1.0-Modus fällt od. man kann es eben nicht;

    Okay, dann müssen wir uns wohl darauf einigen, dass wir uns uneinig sind :).


    Quote

    das ist ja eben so nicht richtig, damit ist wirklich 'nur' der 2te Faktor etwas aufgeweicht, wenn überhaupt;

    Korrekt. Aber nach der Logik könnte ich Google ja auch alle meine Passwörter in den Rachen werfen, solange sie nicht meine 2FA-Tokens kenne. Würde ich jetzt nicht unbedingt empfehlen ^^.


    Quote

    schon mal der Gedanke gekommen, wäre es so eine Katastrophe wie alle tun, dann hätte doch die EU dem Google Laden das längst untersagt, es innerhalb der EU 'anzubieten' ..., Stichwort: DSGVO

    Da bringst du jetzt aber was durcheinander: Die API von Google ist mWn. nur dafür da, QR-Code zu generieren. Dass da ein OTP-Token drin landet, liegt ja nicht an Google, sondern an Netcup ;). Sie könnte ja auch für recht ungefährliche Sachen verwendet werden, wie beispielsweise dem Erstellen eines Hyperlinks für öffentliche Webseiten.


    Quote

    und noch was: man darf doch bitte niemanden (auch nicht netcup) an den Pranger stellen, nur weil er/sie was fertiges nutzt; und somit Aufwand f. eine eigene Entwicklung, die es damit nicht braucht, gespart hat;

    Es geht doch in dieser Diskussion nicht darum, dass jemand bemängelt, Netcup würde fertige Dinge benutzen. Es geht darum, dass sensible Daten nach außen weiter gegeben werden ... Es meckert ja auch niemand, dass Netcup beispielsweise keine eigene Virtualisierungslösung für Linux-Hosts implementiert hat.

  • Da bringst du jetzt aber was durcheinander: Die API von Google ist mWn. nur dafür da, QR-Code zu generieren.

    nicht unbedingt; es stimmt schon die QR Codes können f. alles mögliche verwendet werden;

    aber ein Verbot f. einen bestimmten Zweck wäre dann dennoch nach der DSGVO denkbar, wenn es so eine Katastrophe wäre;

    und genau hier muss die Diskussion ansetzen;

    was das anbelangt ist hier ein nahezu rechtsfreier Raum, leider;

    z.B. der QR code auf Zahlscheinen könnte ebenfalls mittels dieses APIs entstanden sein;