Am 30. Mai verlieren Sie möglicherweise den Zugriff auf Apps, die eine weniger sichere Anmeldetechnologie verwenden

Zitat von o0Julia0o

Wenn OAuth2 nichts mit unsicheren Apps zu tun hat und ich auf den Link von Google klicke wo Unsichere Apps erklärt werden, dann steht dort: "Zum besseren Schutz Ihres Kontos unterstützt Google ab dem 30. Mai 2022 keine Drittanbieter-Apps oder ‑Geräte mehr, bei denen Ihr Nutzername und Passwort ausreichen, um sich in Ihrem Google-Konto anzumelden."

Quelle: https://support.google.com/accounts/answe…ecure-apps&rd=1

Also somit wäre eine Anmeldung per OAuth2 nicht mehr möglich.

Wie kommst Du darauf? Ich glaube es liegt ein Denkblockade vor... OAuth2 ist eben nicht nur ein Username mit Passwort. Zum Beispiel müssen Cookies aktiviert sein... Es findet auch (beim Aufploppen dieser Anmeldefenster von Google in TB) eine Rücksprache mit dem Server statt, die bei der anderen Variante "Passwort normal/verschlüsselt" nicht statt findet.

Warum sollte Google zum 30.5. eine Anmeldung für Millionen von Usern plötzlich komplett sperren, obwohl der von Google mitentwickelte Standard verwendet wird? Nach deiner Idee das ab 30.5. OAuth2 nicht mehr geht würden nur noch User mit der Gmail App Zugriff auf ihr Konto haben... sonst niemand, auch nicht per Browser (IE,FF,Chrome etc...).

Zitat von o0Julia0o

Widerspricht sich doch. Entweder per Passwort geht es noch, oder nicht.

Widerspricht sich nicht... wie gesagt OAuth2 ist mehr als Passwort und Username, bei der Erstanmeldung wird ein Token gesetzt/Cookies gespeichert usw... das ist mehr als "bei denen Ihr Nutzername und Passwort ausreichen" das fängt damit an das die App OAuth2 unterstützen muss...

Zitat von o0Julia0o

Ich als Hacker habe dein Passwort geklaut.

viel Spaß damit!

Ne ernsthaft: "Früher" (die alte Methode) mit "Passwort normal/verschlüsselt" da hätte das ausgereicht den Usernamen und das Passwort zu haben. Dann muss Google die Mailbox öffnen...

Jetzt bei der neuen Methode (OAuth2) poppt in Thunderbird und auch im Browser (bei mir FF) dieses weiße Anmeldefenster auf... Nutzername... dann Passwort....

Wie gesagt da findet eine Rücksprache statt... bei mir (wo 2FA aktiviert ist) bekomme ich eine Meldung ob ich den Zugriff zulassen will... ohne meine Bestätigung geht es da nicht weiter.

Wenn es jetzt ohne 2FA abläuft... dann checkt Google trotzdem ob der Zugriff Sinn macht. Versuch doch mal ob der Zugriff mit ner chinesischen IP bei Deaktivierung aller Tracker, Cookies auf einem Linux OS klappt.... Das glaube ich kaum!

(Im übrigen sind Hacker ja vielbeschäftigte Menschen, die werden kaum per Hand die Daten eingeben sondern das scripten, alleine die Anmeldegeschwindigkeit wird schon geprüft werden... ob es halt ein netter Mensch oder ein böser Bot ist...)

Zitat von Feuerdrache

ich sehe das ganz entspannt und bin nicht bereit, dass auch nur eine meiner Gehirnzellen wegen des Gockelkontos für meinen androiden Schlaufernsprecher Schaden nimmt.

Vernünftig! Denn genau diese Panik will Google ja... also das man schnell alles angiebt (Telefonummer usw... und am besten zur Gmail App wechselt).

Zitat von Feuerdrache

diese "Warnmails"/"Drohmails" erhält praktischer Weise jeder, der ein Google-Konto sein Eigen nennt. Google wird da keinesfalls individualisieren und bestimmte Personen nicht anmailen. Der Aufwand dieser Differenzierung wird in keinem Verhältnis zum Nutzen stehen.

ALso ich habe die Email nicht bekommen... ich habe aber auch 2FA an und keine unsicheren Apps... Das "personalisieren" sollte ja ganz einfach gehen, alle User die bestimmte Einstellungen nicht haben werden angemailt... nicht alle. Vielleicht werden auch nur die angemailt die ein App-Passwort haben?

So bis die Tage... Grüße dErzOnk

Hier geht es ja munter weiter. OAuth und 2FA werden komplett durcheinander geworfen. So kann man auch Chaos erzeugen.

Zitat von Veteran

Es handelt sich in der jetzigen Form um einen Autorisierungsstandard ohne zusätzliche Authentifizierung.

Das ist technisch nicht richtig dargestellt und hat überhaupt nichts mit dem jetzigen Standard zu tun. Das A in OAuth steht für Autorisierung, nicht für Authentifizierung. Die Authentifizierung ist im Grunde überhaupt nicht Bestandteil von OAuth2. Ich habe oben schon versucht, das zu erklären.

Zitat von Veteran

Jeder im Besitz des Tokens kann somit auf deine Ressourcen zugreifen.

Auch das ist so nicht ganz richtig. Die Tokens werden im Hintergrund zwischen den beteiligten Apps/Servern ausgetauscht. Der Anwender bekommt sie gar nicht zu sehen! Außerdem haben die Tokens eine Ablaufzeit, weshalb nach der Authentifizierung für die Autorisierung auch ein Renewal-Token geliefert werden kann.

Du meinst vermutlich etwas ganz anderes, nämlich den zweiten Faktor der 2FA, der hier vermutlich über ein Cookie realisiert ist. In der Tat kann jemand bei dem Cookie-Verfahren auf das Konto zugreifen, wenn er das Passwort kennt und an den Browser/Thunderbird kommt, auf dem das Cookie gespeichert ist. Das ist aber nichts Besonderes. Bei einer 2FA über SMS oder eine Smartcard ist es nicht anders. Wer an das Smartphone kommt und auch das Passwort kennt, bekommt Zugriff.

Außerdem muss es auch bei der 2FA immer eine Möglichkeit geben, an sein Konto zu gelangen, auch wenn man z.B. sein Smartphone verloren hat. Das geschieht meist über ein weiteres Geheimnis.

Zitat von dErzOnk

OAuth2 ist eben nicht nur ein Username mit Passwort.

OAuth2 ist etwas ganz anderes.

Zitat von dErzOnk

Zum Beispiel müssen Cookies aktiviert sein...

Das ist nur dann der Fall, wenn das über Cookies realisiert ist. Amazon z.B. bietet eine 2FA mit SMS als zweiten Faktor an. Da braucht es keine Cookies, dafür aber ein Telefon. Mein Arbeitgeber verfährt für die Einwahl per VPN ebenso, wahlweise per SMS oder App. Kein Cookie.

Im konkreten Fall hier gehe ich aber davon aus, dass Google nach der einmaligen Authentifizierung ein Cookie setzt. Das stellt dann den zweiten Faktor dar und ist der Ersatz für das Smartphone. Das ist natürlich bequemer, weil man nichts mehr eingeben muss. Es ist deshalb aber nicht automatisch weniger sicher. Man kann sich nur einloggen, wenn man dieses Cookie hat.

Was heißt das jetzt konkret für o0Julia0o? Wenn meine Vermutung stimmt, dass Google OAuth2 unterstützt und die 2FA über ein Cookie realisiert, dann musst du dich einmalig bei Google identifizieren. Das geschieht über dieses 16-stellige App-Passwort. Dann setzt Google in dem verwendeten Thunderbird ein Cookie. Zukünftig erscheint dieses Anmeldefenster dann nicht mehr, weil der Thunderbird eben über das Cookie bestätigt, dass du nicht nur dein Passwort kennst, sondern auch im "Besitz" dieses Thunderbird-Profils bist.

Jemand der deine E-Mails lesen will, muss also an deinen Thunderbird kommen. Selbst wenn er das 16-stellige Passwort kennt, damit allein kommt er nicht an deine E-Mails. Kennt er hingegen das Passwort zu deinem Google-Account, kann er sich dort anmelden und sein eigenes App-Passwort für seinen Thunderbird genieren. Hier lauert eine Schwachstelle. Mit OAuth hat die aber nichts zu tun. Sie ließe sich umgehen, wenn Google für das Erstellen des App-Passwortes zusätzlich zum normalen Login eben auch einen zweiten Faktor verlangt, z.B. per Smartphone, Cookie im Browser oder auch nur eine weitere Sicherheitsabfrage. Ob und wie Google das macht, weiß ich mangels Konto nicht. Ich hatte gehofft, dass das hier jemand erklärt.

Man kann zu Google stehen wie man will, in diesem Fall erhöhen sie durch die 2FA die Sicherheit deutlich gegenüber nur Benutzername + Passwort. Das sollte man zugestehen. Getrolle ist hier wirklich nicht angebracht.

/*

Da es ganz offensichtlich vielen Schwierigkeiten bereitet, OAuth2 und 2FA zu unterscheiden, mir ist noch ein Beispiel eingefallen.

Wenn ich einen Kunden besuche, zeige ich zunächst am Empfang meinen Ausweis vor bzw. geben ihn ab. Dann kommt jemand vom Kunden, der mich kennt, und holt mich ab. Das ist der zweite Faktor, wenn man so will. Er bestätigt, dass ich auch wirklich ins Gebäude gelassen werden soll. Der Ausweis allein genügt nicht. Das wäre also die 2FA. Damit habe ich mich authentifiziert.

Nun darf ich natürlich nicht alle Räume betreten. Deshalb bekommen ich am Empfang einen Besucherausweis. Auf dem steht nur eine Nummer, sagen wir 0815. Mein Name ist darauf nicht zu sehen, auch kein Foto. Im System des Kunden ist hinterlegt, wie lange der Ausweis gilt und welche Räume damit betreten werden dürfen. Komme ich an einen Eingang, halte ich meinen Ausweis an das Lesegerät. Das fragt nun bei einem Server ab, ob der Ausweis überhaupt vom Kunden ausgestellt wurde, ob er zeitlich gültig ist und ob er für diesen Raum gilt. Wird vom Server alles bestätigt, werde ich also autorisiert, den Raum zu betreten. Die Tür öffnet sich. Das wäre OAuth2.

*/

Susi to visit Du schmeißt aber auch 2FA und OAuth2 in einen Satz. Und meine Aussage bezieht sich nur auf Google Mail.

Eigentlich sollte 2FA nicht über das gleiche System laufen erst dann wird es richtig gut.

Um bdas noch mal klar zu stellen für Google Mail und OAuth2 braucht man kein 2FA.

2FA kommt nur ins Spiel weil Google zur Zeit seine Nutzer dazu zwingt dies zu nutzen damit man App Passwörter erstellen kann.

Wie gesagt erst am WE finde ich Zeit dafür das durch zu testen...

Grüße dErzOnk

Zitat von Veteran

Ein App-Passwort ist eine Alternative und keine Voraussetzung für OAuth2,

Ich streite mich nicht mit Leuten herum, die immer noch nicht verstanden haben, was OAuth2 überhaupt ist.

Du solltest mal lesen und versuchen zu verstehen, was ich oben geschrieben habe: Dass das App-Passwort der 2FA dient, nicht OAuth. Streng genommen benötigt OAuth2 überhaupt kein Passwort.

In dem von dir selbst verlinkten Artikel steht ausdrücklich:

Zitat

App-Passwörter können nur für Konten verwendet werden, bei denen die Bestätigung in zwei Schritten aktiviert ist.

Kurz: Keine 2FA - kein App-Passwort.

Ganz egal ob o0Julia0o nun eine Telefonnummer benötigt, was ich nicht glaube, oder ein Cookie, was ich eher glaube, dann deshalb, weil Google 2FA macht, nicht wegen OAuth2. Du hast den Unterschied ganz offensichtlich immer noch nicht verstanden. Ebenso wenig wie die Funktionsweise mit den Tokens.

Tut mir Leute, man kann euren Verwechselungen und Formulierungen ganz deutlich entnehmen, dass ihr echt nicht umrissen habt, was OAuth2 überhaupt ist.

Vermutungen habe ich dazu aufgestellt, wie Google konkret verfährt. Das habe ich auch ganz klar so geäußert, dass das Vermutungen sind. Im Gegensatz zu dir, stelle ich nicht etwas als Tatsache in den Raum, wenn mir die Kenntnis fehlt.

Zu den Themen OAuth und 2FA habe ich die Hintergründe erläutert, weil ganz deutlich wurde, dass das hier völlig durcheinander ging. Da drohte schlicht die Gefahr, dass ihr die Julia und spätere Leser aufs Glatteis führt. Das waren keine Vermutungen, sondern einfach die Gegebenheiten.

Sollte darin ein Fehler meinerseits stecken, dann zeige ihn auf. Da wäre ich dir nicht böse. Bisher gehst du auf die technischen Argumente und deine Fehlaussagen nicht weiter ein. Mehr als ein dummer Spruch war wieder mal nicht drin. Warum wohl?

Egal wie Google es am Ende handhabt, technisch ist es so, dass wenn die Julia etwas zusätzlich benötigt, sei es ein Telefon, eine App oder eben schlicht das Cookie zulassen muss, dann liegt das an der 2FA und nicht am OAuth.

Ferner entsteht eben durch die 2FA ein deutlicher Sicherheitsgewinn, ob du Google nun magst oder nicht, ob dir OAuth gefällt oder nicht. Die 2FA ist etwas Gutes. Hier haben sie anderen Providern etwas voraus.

Da kannst du noch so gegen Google trollen, dumme Sprüche machen und dir Smileys von einem User abholen, der sich zumindest in diesem Forum normalerweise wegduckt. (Warum wohl?). Google macht das besser als viele andere.

Wir machen hier jetzt mal eine Pause bis der 30.05. gekommen ist...

Also wie gesagt, Google lässt weiterhin TB mit OAuth2 zu. 2FA hat damit nix zu tun, man kann weiterhin ein gmail Konto haben und mit TB nutzen, ohne das man seine telefonummer oder eine Emailadresse hinterlegen muss.

Grüße dErzOnk

Und ist was passiert?

Lutz

Zitat von elo22

Und ist was passiert?

Bei denen, die voher schon OAuth/App-Passwort/2FA verwendet haben, vermutlich nichts.

Zitat von dErzOnk

2FA hat damit nix zu tun,

Genau

Das sind zwei Paar Schuhe, auch wenn sie häufig kombiniert werden. So auch bei Google. Nach eigener Aussage verlangen sie mindestens bei der Variante App-Passwort zusätzlich auch die 2FA. Siehe https://support.google.com/accounts/answer/185833

Zitat

App-Passwörter können nur für Konten verwendet werden, bei denen die Bestätigung in zwei Schritten aktiviert ist.

Meines Wissens gilt das auch für die Authentifizierung bei Autorisierung über OAuth. Gelöst über ein Cookie.

Ließe sich leicht testen: Neues Profil, Cookies verbieten, Google per OAuth2 einbinden. Das wird vermutlich nicht funktionieren.

Zitat von dErzOnk

... ohne das man seine telefonummer oder eine Emailadresse hinterlegen muss.

Wenn gar nichts hinterlegt ist, wie lösen sie dann das Problem "Passwort vergessen"? Über eine weitere Sicherheitsabfrage, z.B. "Wie hieß dein erstes Haustier?"

Moin,

so wieder richtiges Internet

Zitat von Susi to visit

Genau

Ja, das wurde auch die ganze Zeit gesagt...

Zitat von Susi to visit

Meines Wissens gilt das auch für die Authentifizierung bei Autorisierung über OAuth. Gelöst über ein Cookie.

Ließe sich leicht testen: Neues Profil, Cookies verbieten, Google per OAuth2 einbinden. Das wird vermutlich nicht funktionieren.

Jetzt schmeißt Du aber was zusammen... Google OAuth ist ohne Cookies in TB nicht möglich, hatten wir hier schon im Forum.

Zitat von Susi to visit

Wenn gar nichts hinterlegt ist, wie lösen sie dann das Problem "Passwort vergessen"? Über eine weitere Sicherheitsabfrage, z.B. "Wie hieß dein erstes Haustier?"

Der Testaccount enthält keine Daten - auch nicht auf welche Schule ich gegangen bin oder wie das Haustier hieß... Für einen Account der wichtig ist würde ich das auf keinen Fall machen aber das Ding geht eh bald in die Tonne.

Wenn keine Daten hinterlegt sind wie in diesem Fall und ich auf "Passwort vergessen" klicke kommt nur:

"Google konnte nicht bestätigen, dass dieses Konto Ihnen gehört."

ENDE... keine Möglichkeit da wieder ran zu kommen...

Aber ist doch immer so, wer ein Hintertürchen braucht weil das Paßwort verloren geht muß halt Google weitere Infos geben (bevor das Paßwort verloren geht.

Grüße dErzOnk

Zitat von dErzOnk

Jetzt schmeißt Du aber was zusammen... Google OAuth ist ohne Cookies in TB nicht möglich

Hallo

bitte lies Dein Zitat noch einmal genau und aufmerksam.

Zitat von Susi to visit

Das wird vermutlich nicht funktionieren.

Du hast es nämlich selbst zitiert.

Gruß Ingo

Zitat von dErzOnk

wer ein Hintertürchen braucht weil das Paßwort verloren geht muß halt Google weitere Infos geben

Nein, eigentlich nicht. Oder besser: Jaein

Du musst nur eine Frage auswählen und eine Antwort dafür festlegen und dir notieren - sie muss aber nicht stimmen.

Du kannst beispielsweise ein völlig deplatziertes oder ein Kunstwort verwenden. Hauptsache, du selber weißt später noch, welche Antwort du gewählt hattest.

z.B.:

Wie hieß deine erste Schule? Erdumrundung.

(meinetwegen auch 'doppelte Periskoptiefe' - die Idee dahinter ist hoffentlich erkennbar )

Wie hieß deine erste Lehrerin? Kaspar Melchior Balthasar.

Wie hieß der Mann der Frau des Malers? Auf einem Baum ein Kuuhukuk, simsalabimbambasaladusaladim

Und so weiter

Klar will Google Infos, die leben davon. Aber wo steht geschrieben, dass die Antworten für diese Passwort-vergessen-Sicherheitsfragen zwingend einen Bezug zur ausgesuchten Frage haben müssten?

Deswegen jaein: Ja, Man muss da etwas eintippen, aber nein, man muss keine validen Infos rausrücken

Zitat von dErzOnk

Jetzt schmeißt Du aber was zusammen...

Nein, das habe ich nun wirklich nicht. Danke schlingo

Zitat von dErzOnk

Google OAuth ist ohne Cookies in TB nicht möglich, hatten wir hier schon im Forum.

Das liegt aber nicht an OAuth. Hier liegt meiner Meinung nach dein großes Missverständnis. Du verwechselst nach wie vor OAuth und 2FA. OAuth benötigt kein Cookie. Das Cookie wird für die 2FA benötigt. Warum braucht man nun bei Google ein Cookie? Weil

Zitat von Susi to visit

In der Praxis kombiniert man beides. Denn es ergibt wenig Sinn, jemandem Rechte einzuräumen, den man nicht zuvor sicher identifiziert hat. Siehe dazu OpenID Connect.

Zum Missverständnis bei trägt auch die Formulierung im Thunderbird. Hier ist von OAuth 2 Authentifizierung die Rede. OAuth authentifiziert aber gar nicht, es autorisiert. Das wird halt nicht unterschieden, weil beides in einem Abwasch erledigt wird.

Google erzwingt nicht das OAuth, sondern die 2FA. Und das ist einer der Punkte, um die es mir geht. Die 2FA erhöht die Sicherheit. Ich gehe Google ja aus dem Weg, wo ich kann, aber das gefällt mir. Ich würde mir wünschen, andere Provider würden es ähnlich machen. Bei uns in der Firma kommt 2FA + OAuth schon seit Jahren zum Einsatz.

Solltest du nach wie vor der Meinung sein, ich würde bzgl. der technischen Aspekte von OAuth und 2FA falsch liegen, dann möchte ich dich bitten, das zu erklären. Ich bin ziemlich sicher, dass ich die Verfahren und ihren Zweck verstanden habe. Ausschließen will ich aber nichts.
Mit erklären meine ich bitte eine technische Begründung, nicht so was wie "OAuth ist mehr als Benutzername und Passwort". Denn wie ich schon schrieb, benötigt OAuth weder Benutzername noch Passwort. Ganz im Gegenteil. Einer der Vorteile von OAuth ist, dass der Dienst, für den man autorisiert wird, weder den Benutzernamen noch das Passwort erfährt.

Zitat von Drachen

Du musst nur eine Frage auswählen und eine Antwort dafür festlegen und dir notieren

Also doch, wie vermutet, die Möglichkeit einer Sicherheitsabfrage. Danke für die Info.

Zitat von milupo

Bist du sicher?

Ja

Zitat von milupo

Also stimmt der Inhalt des folgenden Hilfeartikels nicht?

Doch, der stimmt, weil hier OAuth und die 2FA kombiniert sind. Mir kommt vor, das schreibe ich gerade zum hundertsten Mal.