# Java Mail und idle() mit zig Emailadressen?



## beta20 (15. Nov 2020)

Hallo zusammen,

hat vielleicht jemand Erfahrungswerte mit dem Überwachen von Emailadressen im Hintergrund?
Java Mail bietet hierfür ja die idle() - Methode an bzw. auch den IdleManager:
https://github.com/javaee/javamail/blob/master/mail/src/main/java/com/sun/mail/imap/IdleManager.java

Bei idle() läuft jeder Emailordner in einem Thread, bei IdleManager wohl nur ein Thread für alle.
Mein Vorhaben ist zig Emailadressen auf neue Email zu überwachen. Angenommen 1000 Emailadressen, später 10.000 Emailadressen....

Ist das völlig utopisch? Wird das mich so sehr an Performance / Ressourcen kosten? Oder mache ich mir hier im Vorhinein zu viel Gedanken, über die ich mir keine machen muss?

Kann hier jemand aus der Praxis berichten oder hat plausible Begründungen?

Vielen Dank für jede Hilfe.


----------



## LimDul (15. Nov 2020)

Aus dem Bauch heraus wird das ein Problem. Soweit ich das sehe bedeutet das bei 10.000 Emailadressen 10.000 eigene TCP/IP Verbindungen (da die ja Logins benötigen) und damit im Programm auch 10.000 Threads per Default - was mit Sicherheit ein Problem gibt. Sprich, ich würde vermuten, dass man da (sofern es wirklich ein Programm sein soll) um Eigenbau-Lösungen nicht drumrumkommt.


----------



## beta20 (15. Nov 2020)

LimDul hat gesagt.:


> Aus dem Bauch heraus wird das ein Problem. Soweit ich das sehe bedeutet das bei 10.000 Emailadressen 10.000 eigene TCP/IP Verbindungen (da die ja Logins benötigen) und damit im Programm auch 10.000 Threads per Default - was mit Sicherheit ein Problem gibt. Sprich, ich würde vermuten, dass man da (sofern es wirklich ein Programm sein soll) um Eigenbau-Lösungen nicht drumrumkommt.



danke...

Die Logins lege ich bei mir in der Applikation ab. D.h. beim Hochfahren der Applikation wird einmal die Inbox dem IdleManager hinzugefügt (watch). Dann benötige ich doch keine 10.000 TCP / IP Verbindungen?

Ggf. müsste ich noch alle 10 Minuten einen check (zB. getNumberMessage) machen, dass ich nicht in einen Timeout laufe.

Was meinst du in dem Kontext genau dann mit "Eigenbau"?


----------



## LimDul (15. Nov 2020)

beta20 hat gesagt.:


> danke...
> 
> Die Logins lege ich bei mir in der Applikation ab. D.h. beim Hochfahren der Applikation wird einmal die Inbox dem IdleManager hinzugefügt (watch). Dann benötige ich doch keine 10.000 TCP / IP Verbindungen?
> 
> ...


"Die Inbox" vs. "10.000 Email-Adressen" sind das nicht dann 10.000 Inboxen?


----------



## White_Fox (15. Nov 2020)

Hier hat doch irgendjemand ein Javapaper verlinkt. Da stand etwas über virtuelle Threads drin...ich denke, das könnte etwas für dich sein.


----------



## thecain (15. Nov 2020)

Ändert ja nichts an der benötigten TCP Connection


----------



## White_Fox (15. Nov 2020)

Aber das Problem mit den vielen Threads.



			https://jax.de/wp-content/uploads/2020/09/WJAX_20_Whitepaper.pdf


----------



## temi (15. Nov 2020)

Müssen die denn permanent überwacht werden? Vielleicht könntest du sie ja pollen?

Aber ich frage mich grad - wer gibt dir denn die Anmeldedaten seines Mailaccounts? Oder hast du selbst 1000 Mailaccounts?


----------



## beta20 (16. Nov 2020)

temi hat gesagt.:


> Müssen die denn permanent überwacht werden? Vielleicht könntest du sie ja pollen?
> 
> Aber ich frage mich grad - wer gibt dir denn die Anmeldedaten seines Mailaccounts? Oder hast du selbst 1000 Mailaccounts?


Realtime wäre die beste Lösung. Zeitverzögerungen von 1-5 Minuten wäre auch noch OK.

Vllt. kurz zum Szenario etwas:
1) Kunde speichert seine Daten in der App, damit meine App den Emailordner überwachen kann.
2) Es kommt eine neue Email von XYZ herein für diese Emailadresse
3) Darauf hin sollen in meiner App sofort weitere Prozesse angestoßen werden (sende Email etc.)

Die Kunde gibt in der GUI seine Daten ein, diese werden verschlüsselt gespeichert. Ich kenne das von einer anderen Softwarelösung, die machen das auch so. 

Pollen wäre auch eine Option, aber dann habe ich eben eine Zeitverzögerung.
Wenn ich bspw. nur alle 5 Minuten die Emails abrufe, würde ich dann nicht in solche Probleme laufen?


----------



## LimDul (16. Nov 2020)

An der Stelle würde ich mir Gedanken um Load-Balancing & Co machen. Eine Anwendung die alles tut ist an der Stelle mit SIcherheit nicht mehr sinnvoll. Denn du brauchst dann ja pro E-Mail Account eine TCP-Verbindung, die auch möglichst dauerhaft gehalten werden soll.


----------



## White_Fox (16. Nov 2020)

Nimm dir mal den Link vor, den ich gepostet habe. Da steht z.B. drin, daß ein extra Thread in Java erstaunlich viel Speicher benötgt - weitaus mehr, als für eine schnöde Verbindung eigentlich notwendig wäre. Wenn du für jede Verbindung einen neuen Thread aufmachst (was rein programmiertechnisch meiner Meinung nach ein naheliegender Ansatz wäre), bläst du den Hardwareaufwand sehr stark auf.
Und virtuelle Threads sollen das deutlich vereinfachen.


----------



## beta20 (16. Nov 2020)

Ok, danke. Aber brauche ich wirklich mehrere Threads? Siehe in der Doku:

https://access.redhat.com/webassets...0/javadocs/com/sun/mail/imap/IdleManager.html



> To deliver all events in a single thread using the Executor, set the following properties for the Session (once), and then add listeners and watch the folder as above.



Nach meinem Verständnis ist das ein Thread?


----------



## LimDul (16. Nov 2020)

Es reicht wohl ein Thread, das stimmt. Aber 10.000 offene IMAP-Verbindungen gibt es auch nicht umsonst  Und ein Thread heißt, das er auch nur eine Imap-Verbindung gleichzeitig prüfen und verarbeiten kann.

Nachtrag: Wenn das beispielsweise 10ms dauert heißt es, dass für 10.000 IMAP-Verbindungen das 100.000 ms dauert oder 100 Sekunden, sprich jeder Folder nur alle 100 Sekunden drankommt.


----------



## beta20 (16. Nov 2020)

LimDul hat gesagt.:


> Es reicht wohl ein Thread, das stimmt. Aber 10.000 offene IMAP-Verbindungen gibt es auch nicht umsonst  Und ein Thread heißt, das er auch nur eine Imap-Verbindung gleichzeitig prüfen und verarbeiten kann.


Bist du dir dazu sicher? Das heißt der Executer geht dann *nacheinander* die Emailnboxed durch, die er überwacht?
Man könnte das doch auf mehrere Applicationserver verteilen?

Aber wenn ich den IdleManager verwende, würde das kein Sinn machen, da dann die Threads nicht auf den App- Server verteilt werden, oder?
Ich müsste das dann mit einzelnen Threads machen, damit das auf mehreren App - Server laufen kann?


----------



## LimDul (16. Nov 2020)

Wie genau der IdleManager intern aufgebaut ist - keine Ahnung. Ob der pollt oder nicht. Aber ein Thread heißt nur eine Aktion zur gleichen Zeit. Sprich, wenn 100 E-Mail Folder gleichzeitig was melden das was da ist, kann das nur hintereinander verarbeitet werden.

Verschiedene Threads und App-Server haben erstmal nichts direkt miteinander zu tun. Verschiedene App-Server heißt auch verschiedene Anwendungen die laufen und sich entsprechend synchronisieren müssen. Und nicht eine Anwendung mit 2 Threads die auf verschiedenen Servern laufen. Das geht in der Form nicht.


----------



## beta20 (16. Nov 2020)

LimDul hat gesagt.:


> Und nicht eine Anwendung mit 2 Threads die auf verschiedenen Servern laufen. Das geht in der Form nicht.


Das würde doch über Load Balancer gehen?


----------



## LimDul (16. Nov 2020)

Ein Load-Balancer ist nur ein System was einen Request an Server A oder Server B schickt. Das sind dann zwei Anwendungen.


----------



## mrBrown (16. Nov 2020)

beta20 hat gesagt.:


> Ok, danke. Aber brauche ich wirklich mehrere Threads? Siehe in der Doku:
> 
> https://access.redhat.com/webassets...0/javadocs/com/sun/mail/imap/IdleManager.html
> 
> ...


Der Satz bezieht sich zwar auf das Ausliefern von Events, nicht auf das Abfragen, aber dafür wird immer ein Thread genutzt. Mit NIO dürfte das den Thread nicht sehr blockieren, allerdings bleibt die Menge an Verbindungen problematisch.



beta20 hat gesagt.:


> Man könnte das doch auf mehrere Applicationserver verteilen?


Aufteilen wäre sinnvoll, ein stumpfes parallelisieren des ganzen aber vermutlich weniger.

Potentiell könnte man die Applikation schneiden in reines Abfragen der Mails und alles andere, und nur ersteres lässt man auf mehreren Servern laufen. Kommunikation kann dann zB über eine Queue laufen, damit sind dann relativ einfach beliebige Mengen an abzufragenden Mailadressen möglich. Vielleicht bietet auch einer der großen Anbieter schon etwas passendes.

Ganz grundsätzlich könnte man aber auch drüber nachdenken, ob Mails das passende dafür sind – kommt natürlich drauf an, was das ganze System machen soll.


Ich wiederhole mich vermutlich zum 34768 Mal, aber: wenn man ein großes Softwaresystem mit uU zig tausend Kunden entwickelt, sollte man schon halbwegs entsprechendes Wissen haben...


----------



## beta20 (1. Dez 2020)

OK, also demnach wäre es besser einen Job zu bauen, der bspw. alle 1-5 Minuten losläuft und dann nach neuen Emails prüft, anstatt das als "Watcher / Idle" zu haben?


----------



## mrBrown (1. Dez 2020)

Was verstehst du unter „Job bauen“?


----------



## LimDul (1. Dez 2020)

Anstelle von Teilaspekten zu betrachten - wenn man wirklich x-tausend E-Mail Konten monitoren will, braucht man dafür ein *skalierfähiges* Konzept, eine Idee was das alles bedeutet:
* Wie viele parallele Verbindungen habe ich?
* Wie oft passieren die Ereignisse vermutlich?
* Wie teuer die Abarbeitung der Ereignisse?
* Wie kann ich das alles transparent skalieren

Wir sind dann automatisch im Enterprise Bereich unterwegs, wo man erst mal ein sauberes Konzept braucht, was man tun will und wo man ein Verständnis der *Gesamt-Architektur *hat. Dann kann man danach auf Detail-Ebene runtergehen.


----------



## beta20 (1. Dez 2020)

mrBrown hat gesagt.:


> Was verstehst du unter „Job bauen“?



Einen Scheduler, der im Hintergrund läuft und eben alle 1-5 Minuten angestartet wird (falls er sowieso nicht gerade läuft)....
Dieser könnte dann zB so aussehen:

- Hole mir alle Postfächer aus der Datenbank, die seit den letzten z.B. 5 Minuten nicht aktualisiert wurden (ich speichere zB das "lastUpdateDate"
- Prüfe bei denen ab, ob es neue Emails gibt
- Sobald alle geprüft wurden, startet der Job erneut


----------



## kneitzel (1. Dez 2020)

Also wie lange meinst du, wird 
- der Connect mit Logon, 
- die Prüfung
- die Verarbeitung der Resultate
dauern?

Du hast 5 Minuten sind 300 Sekunden ... Du willst ja fertig sein, ehe "es wieder los geht" ....

Dann ist auch die Frage, welche EMail-Server Du ansprechen willst. Wenn das nur einer ist, dann hast Du auch noch ein Problem, dass der ggf. böse wird weil zu viele Connects gleichzeit oder in zu kurzer Zeit kommen.

Das ganze Konzept sieht sehr dubios aus.

Wenn es um einen Mailserver bei euch geht: Wieso da nichts aktives bauen? Jede Email an ein Postfach löst dann ein Event aus. Die Mailserver, die ich so kenne, bieten da entsprechende Schnittstellen. Das bedeutet, dass Du da nichts aktiv prüfen musst - wenn eine Mail kommt, dann stößt der Mailserver direkt etwas an, das getan werden soll.

Wenn es um fremde Mailserver geht, dann ist das Vorhaben generell zu prüfen und zu klären, was Ihr wieso machen wollt.

Das Thema mit der Autorisierung ist aber auch noch offen - du verbindest Dich zu den Konten und meldest Dich da an? Also hast Du Login mit Passwörtern? Das würde ich schon extrem bedenklich finden und komplett abweisen. Passwörter zu speichern - besonders in dem Umfang - ist schon etwas, das ich NIE machen würde ...


----------



## mrBrown (1. Dez 2020)

Mindestens ich denke, dass Mails abfragen generell ungeeignet dafür sind und man nach besserem gucken sollte, und das Abfragen von Mails innerhalb des App-Servers der falsche Weg ist und besser ausgelagert wird.


----------



## beta20 (1. Dez 2020)

kneitzel hat gesagt.:


> Also wie lange meinst du, wird
> - der Connect mit Logon,
> - die Prüfung
> - die Verarbeitung der Resultate
> ...


danke für die Antwort...

Nein, nach 5 Minuten muss dies nicht fertig sein. Es wird nach 5 Minuten nur wieder geprüft, ob der Scheduler wieder anstarten kann (falls er nicht noch läuft)...

Ich habe das Konzepot bei einer bestehenden Software gesehen, bei der laut Aussagen ca. 500 aktive User sind... Hier wird i.d.R. jede Minute geprüft (jedenfalls kann man das nach dem Aktualisierungsdatum einsehen, wann das Postfach zuletzt aktualisiert wurde...
)
Nein, es geht nicht um interne Emailadressen. Es geht um Emailadressen von Usern (gmx, gmail, eigene Domain usw.). Dazu benötige ich doch keinen eigenen Mailserver oder habe ich hier einen Denkfehler?

Ja, der User muss sein Login abspeichern. Die Passwörter werden dann nochmal gehasht.


----------



## mrBrown (1. Dez 2020)

beta20 hat gesagt.:


> Ja, der User muss sein Login abspeichern. Die Passwörter werden dann nochmal gehasht.


Dir ist aber schon bewusst, dass du dich mit gehasht abgespeicherten Passwörtern nicht bei irgendeinem Mail-Anbierter authentifizieren kannst?


----------



## beta20 (2. Dez 2020)

Ja, sie sind verschlüsselt. Der Login funktioniert nur, wenn man das PW (der SHA512 String) des Users auch hat. 
Falls es andere, noch sicherere Alternativen gibt, dann gerne her damit.


```
// Zufälliger Schlüssel erstellen
        String passwordEncrpyt = PasswordHelperClass.createRandomKey(8);

        String password = PasswordHelperClass.decryptPassword(passwordEncrpyt,
                emailSettingPassword.getEmployee().getUser().getPassword());
        emailSettingPassword.setPasswordHash(password);

public static String decryptPassword(String password, String decryptKey)
            throws UnsupportedEncodingException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException,
            IllegalBlockSizeException, BadPaddingException {

        if (password == null)
            return null;

        // byte-Array erzeugen
        byte[] key = (decryptKey).getBytes("UTF-8");

        // aus dem Array einen Hash-Wert erzeugen mit MD5 oder SHA
        MessageDigest sha = MessageDigest.getInstance("MD5");
        key = sha.digest(key);

        // nur die ersten 128 bit nutzen
        key = Arrays.copyOf(key, 16);

        // der fertige Schluessel
        SecretKeySpec secretKeySpec = new SecretKeySpec(key, "AES");

        // der zu verschl. Text (das Passwort)
        String text = password;

        // Verschluesseln
        Cipher cipher = Cipher.getInstance("AES");
        cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec);
        byte[] encrypted = cipher.doFinal(text.getBytes());

        // bytes zu Base64-String konvertieren (dient der Lesbarkeit)
        String geheim = Base64.getEncoder().encodeToString(encrypted);

        return geheim;
    }
```


----------



## thecain (2. Dez 2020)

Was jetzt, verschlüsselt oder gehasht?..

Dein ganzes Projekt scheint mir ein bisschen gebastelt und passt nicht so damit zusammen das du hunderte Zugangsdaten zu Mail konten speichern willst/solltest


----------



## beta20 (2. Dez 2020)

Passwort User = SHA512 (gehasht)
Passwort Email: verschlüsselt (Entschlüsselung durch Passwort User und einen zufällig generieren String, siehe oben im Code: "passwordEncrpyt").


----------



## mihe7 (2. Dez 2020)

beta20 hat gesagt.:


> Passwort Email: verschlüsselt (Entschlüsselung durch Passwort User und einen zufällig generieren String, siehe oben im Code: "passwordEncrpyt").


Wenn das so ist, dann wähle ich doch zufällig einen leeren String und brauche nur noch das Passwort des Benutzers, also dessen Hash wie ich mal vermute.


----------



## mrBrown (2. Dez 2020)

Okay, der Code ist echt gruselig...

Du erstellst ein zufälliges Passwort.
Das übergibst du dann an die decrypt Funktion.
Die decrypt-Funktion ist aber gar kein decrypt, sondern ein encrypt.
Und das ergebnis davon bezeichnest du dann als "Hash"




beta20 hat gesagt.:


> Passwort User = SHA512 (gehasht)


SHA512 ist nicht für das Hashen von Passwörtern geeignet.



beta20 hat gesagt.:


> Falls es andere, noch sicherere Alternativen gibt, dann gerne her damit.


Die Alternative, die ich dir sehr ans Herz legen würde: Entwickle das nicht selbst, sondern bezahl irgendwen dafür, der es wirklich kann.


----------



## mihe7 (2. Dez 2020)

mrBrown hat gesagt.:


> Okay, der Code ist echt gruselig...


Puh, und ich dachte schon es liegt am Schlafentzug, dass ich hinter den Trick des Codes nicht gekommen bin 
decryt <-> encrypt, decryptKey ist das Benutzer-Passwort, das Passwort irgendwas zufälliges, das aber dann in den Settings abgelegt wird... Ich komm da nicht mit.


----------



## kneitzel (2. Dez 2020)

Also egal er da etwas entwickelt und egal wie gut du es verschlüsselst: Du hast das große Problem, dass Du User und Passwort brauchst in dem Konzept. Und damit musst du das Passwort auf irgend eine Art und Weise speichern und laden. Dabei ist es komplett egal, ob und wie Du es verschlüsselst. Denn an der Stelle, Wo du es entschlüsselst, kann ich ansetzen...

Zum Glück haben wir Java - ein Angriff auf das System und ich ziehe Daten mit jar/war Files ab und habe von vielen Usern Login / Passwort. Login ist die Email-Adresse und damit habe ich Email-Adresse mit Passwort ... wie viele User nutzen überall das gleiche Passwort? Wenn ihr so eine Datenbank habt, dann lasst das mal gegen PayPal laufen und so.  (Jetzt fehlt der neue Thread in der Plauderecke: "Kann jetzt massiv Geld bekommen - wohin kann man sich Absetzen, dass die Deutsche Justiz einen nicht kriegen kann?" *scnr*)

Also das ist ein absolutes Unding. Ein No Go!
Wenn Du Logins anbieten musst: Dann wird nicht das Passwort gespeichert sondern nur ein Hash (mit salt) oder irgend etwas ähnliches, so dass es eine garantierte Einwegstraße gibt: Passwort -> gespeicherter Wert. Somit kannst Du das Passwort niemandem sagen. Du hast es nicht gespeichert. Alles was du machst ist: Du bekommst eine Zeichenkette und die wandelst Du um um dann das Ergebnis mit dem gespeicherten Wert zu vergleichen.

Wenn Du Zugriff auf z.B. Google Mail oder so haben willst - auch für mehrere User, dann geht das natürlich. Aber nicht mit User / Passwort. Dann nutzt Du die entsprechende API. Wenn Du Google Dienste schon mal genutzt hast: Da startet dann der Browser, der User meldet sich an (incl. 2FA oder was auch immer) um dann am Ende auf der Google Seite zu sagen: Ja, ich gebe dem Dienst von Dir die Rechte, x, y und z zu machen. Also z.B. auf meine Mails zuzugreifen.
==> Du kannst dann meine Mails lesen. Aber du hast noch nicht einmal vollen Zugriff auf mein Google Konto. (Zumal meine EMails mit dem reinen Login nicht lesbar sind. Da wirst Du wohl bei den meisten G Suite Kunden massiv gegen die Wand rennen! Und ich würde mich auch nicht wundern, wenn Google das auch bei der offenen Plattform einbauen wird. Dann ist das zwar möglich, aber erkläre den Kunden, dass diese für Ihr Konto IMAP freischalten sollen und dass sie einen expliziten User/passwort Account erzeugen sollen für Deine App... Das alles schön mit roten Hinweisen, dass dies nicht sicher ist und der User in sich gehen soll um sich zu fragen, ob er das wirklich möchte ....) Und natürlich entfallen auch alle anderen Angriffsvektoren, die mit User / email und Passwort möglich wären ...


----------



## beta20 (2. Dez 2020)

Ok, du hast Recht, mit den Benamungen passt etwas nicht (decryt vs encrypt).

*EmailSetting* = Das Emailpostfach 
-> Hier passiert das beim Speichern, also sobald der User Username und PW in der GUI eingibt.


```
// Zufälliger Schlüssel erstellen
 String randomString = PasswordHelperClass.createRandomKey(8);

 // Das Passwort verschlüsseln (getPassword() ist das "richtige" Passwort, das der User in der GUI eingibt) 
emailSetting.setRandomPasswordHash(randomString);
emailSetting.setPassword(PasswordHelperClass.decryptPassword(emailSetting.getPassword(), randomString));

// Danach wird [B]EmailSettingPassword [/B]gespeichert (in einer Liste werden die User gespeichert, die auf das Postfachzugriff haben sollen und diese an die create() - Methode übergeben)
```

Das heißt in meiner DB steht dann als getPasswort sowas, zB:
*f33PZy42323WZb6sUGAsgYOg==*
-> RandomPasswordHash wird nicht in der DB gespeichert.


*EmailSettingPassword 
=* Das Emailpostfach, auf welches ein User Zugriff hat (1 EmailSetting .... n EmailSettingPassword)


```
String passwordEncrpyt = emailSettingPassword.getEmailSetting().getRandomPasswordHash();

String password = PasswordHelperClass.decryptPassword(passwordEncrpyt,
                emailSettingPassword.getEmployee().getUser().getPassword());
emailSettingPassword.setPasswordHash(password);
```

Dann steht in der DB sowas in "PasswordHash" in EmailSettingPassword ("Hash" ist hier falsch betitelt, es ist verschlüsselt)
Qbix2332323RWa32NA==
------------------------

Um das Passwort dann wieder zu bekommen, geschieht das:

```
// user.getPassword() is der Hashwert (SHA512) des PW vom Login des Users
String passwordEncryptUser = PasswordHelperClass.encryptPassword(emailSettingPassword.getPasswordHash(),
                user.getPassword());
 String passwordEncrypt = PasswordHelperClass.encryptPassword(emailSetting.getPassword(), passwordEncryptUser);

return passwordEncrypt;
```

Hier noch die encryptPassword - Methode

```
public static String encryptPassword(String password, String decryptKey) throws NoSuchAlgorithmException, IOException,
            NoSuchPaddingException, IllegalBlockSizeException, BadPaddingException, InvalidKeyException {

        if (password == null)
            return null;

        // byte-Array erzeugen
        byte[] key = (decryptKey).getBytes("UTF-8");
        // aus dem Array einen Hash-Wert erzeugen mit MD5 oder SHA
        MessageDigest sha = MessageDigest.getInstance("MD5");
        key = sha.digest(key);
        // nur die ersten 128 bit nutzen
        key = Arrays.copyOf(key, 16);
        // der fertige Schluessel
        SecretKeySpec secretKeySpec = new SecretKeySpec(key, "AES");

        // BASE64 String zu Byte-Array konvertieren
        byte[] crypted2 = Base64.getDecoder().decode(password);

        // Entschluesseln
        Cipher cipher2 = Cipher.getInstance("AES");
        cipher2.init(Cipher.DECRYPT_MODE, secretKeySpec);

        byte[] cipherData2 = cipher2.doFinal(crypted2);
        String erg = new String(cipherData2);

        return erg;
    }
```

Fakt ist, das Email Passwort kann ich nicht einfach so in die Datenbank schreiben, aber ich brauche zwingend den Username und das PW, um Zugriff zu haben. Ich sehe keine Weg, wie ich das lösen sollte, wenn ich Username und PW der Emailinbox nicht habe. Der User könnte sich natürlich jedes Mal erneut in der GZU anmelden, sodass ich das PW nicht speichern muss und es nur für die Session gilt, aber das ist nicht das, was ich brauche...

Bei Gmail kann man das denke ich über einen API Token lösen, aber das Problem ist, dass ich nicht nur Gmail Adressen habe.


----------



## beta20 (2. Dez 2020)

mrBrown hat gesagt.:


> SHA512 ist nicht für das Hashen von Passwörtern geeignet.


warum?


----------



## kneitzel (2. Dez 2020)

Also neben ggf. der Kritik am Code (Verschlüsselung mag besser gehen - das ist kein Spezialgebiet von mir. Ich verlasse mich da auf andere ...) gab es halt eine Kritik an dem Konzept selbst.

a) Ihr baut eine Stelle, die alle Passwörter kennt. Es steht ja was in der Datenbank und du kannst da - egal wie - an Logindaten kommen. Dies ist kritisch und kein Manager wird das wollen. Ihr werden Ziel eines Hackerangriffs und dann erbeuten das Hacker? Sorry, aber es geht schon extrem negativ durch die Medien, wenn da nur persönliche Daten nicht gut genug geschützt waren ... aber dann noch sowas? Mit einem System mit Internetzugriff? Aber ich habe diesen Punkt deutlich gemacht - könnt ihr machen - nur mir bitte noch den Namen der Firma schreiben, die das umsetzen möchte ... nicht dass ich da geschäftliche Kontakte zu habe ...

b) Technische Umsetzung ist nicht funktional in der Zukunft: Ihr setzt auf veraltete Technologie. Diese wird so in der Form immer weniger genutzt. Im Privatbereich haben sich da noch keine anderen Lösungen durchgesetzt, aber die großen Anbieter haben sich da verabschiedet. Ein Login rein mit User/Passwort.... Wie gesagt: Mein Postfach könntet Ihr nicht überwachen. Selbst wenn ich Dir meinen User / Passwort nennen würde. Das nützt Dir einfach nichts.

Und ein weiterer Punkt ist: Wieso sollte jemand euch seine Logindaten geben? Egal was ihr damit macht: wenn etwas passiert, dann war das grob fahrlässig. Müsste man einen Jurist fragen: Könnte euch den Hals retten im Falles eines Schadens - war ja schon grob fahrlässiges Handeln von der Person - dann muss man seine Schäden nicht begleichen ...


----------



## mrBrown (2. Dez 2020)

beta20 hat gesagt.:


> warum?


Weil SHA512 nicht für Passwörter gemacht ist.

Anforderungen an Hashfunktionen für Passwörter sind gänzlich andere als an Hashfunktionen für zB Dateien.


----------



## beta20 (2. Dez 2020)

kneitzel hat gesagt.:


> Also neben ggf. der Kritik am Code (Verschlüsselung mag besser gehen - das ist kein Spezialgebiet von mir. Ich verlasse mich da auf andere ...) gab es halt eine Kritik an dem Konzept selbst.


Ich kann die Kritik absolut nachvollziehen. Absolut verständlich.
Die Frage, die ich mir aber stelle, welche Lösungen gibt es, das Passwort nicht in irgendwelcher Form abspeichern zu müssen? Mir fallen keine ein.


----------



## mihe7 (2. Dez 2020)

beta20 hat gesagt.:


> warum?


Bei SHA handelt es sich um Prüfsummenalgorithmen. Als solche müssen sie schnell zu berechnen sein, man will ja nicht bei einer 2 GB-Datei mehrere Stunden auf ein Ergebnis warten müssen. Das wirft ein Problem auf, denn "schnell zu berechnen" bedeutet, dass man in kurzer Zeit viele Prüfsummen generieren kann. Hinzu kommt, dass gleiche Eingaben die gleiche Prüfsumme generieren. Das alles lässt sich von potenziellen Angreifern ausnutzen, um z. B. mittels vorberechneten Rainbow-Tables an Passwörter zu kommen und dann z. B. nachzuschauen, welche User das gleiche Passwort verwenden.

An die Berechnung eines Passwort-Hashs werden somit ganz andere Anforderungen gestellt: es muss möglichst jedes Passwort einen eigenen Hash bekommen und für dessen Berechnung sollte einiges an Zeit aufgewendet werden müssen. Das ist so ziemlich das Gegenteil von dem, was eine Prüfsumme leistet.

Allerdings wird z. B: SHA-2 durchaus im Rahmen der Verfahren zur Berechnung eines Passwort-Hashes eingesetzt. Zum Beispiel PBKDF2 mit HMAC als pseudozufällige Funktion (PRF) und SHA-256 als Hashfunktion.


----------



## beta20 (2. Dez 2020)

Ok, danke - das war mir neu.... Welchen Algorithmus sollte man dann besser für Passwörter verwenden?


----------



## mihe7 (2. Dez 2020)

beta20 hat gesagt.:


> Ok, danke - das war mir neu.... Welchen Algorithmus sollte man dann besser für Passwörter verwenden?


Ach, natürlich gibts da was von Baeldung: https://www.baeldung.com/java-password-hashing


----------



## kneitzel (2. Dez 2020)

beta20 hat gesagt.:


> Ich kann die Kritik absolut nachvollziehen. Absolut verständlich.
> Die Frage, die ich mir aber stelle, welche Lösungen gibt es, das Passwort nicht in irgendwelcher Form abspeichern zu müssen? Mir fallen keine ein.


Teilweise gibt es keine. Gerade dann, wenn man wirklich Richtung IMAP gehen möchte.

Aber bei einigen Anbietern gibt es da Alternativen. Ich kenne die Google Suite relativ gut, da ich diese einsetze. Da läuft es halt so, dass Du Deine Applikation für die API registrierst. Da gibst Du dann u.a. an, worauf zu Zugriff haben willst. Das wäre dann bei Dir Zugriff auf Emails. Aber das kann da auch deutlich mehr sein und teilweise auch deutlich detaillierter. Damit hast Du Daten für Deine App, die Du nutzen musst.
Wenn jetzt jemand sich autorisieren will, dann erstellst Du nur den Autorisierungs-Request. Das läuft dann bei einer Webanwendung in einem eigenen Tab, einem Popup oder was auch immer. Das ist aber dann eine Seite von Google. Ich melde mich da dann an - wie auch immer. Bei mir ist dies in der Regel durch Angabe meines Logins / Passworts + 2FA Bestätigung auf einem meines Handies. nachdem ich mit Authentifiziert habe bei Google fragt Google mich: Die App bla bla bla möchte Zugriff auf: x, y, z ... Stimme ich dem zu? Wenn ich dem zustimme, dann bekommt Deine App von Google einen Token. Diese App darf dann mit diesem Token auf bestimmte Dinge meines Accounts zugreifen.

Das kennst Du evtl. auch von Facebook. Das findet man doch bei fast allen Handy spielen. Da kannst Du dann auch eine Facebook Authentifizierung machen. Läuft ebenso ab: Anmeldung von Facebook (wäre bei mir ähnlich wie oben - Bestätigung auf Handy oder Code muss eingegeben werden) und dann kommt die Frage: Soll die App das und das dürfen. Oft mit der Erläuterung, dass die App nichts in meinem Namen posten kann und so.

Das wäre ein übliches verfahren. Und das gibt mir auch an zentraler Stelle die Möglichkeit, Token zu löschen. Ich will nicht mehr, dass die App bei mir zugreifen kann? Kein Thema: Ich gehe einfach hin und lösche es. Nicht bei Deiner App, deren Webfrontend das ggf. nicht bietet, gerade nicht geht oder oder oder. Nein - das geht zentral in der Verwaltung meines Accounts.

Das wäre eine klare Alternative, die aber nicht alle Anbieter bieten. Nur wenn Anbieter sowas haben (Office 365 hat das ebenso. Die Office 365 Anmeldung vom Konzern Account läuft über die Identity Verwaltung des Konzerns. Wenn ich also bei Microsoft mich anmelde mit Firmen-Email und ich sage: Firmenkonto, dann fragt mich Microsoft nicht nach einem Passwort sondern ich lande auf der Login-Seite vom Identity System des Konzerns. Und da kann ich dann Smartcard (Ist dann eigentlich eine Client Certificate Anmeldung), 2FA mit Code-Generierung, eigens generiertem OTP, ... wählen. 

Das ist, was im Business Bereich immer verbreiteter wird. Zu der Firma gehört dann ein identity management - in welcher Form auch immer. Und da werden dann User mit Rollen und so definiert und an der zentralen Stelle erfolgt die Autorisierung. Dienste wollen dann nur noch eine solche und dann gibt es Single Sign On und solche Dinge. Ich muss mich also nicht ständig neu anmelden.

Auch im privaten Bereich findet sich das immer mehr. Anbieter unterstützen andere Identity Provider. Das kann alles mögliche sein:
- Google findet sich sehr oft. Bestes Beispiel ist das Forum hier. Ich habe meinen Google Account verknüpft und damit melde ich mich mit Knopfdruck an (Im Browser bin ich halt auch angemeldet und habe da mein Profil). Microsoft bietet das wohl jetzt auch, aber ist nicht so sehr verbreitet.
- Facebook findet sich sehr stark im privaten Bereich, wo Sicherheit wenig Relevanz hat.
- In Entwickler Bereichen habe ich öfters Github als Identity Provider gesehen. Dann konnte man sich mit Github Account anmelden.
- Bei Blogs ist wordpress.com teilweise ein Identity Provider. Sie hosten viele Blogs direkt und WordPress ist auch weit verbreitet als Tool für Blogs auf eigenem Server. Da bietet sich das an (Aber evtl. braucht man ein kostenpflichtiges AddOn) ...
- ...

Nur zu dem konkreten Problem stellt sich dann die Frage:
- Was für Anbieter müssen unterstützt werden? Bieten die entsprechendes an? IMAP mag im privaten Bereich (noch) funktionieren, aber im gewerblichen Bereich scheitert es bei allen, die etwas mehr auf Sicherheit achten. Ich bin da mit Kleingewerbe schon ein gutes Beispiel...
- Wie aufwändig wird es, dies zu unterstützen? Nicht nur die einmalige Implementierung ist hier wichtig, sondern auch die Unterstützung. Das sind ja lebendige Verfahren - Google ändert da ja auch durchaus mit der Zeit etwas daran. Die APIs werden so in der Form nicht ewig existieren.

Aber man kann technisch diese IMAP Lösung anbieten. Man kann dann andere Verfahren nach und nach dazu nehmen. Rein technisch gesehen ist dies eine valide Herangehensweise. Im Kleinen wird dies ja so gemacht (Mail Programm auf dem Desktop um nur ein Beispiel zu nennen). Nur wenn mein Client gehackt ist, dann bin ich da erst einmal nur betroffen (so ich IMAP nutzen würde). Mein Risiko. Ich gebe das Passwort aber nicht an andere, die es dann kennen, weil sie das Passwort verwenden wollen.

Bezüglich dieser verfahren kann man sich auch mal Anschauen, was z.B. Clients so anbieten. Evolution / KMail fallen mir da ein. Beide unterstützen Google API und es gibt Erweiterungen für Exchange / Office365 und so (Meine ich - habe ich noch nicht benutzt).

Ich selbst hätte aber auf jeden Fall gewisse bedenken und würde diese entsprechend kommunizieren. Ich habe keine Ahnung, wo du arbeitest - bei kleinen Klitschen wäre evtl. nur der Chef da. Bei größeren Firmen gibt es dafür Ansprechpartner für Security und auch Datenschutz, die ich mit ins Boot nehmen würde. Ansonsten bist du der Kleine Depp, der verhauen wird, wenn da sowas raus kommt - meine Reaktion a.la. "Wo arbeitest du - damit ich sicher sein kann, da keine Geschäftsbeziehung zu haben" zeigt, was da für ein Risiko besteht: Wenn da sowas raus kommt, dann gibt es einen gewissen Shitstorm, d.h. das Ansehen der Firma leidet extrem. Bei einem Konzern an der Börse ist das fatal. (Beispiel hier Siemens: Kleiner, dummer Vertrag als Zulieferer für irgendwas, was manchen nicht passt aus Umweltsicht. Auftragsvolumen 100.000€ oder so, also aus Sicht von Siemens Peanuts! ... und dann gibt es einen riesen Shitstorm und Siemens Aufsichtsrat bietet sogar an, eine der Haupt-Aktivistinnen anzuhören und so ... Das der Aufsichtsrat so einen kleinen Deal behandelt kommt auch eigentlich nie vor ... Und bei sowas stellt sich die Frage: Wenn Du in einem solchen Konzern bist: Willst Du als Personalie vom Aufsichtsrat behandelt werden?  Naja - wenn alle aus dem Aufsichtsrat Deinen Namen kennen muss das nicht zwangsläufig was schlechtes sein ...  Aber ich fürchte Du bist nicht bekannt, weil Du den Umsatz mit einer einfachen Idee verdoppelt hast oder Kosten halbiert hast oder so ...)


----------



## kneitzel (2. Dez 2020)

mihe7 hat gesagt.:


> Ach, natürlich gibts da was von Baeldung: https://www.baeldung.com/java-password-hashing


Das ist aber das Hashing von Passwörtern und nicht das verschlüsseln von Passwörtern um diese dann entschlüsseln zu können um diese dann zu verwenden.

Wenn man sich mit der Thematik etwas auseinander setzen möchte, dann wäre mein Tipp:








						Java Cryptography: Tools and Techniques
					

Between the standard Java Runtime and the Bouncy Castle APIs there is a rich tool set of APIs to help work with the maze of standards and protocols needed for secure communication, storage and identity management. This book will help you navigate that maze and shine light into some of the darker...




					leanpub.com
				




Edit: Da hat er beim return irgendwie gepostet und mir keine neue Zeile gegeben ... Muss der Fokus irgendwie nicht um Textfeld gewesen sein ...

Also was da gebaucht wird, ist also etwas wie es hier beschrieben wurde: https://examples.javacodegeeks.com/core-java/crypto/encrypt-decrypt-string-with-des/

Aber weil es hoch kritisch ist: Ich würde mich da intensiv einarbeiten. Security ist essentiell. Da muss ein Profi ran. Und ggf. nicht nur den Code selbst prüfen sondern das Unterfangen als Ganzes. Es gibt ja viel mehr Möglichkeiten:
a) Aufsplitten von Daten - also was ist in der Datenbank gespeichert und was nicht? (Also die Keys zum verschlüsseln / entschlüsseln würde ich nicht auch in die Datenbank packen....)
b) Absichern von Informationen: Datenbank kann ggf. in sich verschlüsselt sein. Bei Windows können die Keys an gesicherter Stelle sein, so dass da auch kein Admin heran kann sondern nur der User, unter dem es läuft, ....
c) Absichern des Codes: Hier muss man sich überlegen, was man machen kann, damit Angreifer er schwer haben, die Verfahren zu erkennen. Da gibt es dann auch diverse Möglichkeiten um Dinge zu verschleiern oder Zugriff zu erschweren. (Nicht optimal, aber die Latte hängt höher. Ich halte nichts davon ... Aber es ist ein Punkt, der beachtet werden kann / muss.)
d) Absichern der Hardware: Hardening von Systemen, Zugriffe minimieren. ggf. aufteilen um Zugriffe zu erschweren. Firewalls, .... Nur um mal zu spinnen: Es kann ein Webportal geben. Da können User Passwörter und so angeben. Da ist dann nur ein Schlüssel zum verschlüsseln. Die Verschlüsselten Daten gehen dann an ein anderes System. Zugriff bei der Schnittstelle ist aber nur das setzen von Daten. Zentrales System speichert dann die Daten. Hat aber keinerlei Keys.
Ein weiteres System kann dann Daten abrufen. Dieses System kann dann auch entschlüsseln. Das System kann dann auch gewisse Zugriffe nach außen machen. Aber nur auf bestimmte Systeme / ports. Zugriff von Außen ist nicht möglich.
Bei allen Systemen läuft nur das Minimum um Angriffsfläche zu minimieren. Erlaubte User sind jeweils auf ein Minimum eingeschränkt u.s.w.


----------



## mihe7 (2. Dez 2020)

kneitzel hat gesagt.:


> Das ist aber das Hashing von Passwörtern


Ja, das war das Subthema 


mrBrown hat gesagt.:


> SHA512 ist nicht für das Hashen von Passwörtern geeignet.


----------



## LimDul (2. Dez 2020)

Die anderee Alternativ - die übrigens eine Menge Probleme auch bezüglich Skalierung und Co löst und den Datenschutz nicht aus der Hand gibt (Mit einer Lösung gibt der Benutzer dir die volle Kontrolle über sein Postfach und du kannst darüber alles mögliche tun, E-Mails versenden, Nacktbilder abgreifen etc.).

- Für jeden angemeldeten Benutzer gibt es eine E-Mail Adresse bei einer Domain von dir, gerne kryptisch (ala amazon Kindle). z.B. gksagjksghsgkskgh@mailcheck.meinedomain.de
- Der Benutzer muss bei seinem E-Mail Provider eine Weiterleitung auf diese E-Mail Adresse einrichten *für die E-Mails, wo er will, dass die Sachen bei dir geprüft werden*
- Die gesamten Mails landen in einem IMAP-Postfach bei dir
- Der gesamte Check kann bei dir gegen ein Postfach laufen - ist damit deutlich performanter.


----------



## beta20 (2. Dez 2020)

LimDul hat gesagt.:


> Die anderee Alternativ - die übrigens eine Menge Probleme auch bezüglich Skalierung und Co löst und den Datenschutz nicht aus der Hand gibt (Mit einer Lösung gibt der Benutzer dir die volle Kontrolle über sein Postfach und du kannst darüber alles mögliche tun, E-Mails versenden, Nacktbilder abgreifen etc.).
> 
> - Für jeden angemeldeten Benutzer gibt es eine E-Mail Adresse bei einer Domain von dir, gerne kryptisch (ala amazon Kindle). z.B. gksagjksghsgkskgh@mailcheck.meinedomain.de
> - Der Benutzer muss bei seinem E-Mail Provider eine Weiterleitung auf diese E-Mail Adresse einrichten *für die E-Mails, wo er will, dass die Sachen bei dir geprüft werden*
> ...


Finde ich eine gute Idee, vielen Dank.

Ist euch eine Möglichkeit bekannt ein IMAP Postfach automatisch via API anzulegen? Das sollte automatisch gehen, ich möchte nicht "händisch für jeden User immer ein Imap Postfach anzulegen". Habe mit IMAP Postfächer jetzt aber auch nicht wirklich große Erfahrung bisher gemacht...


----------



## LimDul (2. Dez 2020)

E-Mail Server nehmen, der das kann. Ist aber die Frage ob man wirklich für jeden user ein Postfach will oder ein Postfach für alle, was einfacher zum überprüfen ist - aber dazu kenn ich die Anforderung nicht genug.


----------



## beta20 (2. Dez 2020)

Wobei ich gerade glaube, dass das für mein Vorhaben nicht funktioniert, da ich dann nicht mehr den richtigen Sender habe...

Hier mein Ablauf, den ich gerade vor Augen habe:

1) User hat seine eigene Emailadresse bei mir auf dem System (user1121212122@myapplication.com)
-----
2) Neue Email geht bei "richtiger" Emailadresse ein (zB. user1@gmail.com). Sender ist "customerFromUser@gmail.com"
3) Email wird weitergeleitet an "user1121212122@myapplication.com" von "user1@gmail.com"
-> Soweit so gut...

In der Email Inbox user1121212122@myapplication.com ist nun aber "user1@gmail.com" der Sender... 
Ich möchte aber als Sender "customerFromUser@gmail.com"... haben.
-> Um unter anderem: alle Emails von customerFromUser@gmail.com bekommen. Wann war die letzte Kommunikation usw. usw.

Oder habe ich ein Denkfehler?


----------



## LimDul (2. Dez 2020)

je nach dem wie man die Weiterleitung einrichtet, müsste das trotzdem gehen, wenn sie richtig eingerichtet ist.

Aber andere Frage, hast du dir da überhaupt mal Gedanken um DSGVO gemacht? Wenn es geschäftlich ist, brauchst du da entsprechende Vereinbarungen mit jedem deiner Kunden. Denn wenn ich eine Mail an Firma X schicke und auf diese E-Mail hast du Zugriff - dann ist das eine Verarbeitung von persönlichen Informationen, wofür die DSGVO hohe Hürden aufstellt. Insbesondere wenn du das Passwort entschlüsselbar speicherst, bewegst du dich in Regionen, wo die Bußgelder im 5-stelligen Bereich vermutlich anfangen, wenn mal was schiefläuft.


----------



## kneitzel (2. Dez 2020)

Also man kann problemlos IMAP Postfächer automatisch anlegen. Die Frage ist, welcher IMAP Server und wie der konfiguriert wurde. Das kann ein einfacher Datenbank Eintrag sein.

Aber was genau willst Du denn machen? Warum willst Du selbst IMAP Postfächer anlegen?

Also bei so einem Anti-Spam Dienst (Ist es das? Sowas gibt es bereits .. habe ich auch lange genutzt, ehe ich dann einen eingebauten Schutz hatte, der ok ist) brauchst du das nicht. Alles was Du brauchst ist:
a) Eine Funktion, um SMTP Emails zu empfangen (Für User, die z.B. in einer Datenbank liegen)
b) Die Prüfung auf was auch immer, ggf. Veränderung (Header hinzufügen, Subject ändern, ...)
c) Dann ggf. die Weiterleitung an die Zieladresse

Oder brauchst Du sowas wie ein Quarantäne Postfach?

Generell gibt es ja genug solcher Dienste. Da kann man sich ja mal etwas umschauen.

Und dann sollte man sich mit der Technologie vertraut machen, also mal mit Leuten reden, die die notwendige Technik kennen oder sich selbst mit dieser auseinander setzen. Was für ein Server soll denn da verwendet werden? Oder wollt ihr das alles selbst schreiben? (Unnötige Arbeit aus meiner Sicht. Da kann man wirklich auf bestehender Software aufsetzen. SMTP Server und IMAP/POP3 Server gibt es ja genug. Und ankommende Emails könnten dann Prozesse starten, die dann das eigene System anstoßen. Dann muss man nur noch die Filter Technologie schreiben ... wobei es da auch genug fertige (Open Source) Lösungen gäbe ... da würde dann alles nur noch auf ein reines Verwaltungs Frontend hinaus laufen, damit die Erkennung möglichst gut ist...

IMAP Server kann z.B. Dovecot sein -> https://doc.dovecot.org/ würde ich da empfehlen.



beta20 hat gesagt.:


> Wobei ich gerade glaube, dass das für mein Vorhaben nicht funktioniert, da ich dann nicht mehr den richtigen Sender habe...
> 
> Hier mein Ablauf, den ich gerade vor Augen habe:
> 
> ...



Ja, Du kannst Emails doch forwarden. In den Headers ist dies durchaus erkennbar. Aber das sind alles Dinge, die sonst nicht erkennbar sind. From: und To: bleiben. Beim weiter reichen gibt es den Envelope - da hat man Sender / Receiver. Das ist dann das, was man bei SMTP mit angibt. Man verbindet sich und sagt erst mal ein freundliches Hallo von wem auch immer. Dann kommt die Info für wen man eine Email hat und so der Server die haben will, gibt man dann die Email und beendet die Übertragung mit einem . auf einer Zeile.
So mal ganz grob zusammen gefasst. Das kann man aber noch alles in RFCs nachlesen. Darüber hinaus wird es noch mehr interessante Dinge geben, die Mailprovider machen. Aber da wirst Du dann bestimmt selbst regelmäßig überrascht ...

Aber diese Envelope sind später nicht sichtbar. Die sind nur zwischen den Mailservern bekannt. Ist auch wichtig, denn es gibt ja auch Verteiler und Maillisten - da ist es ja auch üblich, dass eine Email weiter gereicht wird.

==> Über Standards schlau machen. Da sollte man halbwegs Sattelfest sein. Es kommen noch genug Überraschungen! (Ich habe lange Zeit einen eigenen Mailserver betrieben für meine Domains. Das habe ich dann aber auch sehr gerne aufgegeben, denn es ist einfach nicht mehr schön. Die Provider sind teilweise sehr aggressiv was Spam Vermeidung angeht. Greylisting ist da nur ein Beispiel: Eine Email wird x Stunden nicht angenommen mit der Bitte, es später erneut zu probieren. Kein Thema - SMTP Server machen das automatisch und Infizierte Clients nicht. Die probieren es nicht erneut mit dem Effekt, dass Spam vermieden wurde. Nur eben kommen Emails erst sehr verspätet an. Bei großen Mailservern kein Thema - denn nachdem ein Mailserver das erfolgreich gemacht hat, ist er für x Stunden auf einer Whitelist. Und jede Erfolgreiche Email setzt den Wert wieder auf x Stunden ... Also große Mailserver untereinander haben sich in der Whitelist. Mein kleiner Server ist da eher problematisch und es gibt Verzögerungen.
Oder einfaches Beispiel Google Mail - ich habe eine Domain, die ich nicht in GSuite integrieren kann, weil da viele Forwardings sind. Die kann GSuite nicht. Die mögen nur Aliase auf User in GSuite. Also einfach vom Provider ein Forward gemacht - aber da da auch Spams dabei waren, war das im Nu gesperrt. (Ja, die Adresse ist halt auch in diversen Domains hinterlegt. Ohne Filter sind da einige Spams drin.... und ist nicht meine Haupt-Adresse ... also wenig nicht Spam Emails ... ) Ein Forwarding war nicht möglich. Nette überraschung! (pop3 Abholen geht - wobei da nicht alle Mails abgeholt werden. Daher wird auch automatisch nach x Tagen der Eingang gelöscht. Was nicht abgeholt wird, landet automatisch im Müll, so dass das Postfach nicht voll läuft...

Wozu diese Beispiele? Ich will nur aufzeigen, dass es mit Providern noch nette Überraschungen geben kann. Das sollte man immer im Hinterkopf behalten! Daher sollte man sich die Thematik sehr gut ansehen, damit man auch reagieren kann. Und das Gebiet ist sehr dynamisch: Da überlegen ständig die Spammer, wie sie ihren Spam dennoch los bekommen (Sie greifen Mailserver gerne an, denn Du bist ja vielleicht vertrauenswürdig gegenüber anderen Servern ... also bist Du sofort ein Angriffsziel!) und die Provider reagieren da auch ständig drauf. Und wenn ein Angriffsvektor bekannt ist, dann scannen sie Server auch - also kann sein, dass Du eine Email abgeben willst und bekommst eine Greylist Antwort. Und parallel wird dann erst einmal Dein SMTP Port gescannt, ob Du offen für den Angriffsvektor sein könntest .... Alles schon erlebt 

Ach ja - da wird auch deutlich: SMTP != SMTP. Da gibt es einmal den Bereich, der offen ist: Ein Mailserver liefert beim anderen etwas ab. Da findet keine Autorisierung statt. Dementsprechend hart sind die Prüfungen und dementsprechend wenig wird erlaubt (Also z.B. nur Annahme von Emails für lokale User, kein sogenanntes Relaying). Und dann noch das Versenden von Emails von bekannten Usern. Lokale User verbinden sich, melden sich an um dann Emails abzugeben. Da gelten dann andere Regeln (z.B. bezüglich From: Header. Wenn der nicht passt, dann wird ggf. ein Sender: eingefügt um den User zu identifizieren. ...

Das einfach mal von meiner Seite aus ...

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 ...


----------



## LimDul (2. Dez 2020)

kneitzel hat gesagt.:


> 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 (2. Dez 2020)

LimDul hat gesagt.:


> 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 (2. Dez 2020)

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 (2. Dez 2020)

mihe7 hat gesagt.:


> 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 (2. Dez 2020)

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


----------



## beta20 (3. Dez 2020)

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.
> 
> ...



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


----------



## LimDul (3. Dez 2020)

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 (3. Dez 2020)

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.
> 
> ...


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 (3. Dez 2020)

Zum Video: 





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


----------



## thecain (3. Dez 2020)

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


----------

