Willkommen im User-Forum von mailbox.org
 

Anwendungsspezifische Passwörter

8592164 hat dies geteilt, 3 Jahren her
unbeantwortet

Hallo,


ich vermisse die Option 2FA zu aktivieren und dann jedoch zusätzlich jeweils ein anwendungsspezifisches Passwort für alle Nicht-WebClients einrichten und verwenden zu können. So war ich es von Yahoo und Google-Mail gewohnt.


Denn, was bringt mir 2FA wenn es nur für das Webinterface greift. Die Option nur noch das Webinterface zu verwenden ist für mich keine.


Bitte um eine Auskunft dazu.


Grüße

Adam Engelhard

Kommentare (3)

Foto
1

Hallo,

anders als bei Google & Co meldet man sich hier bei aktivierter 2FA am Webinterface nicht mit Passwort + OTP sondern mit einer PIN + OTP an. Das Passwort hat somit nichts mehr mit dem Webinterface zu tun und wird nur noch für Apps genutzt. Man hat damit (ein frei wählbares) Passwort das wie anwendungsspezifische Passwörter nur noch von Apps benutzt wird.

Foto
1

Hallo


bei Google & Co. ist das anwendungsspezifische Passwort nur mit einer Anwendung gültig und nicht übertragbar, so verstehe ich es. Hier könnte ich mir irgendein Webclient einrichten und vorausgesetzt meine Email und Passwort ist bekannt, kann doch so die 2FA einfach umgangen werden? Oder nicht?


Grüße

A.Engelhard

Foto
1

Hallo,

soweit ich das verstehe ist das genannte Angriffsszenario möglich. Ob und was mailbox.org hier tun könnte weiß ich nicht da das bei Google entweder über die OAuth Technologie oder über Tracking der Geräte funktionieren muss, da ja ein anwendungsspezifisches Passwort ohne das Wissen zu welchem Gerät / App es gehört ja auch wiederverwendet werden könnte. Und da Tracking der Geräte bei einem Anbieter der sich Datenschutz auf die Fahnen geschrieben hat ist problematisch, ist also auch ein klassischer security/privacy trade-off.

Die andere Frage ist wie hoch man das Risiko einschätzt das jemand an das Passwort kommt. Da das Passwort nicht mehr für den Web Log-in nutzt und damit das Passwort nicht auf fremden / öffentlichen / unsicheren Rechnern in Umlauf kommen kann bleiben als Risikofaktoren noch die eigenen Geräte und verwendeten Apps übrig. Ein gewisses Risiko bleibt, ist aber deutlich reduziert.

Ich persönlich glaube das es schon ein guter Schritt wäre wenn man verschiedene Passwörter für die verschiedene Dienste (also IMAP, CalDav, CardDav, WebDav, ...) hätte da man so nicht jeder Anwendung Vollzugriff gewähren müsste.

Aber im Moment ist es wie es ist und ob / wie man damit zurechtkommt muss am Ende jeder für sich entscheiden.

Gruß

jmr

Foto
1

nicht ganz, mann muss sich zum Beispiel im Browser mit dem Passwort anmelden um das Forum zu nutzen.

Foto
1

Hallo,

Es ist sein sehr altern Frage die hier gestellt wurde. Aber für mich immer noch Aktuell. Leider gibt es unter mailbox.org immer noch keine Möglichkeit "Anwendungsspezifische Passwörter" zu erstellen.

Finde es Kritisch habe meine Mailadresse in diversen Geräten hinterlegt (Fritzbox, Drucker usw.). Deswegen nutze ich für die Geräte auch nicht meine mailbox.org Adresse. Sondert GMX Adresse die auch Anwendungsspezifische Passwörter erlaubt.

Vielen ist es nicht bekannt aber die meisten Browser oder Mail Programme (z.B. Chrome, Firefox oder Thunderbird) speichert die Adresse auf den PC nicht verschlüsselt. Nur bei Firefox und Thunderbird ist die Verschlüsselung erst aktiv, wenn man ein Masterpasswort gesetzt hat. Ein tolles Einfallstor für Hacker


Es wäre richtig und Wichtig, wenn man mailbox.org auch diese Option anbietet.


Gruß

Foto
1

Welchen Sicherheitsgewinn hättest Du bei dem Szenario denn durch anwendungsspezifische Passwörter? Wenn ein solches auf der FritzBox hinterlegt ist und dort "geklaut" wird, hat der Angreifer Zugriff auf Dein gesamtes Postfach.

Der eigentliche Sinn dieser Passwörter ist ja, Clients einzubinden, die mit 2FA nicht umgehen können.

Foto
1

Wie immer das technisch läuft - Token, webauth-Dingensens, FIDO2-Voodoo - die anwendungsspezifischen Passwörter von web.de oder Google funktionieren meiner Erfahrung nach genau in der einen Mail-App-Instanz, in der sie zum ersten Mal genutzt werden, in keiner anderen. Das sind hier Airmail unter macOS und iOS, Thunderbird und Outlook unter Win10 und MacOS und die jeweiligen OS-eigenen Mail-Apps. Und schon ein größeres Update der App kann dazu führen, dass man über das jeweilige Web-Interface ein neues erzeugen muss. Insofern: web.de und Google können es, und GMX mWn auch.


Es wäre schon toll, wenn Herr Henlein oder irgendwer, der sich dazu berufen fühlt, mal erklären könnte, warum der hier seit Jahren geäußerte Wunsch nach appspezifischen Passwörtern oder auch nach FIDO2/Webauth-Unterstützung mailbox's Ansicht nach offenbar Quark ist und deshalb nicht umgesetzt wird.

Foto
2

@Stephan bzw. Hallo Zusammen:

Je nachdem wie die Umsetzung solcher Passwörter ist, hat man einen sehr hohen Sicherheitsgewinn. Man kann diese natürlich auch nach Protokoll filtern (sprich App-Passwörter für SMTP only, Cal/Card-DAV only usw.).

Weiter hat man bei App-Passwörtern das Vorteil, dass die Clients (Mailclients usw.) nur das zugehörige App-Passwort haben. Beim Auslesen, stehlen usw. der Devices kann der Mail-Account-Inhaber das einfach und schnell löschen. Und das ohne das man Zugriff auf den Account hat bzgl. Übernahme (App Passwörter haben kein Zugriff auf Admin-Interface).

Somit hat man einen enormen Sicherheitsgewinn!

Eine nahezu mustergültige Umsetzung bzw. Erklärung (zumindest in der Logik und Vorgehensweise - über den techn. Background kann und will ich nicht urteilen) ist hier zu finden:

https://www.fastmail.help/hc/en-us/articles/360058752854-App-passwords

Foto
6

Es wäre schon toll, wenn Herr Henlein oder irgendwer, der sich dazu berufen fühlt, mal erklären könnte, warum der hier seit Jahren geäußerte Wunsch nach appspezifischen Passwörtern oder auch nach FIDO2/Webauth-Unterstützung mailbox's Ansicht nach offenbar Quark ist und deshalb nicht umgesetzt wird.


Ich habe mehrfach öffentlich erklärt und anderswo auch ausführlicher erläutert, dass wir appspezifische Passwörter als sehr toll empfinden und sehr gerne hätten. Von "ist offenbar Quark" kann keine Rede sein. Ebensowenig kann von "deshalb nicht umgesetzt wird" die Rede sein.

Wir haben bei mailbox.org in Sachen Authentiizierung nur eine sehr komplizierte und vor allem extrem sichere Architektur. Dazu gehört, dass unsere Server selber an Passwortdaten nicht rankommen, sondern die Credentials des Users brauchen, um sich ihrerseits zu authentifizieren. Und LDAP bietet keine Möglichkeit, diese Verfahren mit mehreren Passwörtern zu machen. Wir wollen aber an dieser Stelle unsere Sicherheitsarchitektur nicht aufweichen, weil wir glauben, dass das unter dem Strich eine negative Rechnung wäre.


Firmen und Mitbewerber, die hier keine hochwertige Sicherheitsarchitektur haben, tun sich hier natürlich sehr leicht. Die konfigurieren etwas den LDAP-Query rum und dann lesen bestimmte Softwarekomponenten bestimmte Passwortattribute halt kurzerhand aus. Kann man so machen. Ist aber definitiv nicht unser Sicherheitsniveau. Pardon, aber davon lasse ich mich weder treiben, noch in falsche Entscheidungen zwängen. Versteht ein außenstehender User natürlich nicht unbedingt, aber auch das ist für mich nicht der Maßstab.


Abhilfe würde die komplette interne Umstellung auf OAUTH etc. bringen. Dazu müssen jedoch ausnahmslos alle Verwaltungs- und API-Module ihrerseits OAUTH unterstützen, damit im Hintergrund alles funktioniert. Das sind > 20 Jahre gewachsener Code. Das überall einzuprogrammieren dürfte ein oder gar zwei Personenjahre Arbeit sein.

Wir wollen und werden das machen und haben damit auch begonnen. Einige Module (z.B. ID4me) benutzen das auch schon. Aber wenn es für alle Kundenservices gehen soll, müssen es alle Codestellen von uns gleichzeitig können.

Die letzten eineinhalb Jahre haben wir uns für jeweils strategisch wichtigere Projekte entschieden: Ob das die Unterstützung der Schulen war, die Einführung der Video-Lösung oder die komplette Überarbeitung der Preis- und Tarifstruktur, die wir im Dezember 2019 (!) begonnen haben und nun in wenigen Tagen abschließen werden. Auch das ist wichtig. Und wir haben an ganz vielen Stellen in den letzten zwei Jahren Code aufgeräumt, die APIs stabiler gemacht, in Microservices ausgelagert und und und -- und damit auch die Grundlage gelegt, überall OAUTH einzuführen.

Sprich: Das ist ein *deutlich* mächtigeres Projekt, als man von außen auch nur ansatzweise ahnt. Und das wäre sicherlich auch fertig, wenn wir andere Prioritäten gesetzt hätten. Haben wir aber nicht und das ist auch gut und richtig so. Aber wollen und werden wir machen.

Foto
2

@Den: Danke für die Erläuterung. Ich sehe auch gerade bei Google, dass für jede Anwendung eine Kategorie wie "E-Mail" oder "Kalender" ausgewählt werden kann. Das ist immer noch nicht so feingranular wie auf Protokollebene, aber natürlich ein Sicherheitsgewinn.

Bei dem Fall "Auslesen bzw. Stehlen des Devices" reicht es aber mit der bisherigen Lösung aus, das Kennwort zurückzusetzen und auf allen Clients zu ändern. Das ist dann mehr ein Komfort- als ein Sicherheitsgewinn.

Foto
2

@Peter Henlein

Ich bitte um Entschuldigung für den spitzen Ton meines letzten Absatzes; er war wohl geschuldet der späten Stunde und dem Eindruck, dass im Forum diese Frage seit Jahren immer mal wieder aufgeworfen wird, ohne wirklich beantwortet zu werden; es bleiben unbefriedigte außenstehende User zurück, die sich fragen, ob das Ansinnen jetzt wirklich so unbedarft war. Mea culpa.

Danke für die Erläuterungen! (Und für die ganze Arbeit!)

Man schiebt aber natürlich die Verantwortung damit wieder komplett an die User zurück - installiere und betreibe nichts, für das du nicht deine Hand ins Feuer legen würdest und was du nicht unter ständiger Kontrolle hast. Auf unserer Seite ist alles gehärtet und safe, wenn auf deiner User-Seite, außerhalb unserer Einfluss-Sphäre, was schiefgeht, dann ist das dein Problem.

Das ist in der Reinen Lehre natürlich ein legitimes und richtiges Ansinnen. Das reale Leben sieht aber ja eher anders aus. Ich kann nicht wirklich überblicken, wie gut ein Mail-Client oder ein Betriebssystem oder ein IoT-Device wie der Netzwerkdrucker oder der Router ihre Konfig schützen; ich surfe im Web, ich installiere Apps; ich werde natürlich das Passwort in App oder Gerät hinterlegen, statt es jedesmal händisch einzugeben. Ich hoffe, dass die Hecke aus Pihole und Scriptblockern, die ich um meinen digitalen Zoo gezogen habe, ausreicht. Und von meinem Provider erhoffe ich, dass er seine Seite nach außen so abgesichert hat, dass die internen Kompromisse, die er machen muss, um meine Unbedarftheit aufzufangen, kein Problem darstellen.

@Stephans Einwurf, dass die Lösung mit EINEM User/PW-Login gegenüber den appspezifischen PW im Verlustfall lediglich eine Frage des Komforts sei, stimmt eben doch nicht ganz: bei der bisherigen Lösung muss ein Angreifer lediglich die Login-Daten auslesen und kann sie dann mit seiner eigenen Infrastruktur nutzen. Bei einer appspezifischen Lösung müsste er den angegriffenen Client selbst so manipulieren, dass er einerseits tut, was der Angreifer will, andererseits für den Server immer noch aussieht wie der unschuldige Client, den er schon kennt. Die reine User/PW-Kombi ist für den Angreifer wertlos. Und da der 08/15-User wohl vor allem blinder Massenphishing-Malware ausgesetzt sein wird, und nicht ausgefuchsten Attacken, die seine konkrete Installation versklaven, ist das dann schon ein deutlicher Schritt nach vorn.

Wenn ich das also recht verstehe, bleibt dann dem außenstehenden User einstweilen nur der Hinweis, man möge sich ausschließlich über das 2fa-gesicherte Webinterface verbinden, alle anderen Schnittstellen abschalten und für Geräte und Apps, die selbstständig Mail versenden sollen, Postfächer bei den bekannten Freemailern mit Weiterleitung an die mailbox.org-Adresse einrichten.

Foto
1

Mir wäre nicht bekannt, dass sich anwendungsspezifische Passwörter nicht auch in anderen Clients verwenden lassen, sofern es sich um denselben Einsatzzweck handelt. Ein für Thunderbird generiertes Passwort kann ich auch auf dem Smartphone-Mailclient verwenden und umgekehrt.


Sollte es da aber eine Entwicklung gegeben haben, die ich nicht kenne, wäre ich dankbar für entsprechende Erläuterungen bzw. Quellen.

Foto
1

Quick‘n‘dirty Test: die MacOS-Mail-App kann mit dem („appspezifischen“) Passwort für imap.web.de bzw. smtp.web.de aus Thunderbird zwar Mail versenden, aber nicht abholen.

(Auf die Idee, dass diese ganze „appspezifisches Passwort“-Geschichte ein großer hoax sein könnte - wir generieren einfach mehrere PW für ein Konto, instruieren dann den User, jedes aber auch WIRKLICH NUR FÜR EINE APP!11! zu benutzen, und simulieren damit Sicherheit - bin ich ehrlich gesagt nicht gekommen.)

Foto
1

Mich interessiert halt, wie das technisch funktionieren soll. Eine Anfrage per IMAP schickt ja keinen User-Agent oder so mit. Wie soll der Server also entscheiden können, ob der Client zu diesem Passwort passt oder nicht?

Foto
1

"Bei dem Fall "Auslesen bzw. Stehlen des Devices" reicht es aber mit der bisherigen Lösung aus, das Kennwort zurückzusetzen und auf allen Clients zu ändern. Das ist dann mehr ein Komfort- als ein Sicherheitsgewinn."

Stimmt. Ein bei web.de erzeugtes anwendungsspezifisches PW funktioniert im iOS-Mailclient und in TB unter MacOS.

Wie peinlich. Man kann so ein PW nur erzeugen, wenn man 2fa aktiviert hat. Ich bin deshalb tatsächlich davon ausgegangen, dass dann halt der Besitz der App-Installation, die man zuerst mit diesem PW losgeschickt hat, der zweite Faktor ist, statt eines OTP oder Hardware-Tokens.

Is' nich' so.


Es geht also wirklich in erster Linie um Bequemlichkeit; dass man nämlich nur diesen einen Key zurückziehen / ändern muss, wenn man den Verdacht hat, er sei verloren oder korrumpiert.

Vielleicht dann doch wieder um Sicherheit, weil man das eher macht, als "auf Verdacht" den ganzen Zoo abzuhängen und überall das PW neu eingeben zu müssen.


Es bleibt hängen: eventuell ist es doch keine so gute Idee, irgendwelchen Devices den Schlüssel zur Guten Stube zu geben.

Danke, wieder was gelernt! :)

Foto