(web)mailserver mit mysql/postfix/courier/squirrelmail

[mmueller]

hi gemeinde und lesende,
vor ca. 1 1/2 jahren habe ich angefangen, mir einen mailserver softwaretechnisch zusammenschrauben zu wollen.
leider hat das, so wie ich es vorhatte nicht funktioniert.

hier ist mein erster leidensweg beschrieben, falls später mehr infos erforderlich sind:
http://forum.webmasterpro.de/viewtopic-t-35253-start-0-postdays-0-postorder-asc-highlight-.html


meine wünsche für einen sicheren betrieb des servers waren und sind immer noch:

-die user sollen ihre mails via imap(s) und pop3(s), sowie über webmail/http(s) bereitgestellt bekommen.

-für webmail soll squirrelmail eingesetzt werden. die userdatenbank (also name/mailaddy/pw/etc), auf die squirrelmail zugreifen soll, soll in einer mysql datenbank, in der die user ihre passwörter ablegen/ändern können (via squirrelmail oder einem entsprechenden squirrelmail-plugin) gespeichert werden. die passwörter der user (innerhalb der mysqldatenbank) sollen *verschlüsselt* sein, d.h. ich möchte sie nicht sehen, wenn ich mal die datenbank administrieren muss/soll. das ist wichtig!

-die user sollen über ihre bevorzugten hausmailprogramme (thunderbird/outlook/the bat/etc) via normal pop3/imap, aber auch geschützt via SSL auf ihre mails zugreifen können. für die zustellung soll postfix/courier zuständig sein.

-die mailversendung soll geschehen, via smtp und authentifizierung durch vorheriges abholen der mails (pop before smtp). über SSL, oder, wenn der mailclient das nicht kann, halt normal smtp. sollte SASL dafür besser geeignet sein, super.

all das sollte brav auf einer debian distribution laufen. und -wenn möglich- ohne patches oder sonstigen "brassel/umlinken/recompilieren" auskommen, so das bei einem update eines dienstes oder so sonstigen programmen nicht plötzlich nichts mehr richtig zusammenarbeitet oder die user nicht mehr an ihre mails kommen.

ich erwarte nun natürlich keine schritt für schritt anleitung, aber mich würde vor allem interessieren, ob das mittlerweile, und wenn ja, mit welcher software/welchen diensten funktioniert/funktionieren kann. evtl. denke ich auch zu weit/zu kurz oder habe einen falschen ansatz?
wichtigste prio: die daten sollen verschlüsselt über das netz gehen, wenn es möglich ist. d.h. sollte an einem flughafenterminal kein https gehen, möchte ich trotzdem auf meine mails via web zugreifen können, wenn ich das möchte. selbiges in einem internetcafe in buxdehude mit z.b. einem schnell installierten thunderbird (der zwar mittlerweile auf dem usbstick ist, aber man kennt das ja...)

ich bin nun nicht der mega-crack, was das confen von postfix/courier/sasl angeht, habe mich aber viel eingelesen, doch fehlt halt die erfahrung, so das es auch beim hundertundfünften versuch nicht geklappt hat und mir die motivation genommen hat. nun also, nach einer längeren pause möchte ich wieder beginnen.

die versuche, die geklappt haben, war ein system aufzusetzen, das alles konnte was ich oben beschrieben hatte, ausser das die passwörter in der mysql datenbank verschlüsselt waren. und so geht das halt nicht, IMHO. nach vielem rumconfen ging dann irgendwann auch kein sasl/tls mehr und noch weiter später hab ich dann enttäuscht und entnervt aufgegeben. ich hoffe, das mit der zeit evtl. ein paar howtos ins netz gekommen sind, die sich meiner idee/sache angenommen haben, aus denen ich schöpfen kann und, bei erfolgreichem abgucken und mutieren, diese auch bereichern kann, aber bislang sitze ich noch auf dem trockenen und finde nichts (richtiges).

so, genug der worte.

ich wäre allen sehr verbunden, wenn mir etwas unter die arme gegriffen würde


p.s.

eine seite, die ich mitlerweile gefunden habe, die auch sehr informativ und ausführlich ist: http://flurdy.com/docs/postfix/#conf_data
leider finde ich auch dort diese zeilen, die mir sagen, das mein vorhaben sich mit diesem howto nicht verwirklichen lässt.

# comment out this field,
# as I now longer use the encrypted pw options
#MYSQL_CRYPT_PWFIELD crypt
MYSQL_CLEAR_PWFIELD clear

 

[Huschi]

Hallo mmueller,

willkommen an Board.
Ich muß Dich leider erstmal auf Punkt 3 unserer Boardregeln hinweisen.

Zu Deinen Fragen:
a) Es klingt alles nach einer std. Installation eines Mailservers.
Entweder Exim
oder Postfix + Postfix-tls + Courier IMAP.

b) Du hast wiedersprüchliche Angaben bzgl. Sicherheit/Verschlüsselung gemacht:

die daten sollen verschlüsselt über das netz gehen, wenn es möglich ist. d.h. sollte an einem flughafenterminal kein https gehen

Was denn jetzt? Verschlüsselt oder ohne https? HTTP ist nun mal unverschlüsselt.

ausser das die passwörter in der mysql datenbank verschlüsselt waren

Was spricht dagegen die (Auth-)Passwörter in der Datenbank unverschlüsselt abzulegen?

huschi.

 

[mmueller]

willkommen an Board.
Ich muß Dich leider erstmal auf Punkt 3 unserer Boardregeln hinweisen.

Danke. Ich habe gehofft, das überseht ihr ich werde mich bemühen. Habe das seit seit der Schulzeit micht mehr gemacht...

Zu Deinen Fragen:
a) Es klingt alles nach einer std. Installation eines Mailservers.
Entweder Exim oder Postfix + Postfix-tls + Courier IMAP.

Es mag sein, das es danach klingt, ich meine allerdings, das es das nicht ist. Mit einem Standartserver bin ich nicht zufrieden, weil man nicht die möglichkeiten hat, die ich gerne hätte ;->
Sollte es natürlich eine Standardinstallation sein, die exakt meine Wünsche erfüllt, wäre ich mehr als froh und zufrieden mit dieser Aussage. Howtos gibt es ja dafür genügend. Nur ist mir immer wieder aufgefallen, das in all diesen Howtos mit Klartextpasswörtern gearbeitet wird.

b) Du hast wiedersprüchliche Angaben bzgl. Sicherheit/Verschlüsselung gemacht:
Was denn jetzt? Verschlüsselt oder ohne https? HTTP ist nun mal unverschlüsselt.

Die Betonung liegt, oder besser, lag auf *wenn*. D.h. der Server soll SSL/HTTPS standardmäßig anbieten, aber *wenn* die Gegebenheiten der User dies nicht hergeben (habe es ja beispielhaft angeführt) soll man auch auf "normalem" Wege an seine Mails kommen. D.h. z.b. bei Squirrelmail werde ich, wenn ich von der Hauptseite aufmerksam gemacht, das ich auf den Server auch via HTTPS gelangen kann und nicht via HTTP, wie es gerade der fall ist (gibt es ja schöne Plugins für), oder, wenn aus irgendeinem Grund es für den User unmöglich sein sollte, Mails via POP3s abzurufen, soll er seinen Client halt umstellen können.

Was spricht dagegen die (Auth-)Passwörter in der Datenbank unverschlüsselt abzulegen?

Der Sicherheitsaspekt, den ich meinen Usern gewähren möchte. Muss es denn wirklich sein, das ein Admin die Passwörter seiner User sehen kann? Ich denke nicht.
Selbst, wenn es nur Freunde sind und sie mir vertrauen, dann interessieren mich ihre Passwörter trotzdem überhaupt nicht. Wenn ich aber mal - und das wird unvermeidlich sein - in der Datenbank arbeite, werde ich gezwungenermaßen die Inhalte der Tabellen und Felder sehen. Und schon hab ich mir das Passwort gemerkt. Ohne es zu wollen. Das gefällt mir nicht. Und ich denke/hoffe, jedem sicherheitsbewussten anderen Menschen sollte dies auch einleuchten. Ich habe darüber schon mit vielen Usern gesprochen und es waren sehr wenig, denen dies egal war, die meinsten konnten mein anliegen verstehen.

Was sagst Du, oder Ihr zu dieser Einstellung? Bin ich damit allein auf der Welt, oder ist das evtl. übertrieben? Dazu habe ich noch wenig Menschen befragt.

Ich weiss bis dato nur, das ich meine Probleme mit dem Aufsetzen/confen der Dienste wohl nur deswegen hatte.
Ich habs jetzt nicht mehr ganz im Kopf, es wird also bestimmt technisch falsch/irreführend sein, was ich nun mitteile, aber SASL verlangt die passwörter im klartext, damit es diese verschlüsselt über das netz senden kann. Mein Ansatz wäre ja dann irgendwie doppelt gemoppelt, bzw. irgendwo kann da irgendeiner mit dem verschlüsselten Passwort nichts anfangen.

 

[Huschi]

Was sagst Du, oder Ihr zu dieser Einstellung? Bin ich damit allein auf der Welt, oder ist das evtl. übertrieben?

Die Einstellung ist ja korrekt. Nur warum soll man erzwingen was (zumindest anscheinend) technisch nicht geht. Alternativ kann man das technisch machbare umsetzen und dafür die Datenbank entsprechend besser schützen.
Ausserdem darf man den Aspekt 'Ich habe mein Passwort vergessen' nicht ausser acht lassen.

aber SASL verlangt die passwörter im klartext, damit es diese verschlüsselt über das netz senden kann.

Das ist falsch.
SASL läuft bereits auf dem Server. Dort müssen die Passwörter im Klartext ankommen. (Zumindest bei den Methoden LOGIN und PLAIN.)
Mit TLS (oder auch https) wird der Datentransfer verschlüsselt, so daß keiner (der an der Leitung horcht) das Passwört herausfiltern kann.

huschi.

 

[mmueller]

Warum soll man erzwingen was (zumindest anscheinend) technisch nicht geht. Alternativ kann man das technisch machbare umsetzen und dafür die Datenbank entsprechend besser schützen.

Sicher, Datenbank schützen. Aber nicht als Alternative, sondern zusätzlich, ist meine Meinung.
Da ich bei dem Aspket der technischen Umsetzung auf die Hilfe anderer, mitunter Euch, angewiesen bin, bzw. zurückgreifen muss, würde ich gerne wissen/verstehen, *was* genau da technisch nicht möglich ist, bzw. *wo* genau der Haken nicht in die Öse passt. Kannst Du mir da Auskunft geben?
Das, was ich bis dato gefunden habe, ist dies:
http://lists.suse.com/archive/suse-linux/2004-Aug/2219.html
Und wenn ich "Und wenn du Pech hast, taucht das Passwort in allen Logdateien auf." lese, wird mir übel.

Ausserdem darf man den Aspekt 'Ich habe mein Passwort vergessen' nicht ausser acht lassen.

Ich bin der Meinung, das muss man sogar ;-) denn sonst kommen sie alle 5 Wochen an....
Nein. Wer sein pw vergessen hat, bekommt ein neues, bzw. hat auf der Webseite die möglichkeit eins/das alte zu bekommen (man kennt ja diesen "passwort vergessen"-link).

Das ist falsch.
SASL läuft bereits auf dem Server. Dort müssen die Passwörter im Klartext ankommen. (Zumindest bei den Methoden LOGIN und PLAIN.)
Mit TLS (oder auch https) wird der Datentransfer verschlüsselt, so daß keiner (der an der Leitung horcht) das Passwört herausfiltern kann.

Danke für die Richtigstellung.

 

[Huschi]

Sicher, Datenbank schützen. Aber nicht als Alternative, sondern zusätzlich, ist meine Meinung.

Du erinnerst mich gerade an ein Kind, welches auf den Bodenstampft und dauernd schreit "ich will aber!".
Wie wäre es, wenn Du einfach mal langsam angehen würdest. So Schritt für Schritt und damit auch ein Ziel erreichst statt gleich von hier bis zum Mond springen zu wollen?

Und wenn ich "Und wenn du Pech hast, taucht das Passwort in allen Logdateien auf." lese, wird mir übel.

Mir auch, wenn ich mir so einen Schwachsinn durchlese. Bah, der Typ sollte sich schämen, solchen Schwachsinn zu schreiben.

Auf der anderen Seite zeigt das nur, daß Dir das ganze Verfahren noch recht fremd ist. Du schmeißt zwar mit vielen Stichwörtern um Dich, aber der globale Zusammenhang fehlt.

Mein Rat für Dich:
Stell Dir einen Plan zusammen mit den Spalten:

• was Du willst
• womit dies zu lösen ist
• was Du schon kannst
• was nicht zur Zurfriedenheit gelöst wurde

Versuche vorallem die 1.Spalte gut und sinnvoll zu sortieren/kategorisieren.

Und dann fragst Du uns nach den Lücken indem Du jeweils ein Problem möglichst exakt beschreibst.

huschi.

 

[mmueller]

Der MasterPlan

Hallo Huschi,

Du erinnerst mich gerade an ein Kind, welches auf den Bodenstampft und dauernd schreit "ich will aber!".
Wie wäre es, wenn Du einfach mal langsam angehen würdest. So Schritt für Schritt und damit auch ein Ziel erreichst statt gleich von hier bis zum Mond springen zu wollen?

Danke für Deine Meinung. Ich erkenne mich wieder. Nur ist es so, das, so wie ich meine, ich die Schritte schon gegangen bin. Und das mehrfach.
Ich weiss nicht, ob du dies in meinem Eingangsposting gelesen hast:

hier ist mein erster leidensweg beschrieben, falls später mehr infos erforderlich sind: http://forum.webmasterpro.de/viewtopic-t-35253-start-0-postdays-0-postorder-asc-highlight-.html

dort ist, wie ich meine, beschrieben, das ich ab einen gewissen Punkt nicht mehr weiterkomme, bzw. die Übersicht verliere/verloren hab. Ob meiner Sachunkenntnis, oder den fehlenden, für mich verstehbaren, Anleitungen, sei nun einmal dahingestellt.

Bah, der Typ sollte sich schämen, solchen Schwachsinn zu schreiben.

Das kann ich nicht beurteilen, da dieses Gebiet Fremdland für mich ist. Es wäre allerdigns schön, wenn Du auch begründen könntest, was Du da sagst.

Auf der anderen Seite zeigt das nur, daß Dir das ganze Verfahren noch recht fremd ist. Du schmeißt zwar mit vielen Stichwörtern um Dich, aber der globale Zusammenhang fehlt.

In der Tat bin ich daran interessiert zu lernen. Ich versuche mein bisheriges Wissen, das nun schon etwas verschwommen ist, durch die lange Zeit, die zwischen dem ersten Posting (s.Link oben) und diesem hier vergangen ist, noch einmal aufzufrischen und weitere Hürden zu nehmen, über die ich damals nicht alleine gekommen bin. Deswegen mein Posting hier. Ich erwarte hier natürlich nicht, das persönlich auf mich eingegangen wird, auch wenn ich mich freue, das Du bestimmte Eigenschaften von mir, mit Deinen Kommentaren hervorhebst oder bemerkst, deren ich mir auch bewusst bin, aber, soweit ich das bis jetzt beurteilen kann, kannst Du (es hat ja noch niemand anderes etwas hierzu beigetragen) mir auch nicht sagen, ob das Vorhaben von mir technisch umzusetzen ist, oder nicht. Und vor allem: mit welchen Mitteln.

Deinen Rat habe ich mir zu Herzen genommen und mir das oben erwähnte Posting aus vergang'ner noch einmal durchgelesen.
Ich meine, dort steht alles drin, was gefordert ist.

(Eine schöne Übung. Ich nehme das zum Anlass, mich hoffentlich anders auszudrücken, denn evtl. ist es ja so, das meine Worte, so wie ich sie wähle, nicht verstanden werden)
Ich fasse es aber nocheinmal zusammen:

[*1*]was ich will

1a0) ein Mailsystem, auf das öffentlich zugegriffen werden kann.

1b0) der Zugriff soll via Webmail geschehen können, und zwar über die Protokolle HTTPS, und, im Notfall, HTTP.
1b1) User sollen Ihre MailPasswörter via Webinterface ändern können.

1c0) der Zugriff soll via Mailclient der User geschehen können, und zwar über die Protokolle POP3s und IMAPs.
1c1) auch diese Zugriffe, sollen, im Bedarfsfall, über POP3 und IMAP, also bei unverschlüsselter Leitung, möglich sein.

1d0) der Mailversand, via Mailclient der User, soll genau so sicher gestaltet werden, wie der Empfang der Mails.
*Hier fehlt mir ein bestimmter Wunsch. Was böte sich an?

1e0) Das zugrundeliegende Userverwaltungssystem soll auf Basis einer MySQL-Datenbank laufen. Somit ist eine einfach(ere) Verwaltung der User(-daten) möglich, wie ich meine.
1e1) Passwörter, die die User über das Webmailsystem ändern können, sollen *nicht*, im Klartext in der Datenbank gespeichert werden.


zu punkt c10) ist nicht unbedingt erforderlich, falls es dadurch zu Komplikationen kommen kann, bzw. muss der User dann halt auf einen Mailclient umsteigen, der die Forderungen des Mailservers erfüllt.



[*2*]womit könnte ich es lösen

Bis dato wurden mittlere, bis gute Erfahrungen gemacht mit:

2a0) Apache/SSL für die Anbindung und die Bereitstellung der Webseiten des Webmailsystems an die Welt.

2b0) SquirrelMail, als WebMailClient. Er ist durch diverse Plugins sehr gut zu erweitern.
2b1) Es gibt diverse Plugins, die das ändern von MailPasswörtern in einer Datenbank (und mit verschiedenen Verschlüsselungen) erlaubt.

2c0) Courier IMAP(s)/POP3(s), als Grundlage für Squirrelmail und für den Zugriff auf die Mails via IMAP und/oder POP3.
2c1) dito

2d0) Postfix, als MTA. Die Zusammenarbeit mit einer Datenbank (1e0) ist hiermit möglich.

2e0) MySQL, als Datenbank




[*3*]was ist mir bis jetzt mit meiner standardinstallation möglich

3a0) ich sehe meinen WebMailserver im Internet. via HTTP oder HTTPS

3b0) ich kann via Web auf meine Mails zugreifen, sofern diese nicht durch das POP3-Protokoll von Server gelöscht wurden.
3b1) Ich kann mein MailPasswort ändern.

3c1) Ich kann Mails via POP3/IMAP abholen/lesen. (outlook/thunderbird/etc)

3d0) Ich kann Mails versenden.

3e0) Ich kann dem MailSystem einfach User hinzufügen und/oder ändern/löschen.



[*4*]was ist nicht zu meiner Zurfriedenheit gelöst

4a0) alles super.

4b0) alles super.
4b1) (Nur, wenn ich mit der Verschlüsselung innerhalb des Passwortfeldes in der Datenbank herumexperimentiere Ich kann mein MailPasswort via Squirrelmail nicht ändern. Das hängt imho allerdings damit zusammen, das ich noch nicht die richtige vermittlung (einstellungen) zwischen dem Squirrelmailplugin und dem entsprechenden Datenbankfeld/-eintrag gefunden habe.

4c0) Ich kann nicht Mails über eine verschlüsselte Leitung empfangen, bzw. wird das Mailpasswort im Klartext versendet.

4d0) Ich kann nicht Mails über eine verschlüsselte Leitung versenden, bzw. wird das Mailpasswort im Klartext versendet.

4e0) alles super.


Weitere Unzufriedenheiten meinerseits:

Es wurde viel am System "gepatched/gebogen". Ich habe die Befürchtung/Vermutung, das nach einem Update eines Dienstes, nicht mehr viel ineinanderlaufen wird.




Hier noch ein Zitat, auf das ich reagieren möchte.

warum soll man erzwingen was (zumindest anscheinend) technisch nicht geht.

Erzwingen möchte ich es nicht, falls es mir aber mit Deiner/Eurer Hilfe gelingen sollte, zu begreifen, warum es anscheinend nicht funktioniert, oder funktionieren kann, wäre ich schoneinmal sehr viel weiter. Eine Lösung wäre sogar noch schöner Bis jetzt ist auf dieses Thema noch niemand eingegangen, ausser das es mit "das geht nicht[tm]" abgetan wurde. Keine Lösung, mit der ich zufrieden bin. Ich weiss ja nun auch nicht, ob ich Euch hier mit meinen Anforderungen überfordere, oder ob es einfach nur eine inkompabilität der Sache an sich ist. Auch hier ist noch niemand drauf eingegangen, sofern es Sinn macht.

SASL läuft bereits auf dem Server. Dort müssen die Passwörter im Klartext ankommen. (Zumindest bei den Methoden LOGIN und PLAIN.)
Mit TLS (oder auch https) wird der Datentransfer verschlüsselt, so daß keiner (der an der Leitung horcht) das Passwört herausfiltern kann.

Auch hierzu nachträglich noch eine Frage:
Wenn also bei TSL der Datentransfer verschlüsselt ist, muss das zu übertragende Passwort sich im Klartext befinden, oder kann es auch verschlüsselt sein?


Falls es noch Fragen/Anregungen zu dem "Plan" gibt, nur zu.

Danke für Deine/Eure Zeit ersteinmal.

 

[Huschi]

Viel viel Text.
Ich lass daher jetzt mal ein paar unwichtige Punkte aus.

ob du dies in meinem Eingangsposting gelesen hast:
[...]
dort ist, wie ich meine, beschrieben, das ich ab einen gewissen Punkt nicht mehr weiterkomme, bzw. die Übersicht verliere/verloren hab.

Ich hab es gerade überflogen. Aber letztendlich ist das dort auch nur eine Diskussion über machbarkeit ohne die konkreten Probleme.

Was ich will, ist:
Du setzt ein Testsystem auf (soweit noch nicht vorhanden), machst soweit und soviel es geht und dann stellst Du hier konkrete Fragen zu jeweils nur einem Problem (eine Übersicht Deiner Probleme hast Du ja jetzt):
- Was soll gemacht werden?
- Was wurde von Dir geändert?
- Was funktioniert nicht mehr?
- Was steht in den Logfiles?

Und dann arbeiten wir an dem Problem bis es funktioniert.
Denn nur anhand der realen Fakten können wir Dir auch konkret helfen.
Alles was Du bis jetzt (und auch im Webmasterpro) geschrieben hast war rein fiktiv/virtuell. Keine Fakten, keine Logfiles, keine Configs. Sondern nur "ich hab das mal probiert und es ging dann nicht".
Verstehst Du was ich meine?

Bah, der Typ sollte sich schämen, solchen Schwachsinn zu schreiben.

[...] wenn Du auch begründen könntest, was Du da sagst.

Klar kann ich.
Die Aussage war: "Das Passwort taucht bei POP3/SMTP ohne TLS in allen Logfiles auf."
Das ist schlichtweg falsch.
a) Weder beim Sender noch beim Empfänger wird das Passwort in die Mail-Logfiles geschrieben.
b) Es bleiben also nur noch Paket-Logs übrig, die die vollständigen IP-Pakete mit loggen.
b1) Wenn ein Client so einen Paket-Logger laufen hat, ist das sein Problem.
b2) Du herrscht über den Server und solltest wissen ob ein Paket-Logger läuft.
b3) Bei allen Hops dazwischen würden Paket-Logger innerhalb von wenigen Sekunden jede Festplatte sprengen.
c) Es bleibt also nur ein gezielter man-in-the-middle-Angriff um eine unsichere POP3-/SMTP-Verbindung abzuhorchen. Ein zufälliges mitbekommen des Passwortes ist also nahe zu ausgeschlossen. Vorallem, da der dazugehörige Username in einem anderen TCP-Paket steht.

ob das Vorhaben von mir technisch umzusetzen ist, oder nicht. Und vor allem: mit welchen Mitteln.

Ich denke schon. Allerdings scheint das eigendlich Problem von damals nur das ablegen der verschlüsselten Passwörter in der DB gewesen zu sein.

Es wurde viel am System "gepatched/gebogen".

Auch das ist einfach nur eine Aussage ohne konkrete Fakten.
Was wurde konkret gepatched? Was heißt bei Dir 'gebogen'?

Wenn also bei TSL der Datentransfer verschlüsselt ist, muss das zu übertragende Passwort sich im Klartext befinden, oder kann es auch verschlüsselt sein?

TSL verschlüsselt nur die Datenübertragung. Du mußt Dir das wie ein Tunnel unter dem Rhein vorstellen:
Entweder Du schreibst die Daten auf eine Fahne und schickst ein Schiff über den Rhein. Alle interessierten, die zufällig ein Fernglas dabei haben (also nur die, die es wirklich agressiv versuchen) können sie lesen.
Oder Du schreibst die Daten auf ein Bus und der fährt durch den Tunnel. Keiner von oben kann die Daten lesen.
Aber gemeinsam haben beide Arten:
a) Auf der einen Seite werden die Daten im Klartext draufgeschrieben.
b) Auf der anderen Seite kommen die Daten im Klartext an.


Nochmals meine Kernaussage:
Bau ein System zum 'spielen'. (evtl. mit Backup etc.; kann ja auch in einer VMware laufen)
Teste daran rum, wie es geht oder gehen könnte und löcher uns dann mit den konkreten Fragen und den dazu gehörigen Fakten. (Mach dazu jeweils einen eigenen Thread auf. Für den globalen Zusammenhang kannst Du ja jeweils am Anfang auf diesen Thread verweisen.)
Aber kein 'ich will aber', 'geht das' und vorallem nicht 'damals hat es nicht, aber ich weiß nicht mehr genau'.

huschi.

 

[mmueller]

Der Angang

Ich denke schon. Allerdings scheint das eigendlich Problem von damals nur das ablegen der verschlüsselten Passwörter in der DB gewesen zu sein.

Exakt.

Du hast Recht. Ich werde also meine Einstellung von "sagt mir vorher ob es geht, damit ich es (nochmals) angehen kann", auf "ich werde es angehen und dann (hoffentlich mit Deiner/Eurer Hilfe) herauskriegen, ob und wie es geht, oder halt nicht."

Ich werde mich also wieder melden, wenn das System läuft und ich die entsprechenden Daten vorweisen kann.

Vielen dank f.d. Mühe und Aufmerksamkeit!