Java Mail und idle() mit zig Emailadressen?

[LimDul]

DSGVO sehe ich nicht als Problem. Du brauchst halt einen Vertrag über die Datenverarbeitung, in der klar sagst, was du wie machst.
Da sehe ich nicht mehr Probleme als z.B. die Nutzung eines Providers.... Meine Emails sind in der GSuite bei Google ...

Klar, aber den Vertrag muss man mit jedem gewerblichen Kunden schließen.

 

[beta20]

Klar, aber den Vertrag muss man mit jedem gewerblichen Kunden schließen.

Kommt in den AGB´s bei Registrierung bei der Software dazu? Der User muss das akzeptieren?

 

[mihe7]

Es geht darum, dass Dein Kunde Dich mit der Verarbeitung von Daten beauftragen muss, die bei ihm anfallen. Genauso musst Du Deinen Provider mit der Verarbeitung von Daten beauftragen, die bei Dir anfallen (z. B. E-Mails, Logfiles, ...)

EDIT: Hier mal ein Link zum Thema https://www.datenschutz-wiki.de/Auftragsdatenverarbeitung

 

[kneitzel]

Es geht darum, dass Dein Kunde Dich mit der Verarbeitung von Daten beauftragen muss, die bei ihm anfallen. Genauso musst Du Deinen Provider mit der Verarbeitung von Daten beauftragen, die bei Dir anfallen (z. B. E-Mails, Logfiles, ...)

EDIT: Hier mal ein Link zum Thema https://www.datenschutz-wiki.de/Auftragsdatenverarbeitung

Aufpassen! Der, der Dich beauftragt muss auf den Vertrag achten. Du selbst bist nicht dafür verantwortlich!

Also wenn ich Daten, die dem Datenschutz unterliegen, weiter gebe an jemand anderes, dann ist es meine Verantwortung, dass dies rechtens ist. Es ist nicht die Verantwortung des Empfängers!

 

[LimDul]

Stimmt. Aber als Empfänger muss man in der Lage sein anzugeben was man damit wie tut 🙂

 

[beta20]

Habe jetzt mal bisschen das ganze erkundigt, wie das ein anderer Provider macht, die das bereits haben.
Siehe auch hier:

Folgende Aussage hierzu:

Keine Sorge, wir kennen zu keinem Zeitpunkt dein Passwort. Dies gibst du bei uns ein und wird direkt verschlüsselt und codiert. Anschließend wird das codierte Passwort in der Datenbank gespeichert und direkt an den E-Mail Provider gesendet. So wie es auch Google, Facebook und Co macht.

Das codierte Passwort ist dann nicht test1234 sondern ein ewig langes codiertes Passwort zb.: KlQ4sXx9YN8xBgl1dOyDUSzMlJC01b54UAy55Q4zri0= Das codieren ist ein einheitlicher Sicherheitsstandard, der überall auf der Welt angewendet wird.

Dein E-Mail Provider macht das auf die 1:1 gleiche Art. Er gibt dir ein Passwort, du kennst das Passwort im Klartext und der Anbieter speichert das codierte Passwort in der Datenbank. Wenn du dich dann bei deinem E-Mail Provider einloggst, wird auf deinem PC das Passwort codiert und verschlüsselt an den E-Mail Anbieter versendet. Der prüft dann das mit der Datenbank und wenn das zusammen stimmt, dann kannst du dich einloggen. Einfach gesagt. Da gibt es noch weitere Sicherheitsmechanismen, die alle Angriffe verhindern soll.

Eines ist aber klar. Das Passwort ist nie zu 100% sicher. Auch nicht bei deinem E-Mail Provider. Wenn dieser gehackt wird und die Hacker viel Zeit haben, dann werden sie irgendwann auch das codierte Passwort encodieren können und haben Zugriff auf dein Postfach. Das ist überall so.

Aber jetzt mal ganz ehrlich. Das Passwort ist bei uns sicher, wir speichern deine Nachrichten nicht, lesen sie nicht und haben keinen Zugriff darauf. Die bleiben alle auf dem Server deines E-Mail Anbieters (Gmx, Gmail, All-inkl....). Mach dir da keine Sorgen. Im Gegenteil, es ist sogar sicherer, als wenn du Outlook auf deinem PC verwendest.

Kann sich jemand vorstellen, wie das umgesetzt werden soll? Sind diese Aussage wirklich valide? Kennt jemand den Prozess für das "codierte" Passwort?

 

[LimDul]

Das ist der Form Bullshit.

Entweder ich hab das Passwort, so dass ich mich bei dem E-Mail Account einloggen kann oder nicht.

Mit dem Passwort hat man Zugriff auf den E-Mail Account. Viele E-Mail Server unterstützen, dass man das Passwort beim Login Prozess nicht als Klartext sondern z.B. als MD5 Hash übergibt (allerdings dann nicht salted). Dann kannst du den MD5 Hash speichern anstelle vom Klartext passwort. Das ist allerdings in Bezug auf den E-Mail Server genau so gut wie ein Klartext Passwort und gibt Vollzugriff auf die E-Mails. Und insbesondere bei MD5 unsalted dürfte es kein Problem sein da wieder das Klartext passwort zurückzuermitteln.

Um es mal ganz deutlich zu sagen:
Wenn du dich auf den IMAP Server mit einem Account einloggen willst, brauchst du ein Passwort, dass dir Vollzugriff auf den Account gibt und aus dem man das Klartext-Passwort zurückrechne nkann Das ist einfach so. An dieser Restriktion kommst du nicht vorbei, wenn du dich auf dem IMAP-Server verbinden willst. Deswegen würde ich jede Dritte Web-Anwendung die mich auffordert mein E-Mail Passwort anzugeben als extrem gefährlich einstufen und würde jedem deutlich davon abraten so etwas zu nutzen. Das öffnet die Tür zur Hölle, insbesondere wenn der Anbieter keine Ahnung was er tut und wie er die Daten ordentlich sichert. Und das weiß man von außen nicht. Und ob der irgendwelchen Unfug damit treibt, weiß ich auch nicht.

 

[mrBrown]

Würde ich als Unsinn bezeichnen.

Keine Sorge, wir kennen zu keinem Zeitpunkt dein Passwort. Dies gibst du bei uns ein und wird direkt verschlüsselt und codiert. Anschließend wird das codierte Passwort in der Datenbank gespeichert und direkt an den E-Mail Provider gesendet. So wie es auch Google, Facebook und Co macht.

Um die Mails abzufrufen (was wie im Video gezeigt wohl einfach nur über Standard-IMAP funktioniert), muss man das Passwort kennen.
Es gibt andere Möglichkeiten, aber da wird im Video ganz explizit gesagt, dass es noch nicht geht – und das ist immer Mail-Provider spezifisch und nicht generisch für alle.

Das codierte Passwort ist dann nicht test1234 sondern ein ewig langes codiertes Passwort zb.: KlQ4sXx9YN8xBgl1dOyDUSzMlJC01b54UAy55Q4zri0= Das codieren ist ein einheitlicher Sicherheitsstandard, der überall auf der Welt angewendet wird.

Dein E-Mail Provider macht das auf die 1:1 gleiche Art. Er gibt dir ein Passwort, du kennst das Passwort im Klartext und der Anbieter speichert das codierte Passwort in der Datenbank. Wenn du dich dann bei deinem E-Mail Provider einloggst, wird auf deinem PC das Passwort codiert und verschlüsselt an den E-Mail Anbieter versendet. Der prüft dann das mit der Datenbank und wenn das zusammen stimmt, dann kannst du dich einloggen. Einfach gesagt. Da gibt es noch weitere Sicherheitsmechanismen, die alle Angriffe verhindern soll.

Eines ist aber klar. Das Passwort ist nie zu 100% sicher. Auch nicht bei deinem E-Mail Provider. Wenn dieser gehackt wird und die Hacker viel Zeit haben, dann werden sie irgendwann auch das codierte Passwort encodieren können und haben Zugriff auf dein Postfach. Das ist überall so.

Aber jetzt mal ganz ehrlich. Das Passwort ist bei uns sicher, wir speichern deine Nachrichten nicht, lesen sie nicht und haben keinen Zugriff darauf. Die bleiben alle auf dem Server deines E-Mail Anbieters (Gmx, Gmail, All-inkl....). Mach dir da keine Sorgen. Im Gegenteil, es ist sogar sicherer, als wenn du Outlook auf deinem PC verwendest.

Da werden zwei Dinge miteinander vermischt, die gänzlich unabhängig sind.

Das Passwort für die Applikation selbst sollte natürlich immer "codiert" (=gehasht) abgelegt sein. Das macht nahezu jeder Dienst so, das ist wirklich völliger Standard und mit vernünftigem Hash-Algorithmus auch sicher (genug).

Aber mit einem gehashten Passwort kann man sich nicht an einer anderen Stelle authentifizieren. Sonst ist das gehashte Passwort einfach nur wieder ein "Klartext" Passwort.

 

[mihe7]

Zum Video:

"Start T S L" ?!? Ok, er sagt ja selbst: "völlig egal, was das ist" 🙂

 

[thecain]

Vor allem "TSL"... Vollstes vertrauen von meiner Seite