Änderung der Login Maske - Probleme Autofill

Komisch bei mir geht 1Password nicht, hast du was besonderes eingestellt?

Mir ist keine Einstellung bekannt, die dabei relevant wäre.

Falls du Vollautomatisch meinst, das geht nicht. Email einfügen lassen, weiter, Passwort einfügen lassen, Login.

Sind halt ein paar Schritte mehr aber ich verwende die Webseite auch nur alle paar Monate mal oder auf fremden Computern.

Könnte der zweiteilige Login zumindest dahingehend geändert werden, dass nach dem Erscheinen des Passwortfeldes dieses automatisch fokussiert wird und man nicht erst rein-tabben oder -klicken muss?

Inzwischen funktioniert mein KeepassXC im 2-Schritt Login. Alle Felder werden automatisch ausgefüllt.

bei mir laedt die seite auch sehr sehr lange.

Ich kann das Problem mit dem langsamen Aufruf der Login-Seite nicht bestätigen. Ich habe es gerade bei mir getestet. Aufruf der Login-Seite aus einem Lesezeichen mit der URL https://login.mailbox.org/ unter einer Sekunde. Also eher deutlich schneller als bisher.

@9974487: Hier ist die Login-Seite unter der genannten URL auch sofort da (macOS/Firefox).

Sind bei dir die mailbox.org-Cookies und -Website-Daten von Löschvorgängen ausgenommen? … (in den Einstellungen des FF-Browsers unter > Datenschutz > Cookies > Ausnahmen verwalten).

- Zitat Peer Heinlein: ”Man bleibt angemeldet. Wenn das bei Dir nicht der Fall ist sieht das danach aus, als ob Dein Browser die Cookies löscht (oder von vornherein alle ablehnt?) und/oder ob Du ein Plugin oder eine Einstellung hast, die diese Cookies sonstwie verhindert. Bitte prüfe hier Deine Browser-Einstellungen und/oder Plugins.”

Ich wäre ja einfach mal für Passkeys.

Woher kommt denn dieser eingeschleuste JavaScript-Code? Und wieso ist es für den schwieriger, die Zugangsdaten abzufangen, wenn die in zwei Schritten bzw. manuell eingegeben werden?

Ich denke 8908805 meint, ein eingeschleuster Code in dem Autofill Addon.

Verstehe ich nicht. Warum sollte sich eingeschleuster Code im Autofill-Addon daran stören, wie die Webseite aussieht?

Der eingeschleuste Javascript kann überall her kommen, entweder durch einen Leak bei mailbox oder durch deinen Browser oder durch ein offenes WLAN. Der eingeschleuste Code braucht nur ein hidden HTML-Textfeld für Benutzername und Passwort machen, welches für dich als User nicht sichtbar ist. Dein Autofill füllt das dennoch aus, da der Autofill auf den HTML-Code geht und diese Felder für valide hält.

Autofill kann dazu beitragen, dich vor gefälschten URLs zu schützen, da diese Funktion nur auf den ursprünglich angegebenen Websites funktioniert. Wenn Autofill also auf Websites, die normalerweise funktionieren, nicht richtig funktioniert, sollten bei dir die Alarmglocken läuten. Grundsätzlich handelt es sich dabei um einen Balanceakt: Wenn der Login zu bequem ist, kann dies unsicher sein, aber wenn es zu sicher ist, wird es vielleicht nicht genutzt, da zu lästig.

Ein Leak bei mailbox.org hätte deutlich dramatischere Auswirkungen als die, dass jemand mein Passwort auf der Login-Seite klaut.

Mein Browser ist ein signiertes Firefox-Paket. Wo genau kommt da das eingeschleuste JavaScript her?

Und dass man über ein "offenes WLAN" in meine TLS-Verbindung zu mailbox.org eingreifen kann wäre mir auch neu.

Der Leak kann ja in einem Javascript oder anderweitigen Framework sein, der eben nur auf das Abgreifen von Passwörtern aus ist.

Ob der Firefox ein signiertes Firefox-Paket ist oder nicht ist egal, es kommt ja auf Erweiterungen/Add-Ons an.

Selbstverständlich kannst du in ein em (eigenen|fremden) WLAN eine TLS-Verbindung brechen. SSL-Inspection nennt sich das bzw (hat auch andere euphemistische Begriffe).

Hier wird echt viel durcheinandergeworfen, ich versuche das mal zu sortieren.

Ja, ganz generell ist es eine schlechte Idee, kompromittierte Software zu verwenden. Ganz egal ob es sich dabei um eine Extension, den Browser an sich oder gar das Betriebssystem handelt. Aber zu sagen "Nutze keinen Passwortmanager, der könnte kompromittiert sein" geht mir echt zu weit. Solange die Software aus vertrauenswürdigen Quellen stammt, sehe ich erst einmal kein Problem.

Kommen wir zum Autofill, jetzt mit der Annahme, dass die Software auf meinem Rechner vertrauenswürdig ist. Dann sehe ich höchstens das Problem, dass JavaScript in einer HTML-Mail ein Formular anzeigt und das automatisch per JavaScript abschickt, sobald dort per Autofill Daten drin landen. Wer also der HTML-Anzeige bei mailbox.org nicht zutraut, externe Dateien zu filtern, sollte den Autofill auf login.mailbox.org beschränken.

In keinem der beiden Szenarien bringt die Umstellung der Login-Maske irgendeinen Sicherheitsgewinn, wenn es um Autofill geht. Spätestens wenn das Passwort per Hand eingegeben wird, kann es ja abgegriffen werden, wenn eine Lücke da ist.

Und noch ein Wort zur SSL Inspection: Das setzt voraus, dass jemand den Zertfikatsspeicher meines Browsers anpassen kann und ist eher da zu verorten, wo man verschlüsselte Verbindungen zwecks Diagnose wirklich aufbrechen will.

Um vielleicht meinen "Problem" an der Stelle zu korrigieren. Ich nutze keine Add-On oder sonstiges, sondern nur die "autotype" Funktion von in dem Fall keepass. Heißt, ich drück’ ne Tastenkombination und die Daten werden (sogar mit Two-Channel Auto-Type Obfuscation) übertragen.

Das sehe ich doch als recht sicher, im Vergleich zum Manuellen rüberkopieren.

Und genau das geht seit dem neuen Login nicht mehr richtig. Aber nur hier mit der neuen Maske ist es problematisch. Andere Websites, die ein ähnliches Login haben, haben das anders aufgebaut und dort ist es kein Problem.

Ein Browser Add-on für Passwörter zu benutzen sehe ich aber auch als eher kritisch.

Das Thema ist ja durchaus interessant und wir verlassen hier ein wenig den OT, aber dafür ist es ja auch ein eigener Sub-Thread.

Ich kann allerdings nicht nachvollziehen, was hier "durcheinandergeworfen" würde, aber ich antworte mal auf einzelne Angaben:

Kompromittierung Software/Framework/SaaS-Anwendung

• Ob eine Software oder ein Framework der SaaS-Anwendung kompromittiert ist, kannst du als Nutzer kaum erkennen, inbesondere bei letzterem (nehmen wir mal NPM oder ssl-lib/openssl 3, curl oder eben auch M365 mit dem Key-Verlust durch MS).
• Es wurde auch (von mir) nicht behauptet, irgendein Passwort-Manager sei kompromittiert. Andere Antworten, die so etwas sagen, sehe ich auch nicht? Auf was bezieht sich diese Aussage? Auch ob ein Passwort-Manager gut ist oder nicht, habe ich nicht getroffen - dass man einen Password-Manager nutzt, ist bei der Verwendung von User/Pass für mich eine Selbstverständlichkeit, wobei ich zertifikatsbasierte Logins bevorzuge.
  

• Bei meinen Ausführungen ging es darum, ein Autofill durchaus Gefahren bergen kann.
• Dies insbesondere wenn auf der SaaS-Anwendung bspw. eine Kompromittierung vorliegen könnte - entweder im eigenen Script oder aber in eingebundenen Scripten/Frameworks (nehmen wir bspw. das allseits beliebte NPM). Das gleiche gilt aber auch für weitere im Seitenaufbau eingeladenen Scripte (bspw. Webseanzeigen, etc.), all diese Scripte haben Zugriff auf die Inhalte im aktuellen Tab. Das bekommt der Benutzer aber aktiv kaum mit, er kann also kaum abschätzen, ob etwas kompromittiert ist und woher und inwiefern.
• Die Kompromittierung kann auch bei Add-Ons im Browser vorliegen (bspw. in beliebten Plugins wie FlagFox oder AdBlocker oder Preisvergleichs-Inclusion). Denn Add-Ons bekommen in den meisten Fällen Vollzugriff auf den Tab und den Inhalt. Um diesen Angriffs-Vektor einzuschränken gibt es ja die offizielle Mozilla-Add-Ons-Seite (obwohl da der Quelltext tatsächlich anders als bspw. im Apple-App store nicht geprüft wird). Firefox bspw. erlaubt neuerdings (seit Firefox 116) den SaaS-Betreibern (also der Webseite) deine Add-Ons im Browser aus sicherheitsgründen zu deaktivieren (die Seite xyz.de könnte also dein Ad-Blocker deaktivieren, wenn es dieses Add-On für unsicher hält).
  

Autofill und Password-Manager

• Nochmals: dass man einen Password-Manager nutzt, ist bei der Verwendung von User/Pass für mich eine Selbstverständlichkeit, wobei ich zertifikatsbasierte Logins bevorzuge.
• Mit einem Passwort-Manager deckst du ja 2 Nutzergründe ab: Einfgache Passwortverwaltung und Schutz vor unerlaubtem Zugriff auf deine Credentials. Der Passwort-Manager soll also den Agriffsvektor mitigieren, dass du deinem System nicht traust und es als unsicher einstufst.
• Diese Sicherheitsannahme sollte natürlich nicht nur für dein lokales System gelten, sondern erst Recht für Systeme (SaaS-Dienste) außerhalb deines Radiuses (there be dragons). D.h. eigentlich wäre die folgerichtige Annahme: jeder SaaS-Dienst/Add-On und der Transportweg könnte potentiell kompromittiert sein.
• Den Transportweg kannst du gegen dem Angriffsvektor (Unerlaubter Zugriff durch Dritte) durch SSL versuchen abzuschirmen. Das ist grds eine taugliche Maßnahme, wenn du den Transportweg einigermaßen bestimmen kannst (dein Internet bspw.) - bei einem freien WLAN wird das schwieriger (siehe unten: SSL-inspection)
• Beim Inhalt (Seiteninhalt, Anmeldeseite) hast du aber kaum noch Kontrolle. Zwar kannst du versuchen sicherzustellen, dass bspw. alle Add-Ons deaktiviert sind und dein Browser aus einer vertrauenswürdigen Quelle geladen wird - aber was heißt das im Fall der Fälle? (das war ja bei curl/openssl und npm auch). Aber unabhängig davon muss du dem SaaS vertrauen beim Login bzw. auch den dort eingebundenen Frameworks/Scripten (unabhängig jetzt mal auch von mailbox.org) - aber auch mailbox.org setzt auf ein zugekauftes Produkt (bindet externe Frameworks/Scripte auch lokal ein, dazu dann auch später).
  

• Selbstverständlich kannst du dem Passwort-Manager sagen, er solle nur einen Autofill auf eine bestimmte Domain ausführen, aber: Änderungen am HTML-Quelltext (bspw. einer Login-Seite) nachdem diese im Browser geladen wurde sind keine andere Domain (mehr). Durch ein präpariertes Javascript (bspw. über Ad-Script oder Framework - welches insbesondere lokal eingebunden wurde wie bspw. jQuery etc.) oder Add-Ons kann ich den Quelltext der Login-HTML-Seite der erlaubten Domain verändern und ein eigenes Login-Form einbinden. Das Login-Form braucht auch nicht aktiv zu senden, sondern ich kann die Daten bspw. per Javascrpit über einen Event_Manager auslesen. Das Form wird auch versteckt, ist also nicht sichtbar für den Nutzer. Bei einem Autofill wird es aber ausgefüllt, da es für den Autofill ein valides Login-Form ist.
• Ein händisches Kopieren/Einfügen schützt dich zumindest vor diesen versteckten Login-Feldern. (bei Keepass ist das ja auch nur ein Doppelklick auf das Passwortfeld und das Passwort ist für 12 Sek im Zwischenspeicher und kann ins Anmeldefeld eingefügt werden).
  

2-Schritt-Login

• Selbstverständlich schützt ein 2-Schritt-Login nicht vor diesem Angriffsvektor des Autofills. Das hat aber mE bisher keine in diesem Thread behauptet.
  

• Ein 2-Schritt-Login schützt aber vor anderen Angriffsvektoren oder kann diese zumindest erschweren:
• Verhinderung der Benutzernamenermittlung: Indem zuerst der Benutzername oder die E-Mail-Adresse angefordert wird, kann das System erkennen, ob ein gültiges Benutzerkonto mit diesem Benutzernamen oder dieser E-Mail-Adresse verknüpft ist. Wenn ein Benutzername im System nicht existiert, kann der Login-Prozess gestoppt werden, wodurch das Risiko automatisierter Angriffe verringert wird, die versuchen, gültige Benutzernamen zu erraten.
  
• Begrenzung der Zugriffsrate und Kontosperre: Nachdem der Benutzername übermittelt wurde, kann das System Richtlinien zur Begrenzung der Zugriffsrate oder zur vorübergehenden Sperrung von Benutzerkonten durchsetzen. Zum Beispiel kann das System ein Konto vorübergehend sperren, wenn es zu viele fehlgeschlagene Login-Versuche für einen bestimmten Benutzernamen gibt, was es für Angreifer erschwert, Brute-Force- oder Credential-Stuffing-Angriffe durchzuführen.
  
• Phishing: Während nicht narrensicher, kann der zweistufige Prozess Phishing-Angriffe etwas erschweren. Phishing-Websites versuchen in der Regel, sowohl Benutzernamen als auch Passwörter in einem einzigen Schritt abzufangen. Durch die Aufteilung in zwei Schritte haben Benutzer die Möglichkeit, Unstimmigkeiten zwischen der besuchten Website und dem erwarteten Verhalten zu erkennen.
  
• Verringerte Anfälligkeit für Credential Spraying: Credential-Spraying-Angriffe beinhalten das Ausprobieren einer kleinen Anzahl häufig verwendeter Passwörter mit einer großen Anzahl von Benutzernamen. Die Anforderung eines gültigen Benutzernamens vor dem Versuch eines Passworts kann dazu beitragen, solche Angriffe zu minimieren.

SSL-Inspection

SSL-Inspektion kann auch ohne Änderungen an den Zertifikaten im Browser des Clients durchgeführt werden, indem sogenannte "SSL-Bypass" oder "SSL-Passthrough" Techniken verwendet werden.

Grds interessante Themen, mir ging es aber mehr darum, dass ich den 2-Schritt-Login vorteilhaft finde (wenn der SaaS-Anbieter dazu die o.g. Maßnahmen ergreift - wenn nicht, dann ist das natürlich eher schlechte UX) und, dass Autofill durchaus Angriffsvektoren eröffnet.

Allerdings muss man natürlich auch sagen, dass ich sowieso keinen Grund für PAssword-Manager beim Login sehe bei mailbox.org, da jeder doch 2FA aktiviert hat, oder?

Andererseits ist 2FA ja (leider) nur auf den Weblogin beschränkt, da es (derzeit) keine 2FA oder Session-Auth oder App-Passwörter gibt, d.h. trotz 2FA kann man natürlich mit User/Pass per IMAP/SMTP und CalDAV/CardDAV/WebDAV auf die Dienste zugreifen, 2FA schützt bei mailbox.org (derzeit) also nur eine mögliche Anfälligkeit des Weblogins.

Gibt es hier eigentlich die Möglichkeit zum Zitieren? Das wird sonst echt unübersichtlich. Aber versuchen wir es mal...

Es wurde auch (von mir) nicht behauptet, irgendein Passwort-Manager sei kompromittiert. Andere Antworten, die so etwas sagen, sehe ich auch nicht? Auf was bezieht sich diese Aussage?

Ich beziehe mich auf "Ich denke 8908805 meint, ein eingeschleuster Code in dem Autofill Addon."

Selbstverständlich schützt ein 2-Schritt-Login nicht vor diesem Angriffsvektor des Autofills. Das hat aber mE bisher keine in diesem Thread behauptet.

Dann verstehe ich Deinen Einstieg in das Thema nicht, denn genau da bringst Du die beiden Themen ja zusammen:

Ich wäre stark dafür, dass der 2-Schritt übrigend beibehalten wird. Autofill ist zudem nämlich absolut unsicher, da braucht es nur einen eingeschleusten Code (Javascript) und der greift dann die Zugangsdaten im Klartext ab.

Zu SSL Inspection:

SSL-Inspektion kann auch ohne Änderungen an den Zertifikaten im Browser des Clients durchgeführt werden, indem sogenannte "SSL-Bypass" oder "SSL-Passthrough" Techniken verwendet werden.

Da geht es aber um Analyse von Datenverkehr und nicht das Einschleusen von JavaScript-Code, wie Du weiter oben behauptet hast.

"Dann verstehe ich Deinen Einstieg in das Thema nicht, denn genau da bringst Du die beiden Themen ja zusammen:"

Nein, ich sage einerseits, dass ich die 2-Schritt-Lösung gut finde. Zudem beziehe ich mich darauf, dass ein Autofill grds auch einen Angriffsvektor eröffnet. Das habe ich ja auch mehrfach nun oben beschrieben. Allerdings ist im OT ja beides auch verknüpft.

"Da geht es aber um Analyse von Datenverkehr und nicht das Einschleusen von JavaScript-Code, wie Du weiter oben behauptet hast."

Für was der Verwender die Technik verwendet, weist du doch gar nicht. Das nennt man dual-use. Natürlich kannst du mit einem Messer Äpfel schneiden, aber du kannst sie auch für etwas anderes verwenden. Aber ist das jetzt echt der Aspekt, den wir hier noch klären müssen, den dual use von Technik?

Wenn das die Thematik wäre, dann bräuchten wir uns gar nicht über mögliche kompromittierte Systeme unterhalten, denn ein Browser/Add-On ist ja nur zum surfen da - wer (potentieller Angreifer) würde da schon was anderes mit machen wollen (Daten abgreifen?)?

Nein, ich sage einerseits, dass ich die 2-Schritt-Lösung gut finde. Zudem beziehe ich mich darauf, dass ein Autofill grds auch einen Angriffsvektor eröffnet.

Okay, also zwei getrennte Themen. Hatte ich anders verstanden. Dann hätte man sich die Diskussion auch sparen können. :)

Für was der Verwender die Technik verwendet, weist du doch gar nicht. Das nennt man dual-use.

Du hast behauptet, man könne damit JavaScript einschleusen, also den Datenverkehr ändern (schreiben). Deine Quellen beziehen sich aber darauf, dass man den Datenverkehr höchstens analysieren (lesen) kann. Und selbst beim Lesen geht es ja vermutlich nicht um die Klartextinhalte.

Wäre es anders, bräuchten wir TLS nicht.

Du hast behauptet, man könne damit JavaScript einschleusen, also den Datenverkehr ändern (schreiben). Deine Quellen beziehen sich aber darauf, dass man den Datenverkehr höchstens analysieren (lesen) kann. Und selbst beim Lesen geht es ja vermutlich nicht um die Klartextinhalte.

Erstmal geht es darum, dass du die SSL-Verbindung brichst (MITM). Ob dann das Tool, was die Verbindung bricht auch die Inhalte verändert ist ja eine andere Frage. Zu dem Zeitpunkt hast du ja jegliche Möglichkeit über den Traffic.

Wäre es anders, bräuchten wir TLS nicht.

Richtig, TSL soll dir erstmal eine Grundsicherheit bieten. Aber da die meisten Schadprobleme mittlerweile über SSL-Verbindungen kommen, gibt es eben auch entsprechende Tools, um SSL/TLS zu brechen, um den Traffic auf Schadprobleme zu untersuchen. Nur die Software/Tools kann man eben auch für andere Zwecke verwenden, auch wenn diese bestimmte Zwecke nur vorbereiten/unterstützen. Heißt also: SSL/TLS ist ein wichtiger Baustein für eine Transportsicherheit, aber blindes Vertrauen darauf wäre falsch, insbesondere, wenn man in fremden Netzen unterwegs ist.

Erstmal geht es darum, dass du die SSL-Verbindung brichst (MITM). Ob dann das Tool, was die Verbindung bricht auch die Inhalte verändert ist ja eine andere Frage. Zu dem Zeitpunkt hast du ja jegliche Möglichkeit über den Traffic.

Du lässt das in der Diskussion so klingen, als wäre das "Brechen" der TLS-Verschlüsselung eine Kleinigkeit. Ist es eben nicht, sondern stellt Angreifer vor extreme Hürden. Schließlich ist das Protokoll genau dafür gemacht, über potenziell unsichere Leitungen unter der Möglichkeit von MITM-Attacken sichere Kommunikation zu gewährleisten.

Mal ganz konkret: Wenn ich mich in ein von Dir betriebenes offenes WLAN einlogge und dort per unmodifiziertem Browser mailbox.org aufrufe, wie genau willst Du an der Verbindung Veränderungen vornehmen, ohne dass in meinem Browser alles voller Warnungen ist?

Welche Warnungen sollte dein Browser denn aus welchem Grund auswerfen wollen? Wegen HPKP? Das wäre tatsächlich dann hart, das zu umgehen, aber das hat Google ja selbst beerdigt. HSTS? Dass muss konfiguriert sein vom Ziel-Host und du musst den in der Kombi schon mal aufgerufen haben und max-age darf nicht abgelaufen sein. Mailbox.org hat HSTS und max-age=15768000, das ist derzeit gut. Und was meint unmodifiziert? Kein Add-on (https://www.rfc-editor.org/rfc/rfc6797#section-5.3)?

Und nochmal: mir geht es bei SSL-inception nicht um mailbox.org, sondern um die Technik an sich. (Habe ich ja mehrfach deutlich geschrieben, dort ging es um das generelle Auto-Fill und die möglichen Angriffsvektoren, wie wir in den Replys auch schon nun mehrfach festgestellt haben). Und natürlich ist das ein Aufwand - deswegen nimmt sich ein potentieller Angreifer ja auch lieber die Supply Chain als einen Rechner eines Nutzers. Mehr Interessantes kann man zum Thema Levono Superfish nachlesen.

Welche Warnungen sollte dein Browser denn aus welchem Grund auswerfen wollen?

Am naheliegendsten in einem "bösen" WLAN wäre ja ein DNS-Server, der mir falsche Adressen liefert. Und da würde sich mein Browser beschweren, dass das Zertifikat nicht passt.

HSTS?

Unnötig, da ich https selbst eintippe oder einen Bookmark nutze.

Und was meint unmodifiziert?

Soll heißen: Vertrauenswürdige Installation, niemand hat am Zertifikatsstore rumgefummelt.

Mehr Interessantes kann man zum Thema Levono Superfish nachlesen.

Zählt für mich nicht als "vertrauenswürdige Quelle von Software".

Am naheliegendsten in einem "bösen" WLAN wäre ja ein DNS-Server, der mir falsche Adressen liefert. Und da würde sich mein Browser beschweren, dass das Zertifikat nicht passt.

Aber nur bei HSTS.

Der Browser überprüft die Zertifikate nicht sofort auf Übereinstimmung mit einer IP-Adresse während der ersten Verbindung. Die IP-Adresse ist mit dem Server verknüpft, zu dem der Browser eine Verbindung herstellt, und der SSL/TLS-Handshake erfolgt nach der Initialisierung der Verbindung.

Der Browser fordert das Zertifikat vom Server nach der Initialisierung der Verbindung an. Während dieses SSL/TLS-Handshakes, überprüft der Browser das Zertifikat auf Übereinstimmung mit dem Domänennamen (nicht der IP-Adresse).

Und das einzige, was dich da retten kann ist HSTS.

Um das nochmal zu verdeutlichen: der Browser führt während des SSL/TLS-Handshakes die folgenden Überprüfungen durch:

• Übereinstimmung der Domain: Der Browser überprüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) im SSL-Zertifikat mit der von Benutzer versuchten Dimain übereinstimmt. Das wurde ja gefaked (dns redirect).
• Gültigkeit des Zertifikats: Der Browser überprüft, ob das Zertifikat in Bezug auf sein Ablaufdatum und seinen Widerrufsstatus gültig ist. Das kann bei einem gefakted Cert auch in Ordnung sein.
• Zertifikat-Vertrauenskette: Der Browser überprüft, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert ist oder ob es selbstsigniert ist. Auch das gab es ja in der Vergangenheit, dass das als Fake klappte bzw das Certificate eben in der Chain valide war.
• HSTS: Wenn HSTS aktiviert ist, wird der Browser die Verbindung nicht akzeptieren, selbst wenn das Zertifikat technisch gesehen gültig ist.

Und das einzige, was dich da retten kann ist HSTS.

Wo genau ist der Unterschied zwischen HSTS und meiner manuellen URL-Eingabe mit https-URL-Schema? Genau das sollte ja dafür sorgen, dass jegliche Daten vom Server mit einem korrekten Zertifikat signiert sind.

Auch das gab es ja in der Vergangenheit, dass das als Fake klappte bzw das Certificate eben in der Chain valide war.

Verstehe ich das richtig, dass Dein Angriffsszenario beinhaltet, dass der Angreifer ein Zertifikat hat, das von meinem Browser akzeptiert wird?

dem stimme ich zu. irgendwie bin ich etwas enttäuscht von mailbox.org.

Das könnte natürlich auch genau so gewollt sein: Änderung der Login-Maske durch zusätzlichem Klick und ohne Passwortfeld-Auswahl, um automatisierte Login Versuche - Brute-Force bspw - möglichst zu unterbinden...

_😂_

Jau, das ist sind sog. layered security controls. Find ich gut, dass das auch für Webmail umgesetzt wird. Wird seit 2003 in den USA für Banken vorgeschrieben. Da (web)mail mittlerweile auch relativ sensible Inhalte haben kann und hier zudem noch nen Cloud-Account hinterhängt, find ich das echt super!

Weiter so mit dem getrennten Login!

Jetzt bin ich interessiert, was soll das denn bringen? Ob der Login nun auf einer oder zwei Seiten eingegeben wird, sollte doch keine wirkliche (Security-)Relevanz haben, oder?

Der Großteil der Seiten, die so was machen, machen das, weil sei multitenant-fähig sind, z.B. Microsoft Entra ID / Azure AD, wo dann Firmenfarben und -logo sichtbar werden, wenn man eine Firmenmail nimmt. Oder bei Diensten, wo dann je nach Tenant ein anderer SSO-Service für das Passwort benutzt wird.

(Und so scheint es aktuell auch bei mailbox.org zu sein, wenn man zwischen den Zeilen liest. Meine Spekulation: Bestimmte (vermutlich interne) Nutzer werden bereits auf Keycloak zur Authentifizierung weitergeleitet.)