Willkommen im User-Forum von mailbox.org
 

Passwort-Reset über eigene Mailbox.org-Adresse sollte deaktivierbar sein.

4905463 hat dies geteilt, 52 Tage her
vorgeschlagen

Hallo Mailbox.org-Team und Community,

ich bin erst vor kurzen auf Mailbox.org aufmerksam geworden und finde den Dienst echt klasse. Mein Unternehmen ist momentan auf der Suche nach einer Alternative zu Microsoft für Mail und Kalender. Mailbox.org ist leider Vorerst raus, da man sich dummerweise an den Sicherheitsstandards orientiert, die große amerikanische Unternehmen setzen. Einige der Showstopper wurden hier schon ausführlich diskutiert; die beiden folgenden Themen habe ich allerdings noch nicht gefunden:


1. Der Passwort-Reset über die eigene Mailbox.org-Adresse sollte deaktivierbar sein.

Die Begründung war (verkürzt): Ein Angreifer, der sich unberechtigt Zugang zu einem Endgerät verschafft hat (ohne das Passwort zu kennen), darf den Eigentümer nicht vollständig aus dem Account aussperren können.

2. Es sollte eine Benachrichtigungs-Option geben, über Logins von unbekannten Geräten an die eigene und falls vorhanden alternative E-Mail-Adresse.


Begründung hier: Unberechtgte Zugriffe sollen möglichst schnell erkannt werden.

Es wird die Entscheidungs meines Unternehmens vermutlich nicht ändern, aber ich wollte die beiden Punkte trotzdem als Vorschlag posten. Zumindest privat habt ihr einen neuen Kunden gewonnen.

Kommentare (3)

Foto
3

Ich stimme zu Punkt 1) zu. Derzeit ist es möglich, ein beliebiges Mailbox.org-Konto nur mit dem IMAP-Passwort (Login-Passwort) vollständig zu übernehmen (falls IMAP aktiviert). Alternativ reicht der Zugriff auf ein unsicheres Endgerät, auf dem ein konfigurierter IMAP-Client läuft (potentiell jedes Smartphone). Die 2FA wird hier effektiv umgangen. Der Passwort-Reset über die eigene Mailbox.org-Adresse sollte daher deaktivierbar sein.

Foto
1

Ich stimme in beiden Punkten zu! Es spricht ja vieles dafür, diese beiden nützlichen Funktionen einzuführen. Ich frage mich, warum es die noch nicht gibt? Mailbox legt an vielen anderen Stellen viel Wert auf Sicherheit - vielen Dank dafür! Aber an dieser Stelle scheint das (noch) nicht der Fall zu sein.

Was spräche denn gegen die Einführung? Zu hoher Aufwand? Zu viele Kosten?

Foto
1

Die Gründe sind einfach:

1) Wer Zugriff auf das Gerät hat, der *hat* auch das Passwort, weil es in den Configs der dortigen Software gespeichert ist. Sonst könnte man sich ja nicht einloggen. Wenn wir Leuten vorgaukeln würden, dass diese Gefahr nicht bestehen würde, dann würden wir ein völlig falsches und trügerisches Gefühl von Sicherheit vermitteln. Nochmal: In der Config dieses Gerätes *steht* das Passwort.

2) Bei IMAP lassen sich unbekannte Geräte nicht identifizieren; es gibt dort (anders als bei Webbrowsern) keine sinnvolle Client-Kennung und/oder einen sinnvollen Footprint. Zudem würden wir dann Daten erheben müssen (Tracking des Users / Device / der IP-Adressen etc.) die wir so nicht erheben wollen. Im Webbereich gibt es sinnvolle Footprints; dort werden verwendete Geräte angezeigt. Wir haben die Datenerfassung dort auf ein Minimum reduziert; können aber die verschiedenen Clients über die vorhandenen Login-Sessions erkennen und anzeigen.

Foto
1

Zu 1) Ich verstehe den Zusammenhang nicht. Ja, das IMAP-Passwort ist auf dem Gerät gespeichert und wer auf das Gerät zugreifen kann kommt da auch ran, das ist klar. Aber mit dem IMAP-Passwort allein sollte es nicht möglich sein, das Mailbox.org-Konto zu übernehmen. Ja, man kann mit dem Passwort über IMAP Mails lesen und verschicken, aber man sollte nicht das Konto übernehmen können. Genau das ist ja der Sinn von 2FA beim Weblogin - nur wird das eben wie oben beschrieben umgangen.

Foto
1

Ja, wenn man OTP im Weblogin zugrundelegt, dann stimmt diese Überlegung natürlich. Ich denke mal darüber nach, finde das aber plausibel.

Foto
1

Super, danke. Jetzt verstehe ich auch Ihre erste Antwort - Mit der Reset-Mail würde man ein Passwort zurücksetzen, welches man eh schon kennt wenn man Zugriff auf das Endgerät hat. Da gebe ich Ihnen recht. Aber das ändert natürlich nix an der Kontoübernahmeproblematik, um die es hier geht :-)

Foto
2

Lieber Herr Heinlein,

erst einmal vielen Dank für Ihre Bereitschaft, auf den Diskurs einzugehen! Das ist nicht selbstverständlich - schon gar nicht vom Geschäftsführer! Danke!

Ich kann die Ausführungen nachvollziehen. Doch bei dem Szenario, das ich vor Augen habe, besteht immer noch eine Problematik: jemand verschafft sich Zugriff auf meinen Laptop oder mein Handy (z.B., weil es gerade nicht gesperrt ist). Über den Mail-Client, der ja Mails per IMAP abruft, kann man dann problemlos ein Passwort-Reset durchführen, ohne das eigentliche Passwort zu kennen. Klar, es steht in den Einstellungen, aber in der Regel ja nicht im Klartext.

Ich würde mich sehr freuen, wenn man für den IMAP-Zugriff ein extra Passwort einrichten könnte. Bei den Mitwettbewerbern (u.a. Web.de und T-Online) klappt das ja auch problemlos.

Foto
2

Hallo Herr Heinlein,

vielen Dank für die Stellungnahme! Punkt 2) kann ich nachvollziehen, vermutlich trifft das Problem dann auch auf App-Passwört zu. Bei 1) bin ich tatsächlich von aktivierten OTP-Login im Web-Portal ausgegangen, klar hat der Angreifer dann schon Zugriff auf alle Mails, aber er sollte zumindest den User nicht komplett aus seinem Account aussperren können.


Man muss auch leider dazu sagen, in meinem Unternehmen und auch bei praktisch allen unserer Geschäftspartnern geht es mehr darum Checkpunkt-Listen abhaken zu können oder Sicherheits-Zertifizierungen zu bekommen, als um die IT-Sicherheit an sich.

Foto
1

Hallo zusammen,


über die Implementation von Punkt 1) würde ich mich sehr freuen.

Entweder die Möglichkeit diese Methode komplett zu deaktivieren oder über OTP oder eventuell doch ein zusätzliches unabhängiges Passwort, welches nur für den Zugriff über IMAP, CalDAV, etc. funktioniert.


Bei der Methode mit Verwendung von OTP müsste dann aber auch das Deaktivieren des OTP Tokens bei einem Passwort-Reset verhindert werden, da die Anmeldung mit OTP Tokens bei einem Passwort-Reset deaktiviert wird.

Hier ist noch die Frage, wann die Anmeldung mit OTP deaktiviert wird? Direkt beim Versenden der Passwort-Reset Email/SMS oder beim Eintragen und Bestätigen des korrekten Reset-Codes?


Daher sollten OTP Backup-Codes generiert werden können, welche alternativ zu den OTP Codes genutzt werden können. Es sollte auf jeden fall nicht möglich sein die Anmeldung mit OTP Tokens durch eine Passwort-Reset zu deaktivieren.


Hat es eigentlich einen bestimmten Grund warum beim OTP PIN nur maximal vier Zeichen möglich sind? Man könnte ja mindestens vier Zeichen erzwingen.


Zu Punkt 2) frage ich mich, ob nur das Erfassen der IP und Versenden an E-Mail und alternative E-Mail wirklich schon zu viel Datenerfassung ist.


Trotz allem würde ich es am besten/sichersten finden wenn OTP nie bei einem Passwort-Reset deaktiviert werden würde und es die Möglichkeit geben würde Backup-Codes zu erhalten.

Foto
2

Zu den Backup-Codes: Man kann ja jetzt schon mehrere OTP-Token generieren. Das ist ja effektiv das gleiche. Reicht ja wenn man sich das OTP-Secret irgendwo aufschreibt.


Meiner Meinung nach macht es schon Sinn, dass das OTP durch den PW-Reset abgeschaltet wird, ansonsten würde der PW-Reset ja überhaupt nichts machen. Eine effektive Methode zum PW-Reset braucht man nunmal. Wichtig dabei ist halt, dass in jedem Fall immer noch ein (anderer) zweiter Faktor gegeben ist. Gute Reset-Methoden sind z.B. eine alternative Mailadresse (vorausgesetzt man macht nicht den Fehler und schickt sich diese Mails automatisiert an das gleiche unsicheres Endgerät) oder der Reset über die Hotline mittels Telefonpasswort. Schön wäre halt, wenn jede Reset-Methode nur optional wäre.


Und was die 4-stellige PIN betrifft: Da man die nur im Weblogin eingibt, sind die 4 Stellen vermutlich mehr als ausreichend. Zusammen mit dem OTP sind es 10 Stellen, und die Anzahl der Login-Versuche ist im Weblogin sicherlich begrenzt. Dein Kreditkarten-PIN hat ja auch nur 4 Stellen (und kein OTP).

Foto
1

Zu 1. Ja, könnte man so machen. Scheint mir aber für den standard Nutzer nicht sehr einfach. Da wäre das Erstellen und Anzeigen von Backup-Codes sinnvoller.

Zu 2. Aktuell macht es Sinn, aber auch nur weil das Passwort im Webclient mit der PIN + OTP Kombination ausgetauscht wird. Wenn man beim Webclient immer noch das Passwort und zusätzlich das OTP benötigen würde, würde ein Passwort-Reset, welcher auch OTP deaktiviert eine Accountübernahme vereinfachen.

Naja, aktuell ist ja das eigentliche Problem, dass durch einen Passwort-Reset der Account ziemlich einfach übernommen werden kann. Der Angreifer benötigt aktuell nur Zugang zu einem Gerät, welches einen Account via IMAP/POP synchronisiert und schon kann das Passwort zurückgesetzt werden. Hier würde eine noch aktive Authentifizierung mit OTP schon sinn ergeben. In anderen Fällen aber nicht, da es dann keine andere Möglichkeit gibt das OTP zu deaktivieren außer direkt über den Webclient.

Hier würden z.B. Backup-Codes, mehre OTP-Tokens oder gesicherte Secrets helfen.

Foto