DLLs von .NET Framework einzeln mitliefern?

[ToolsDevler]

Hi Leute,

ich zerbrech mir seit Tagen den Kopf zu folgendem Problem:

Wenn ich ein Programm habe, das auf einem System installiert wird, wo keine (oder eine ältere) Version .NET Framework installiert ist, ist es mir dann erlaubt, DLLs aus .NET Framework innerhalb meines Softwarepackets mitzuliefern?

Macht es hier einen Unterschied, ob meine Software verkauft oder kostenlos angeboten wird?

Folgende Pro- und Kontrapunkte sind mir eingefallen:

Kontra:

- Der Kunde hat keine Lizensvereinbarung für .NET akzeptiert (könnte aber vllt auf deren Lizensvereinbarung verweisen?)

- Ich würde damit die die DLLs vervielfältigen

Pro:

- .NET Framework ist kostenlos

- Meine Software ist evtl auch kostenlos

- Ich kann explizit darauf hinweißen, dass die DLLs von Microsoft sind (und eventuell auch auf deren Lizensvereinbarung verweisen?).

Ich weise sicherheitshalber darauf hin, dass ich noch nichts in der Richtung gemacht habe, um evtl Unrechtmäßigkeiten zu vermeiden.

Hoffe ich konnte die Frage verständlich formulieren...

Grüße

ToolsDelver

[TDM]

Einzelne DLLs bringen nichts. (Abhängigkeiten, Betriebssystem, etc.)

Entweder der Kunde läd sich das Framework selbst runter, du integrierst eine Offline-/Download-Installationsroutine in dein Setup oder der Kunde muss es lassen. :floet:

[ToolsDevler]

Naja... eig hab ich sogar schon en eigenes Setup programmiert, aber gehofft, dass ich des ohne installiertes Framework aufrufen kann...

Danke für deine Mühe...

ToolsDevler

[Gateway_man]

Man nehme an auf dem Zielrechner währe kein .NET Framework installiert.

Und du willst jetzt statt das Framework zu installieren, einfach alle Dll's auf die dein Projekt verweißt mitliefern?

Hab ich das so jetzt korrekt verstanden?

Wenn ja dann folgendes dazu:

All deine ManagedCode Assembly's die du im .NET verfasst sind nicht nativ bzw. brauchen eine Laufzeitumgebung, die wie in diesem Fall das .NET Framework den IL Code in den jeweiligen Maschinencode übersetzt.

Ergo solange du VB.NET oder C Sharp nutzt wirst du um das .NET Framework nicht herumkommen.

ASFAIK gibts da was von Salamander. Nennt sich Salamander linker (o. ä.). Der soll laut beschreibung .NET Assemly's Nativ compilieren.

Ich denke aber nicht das das was wirklich brauchbares ist da das Programm dazu die ngen.exe nutzt und diese Nativ Abbilder von deiner Assembly erstellt.

MSIL to nativ

lg

Gateway

[ToolsDevler]

Hi Gateway_man,

des is keine schlechte Idee. Allerdings macht mich dieser Ausschnitt ein wenig stutzig:

As part of compiling MSIL to native code, code must pass a verification process unless an administrator has established a security policy that allows code to bypass verification. Verification examines MSIL and metadata to find out whether the code is type safe, which means that it only accesses the memory locations it is authorized to access. Type safety helps isolate objects from each other and therefore helps protect them from inadvertent or malicious corruption. It also provides assurance that security restrictions on code can be reliably enforced.

Ich mein...des Risiko hab ich ja dann auch, wenn ich mit C++ ne exe schreibe oder?...Was ich mir allerdings nich vorstellen kann, is, ab wann n Typ anfängt sich mit nem anderen Typ zu überschneiden... da fehlt mir noch des nötige Hintergrundwissen. Kann man da irwie präventiv vorgehen?

Was den Salamander .NET Linker betrifft:

habe dazu diesen Link gefunden Remotesoft Salamander .NET Linker and Mini-deployment Tool

(Interessante Beispiele gibts hier: Salamander Examples)

Gibt nur ein Problem:

Our linker and mini-deployment tool is available at $1249 for a single developer.

:eek

Werd mich selber auch nochma genauer umschaun, was die Kompilierung des MSIL-Codes betrifft.

Danke dir vielmals für deine Mühe!

Grüße

ToolsDevler

[Gateway_man]

Ich habe mich schon sehr lange mit dem Thema "MSIL Code in Nativ Code Compilieren" beschäftigt.

Jedoch aus einem anderen Grund....

Das Ergebnis meiner recherchen war mehr als ernüchternd.

Es gibt momentan noch keine Kostengünstige und vor allem zuverlässig funktionierende Möglichkeit dies umzusetzen.

Wenn es dich allerdings interessiert verweise ich gerne auf ein paar Seiten, welche den Prozess des "Native Compiling" aus technischer Sicht näher erläutern.

Der folgende Artikel ist meines erachtens nach sehr interessant:

.NET Native Compiling

Zum Thema "Type Safe Programming" kannst du dir folgendes mal ansehn. Ist jedoch bei weitem nicht so umfangreich.

What is it and how does it work.

[Bubble]

Das .NET Programme eine .NET Laufzeitumgebung benötigen ist gewollt. Wenn diese nicht vorhanden ist, kann sie, sofern für das verwendete OS verfügbar, installiert werden. Wo ist dabei das unüberwindbare Problem?

[Gateway_man]

Wer sagt denn das es ein Problem gibt.

Ich hatte mich aus dem Grund in dieser Richtung umgesehn, damit man den Code nicht mit 2 Klicks decompilieren kann. Das ist meines erachtens nach der Größte Nachteil am .NET.

Es macht es mir somit nicht wirklich möglich Wirtschaftliche Software zu schreiben. (Da heutzutage jeder(auch Konkurrenten) die Möglichkeit hat kostenlos an beispielsweise den .NET Reflector zu kommen und sich somit in aller Ruhe evtl. Verschlüsselungsalgorithmen oder das Know How, welches der Code preisgibt anzueignen/zu kopieren).

Früher galt noch der Spruch:

Reverse Engineering ist sehr Teuer und die wenigsten wollen/können sich das leisten.

Heutzutage bekommt man die Tools ja schon hinterhergeschmissen.

Aber ich habe mich damit abgefunden und hatte zu dem Zeitpunkt angefangen mir alternative Programmiersprachen anzueignen.

Natürlich nutze ich dennoch das Framework da es ich es ja nicht von Grund auf schlecht finde. Nur Sicherheitskritischen Anwendungen oder ähnliches schreibe ich in anderen Sprachen....

PS: Sry bei dem Thema werd ich immer n bisschen ... :beagolisc . (Schlechte Erfahrungen gesammelt...)

[ToolsDevler]

hmm... da ich sowie so gerade anfange C++ zu lernen, is desn guter anstoß, des gleich so zu lernen, dass ich ohne .NET Framework programmieren kann. Somit kann ich dann wenigstens relevante Module meines Programms mit ner anderen Sprache schreiben. Alternative wäre ja da noch die COM (oder?... hab mich damit noch nich außeinandergesetzt)...

aber dann lern ich lieber gleich C++

Großes Danke an Gateway_man!

Grüße

ToolsDevler

[Bubble]

Wer sagt denn das es ein Problem gibt.

Na die Ausgangsfrage klingt etwas danach, als ob dem Fregesteller dies nicht so richtig gefällt.

Ich hatte mich aus dem Grund in dieser Richtung umgesehn, damit man den Code nicht mit 2 Klicks decompilieren kann. Das ist meines erachtens nach der Größte Nachteil am .NET.

Das wird gelegentlich erwähnt, es sollte aber jedem klar sein, dass sich im Prinzip jede Software (auch ein "native" übersetztes Programm) mit genügend Aufwand nachvollziehen lässt. Wirklichen Schutz gibt es nur, wenn man das Programm erst gar nicht heraus gibt.

Mich würde aber dennoch interessieren, um was für Programmteile es sich handelt, die möglichst niemand nachvollziehen können soll.

[Guybrush Threepwood]

sich somit in aller Ruhe evtl. Verschlüsselungsalgorithmen oder das Know How, welches der Code preisgibt anzueignen/zu kopieren).

Verschlüsselungsverfahren sind nicht dadurch sicher das niemand weiß wie sie funktionieren sondern dadurch das nicht jeder den Schlüssel hat und wenn du den Schlüssel einfach so hardcodierst macht das keinen Unterschied ob .Net oder irgendeine andere x-beliebige SPrache verwendet wurde

Auch beim restlichen Code stellt sich die Frage ob der wirklich so großartig ist das man den nur dadurch nachbauen kann indem man sich den Quellcode anschaut und wenn das tatsächlich der Fall sein sollte macht es auch wieder keinen Unterschied welche Sprache verwendet wurde weil sich bei so genialem Quellcode/Algorithmen auch aufwändigere Reverse Engineering Verfahren lohnen würden.

[Gateway_man]

@Guybrush

Ja das mit dem Algorithmus war jetzt n schlechtes beispiel.

Das wird gelegentlich erwähnt, es sollte aber jedem klar sein, dass sich im Prinzip jede Software (auch ein "native" übersetztes Programm) mit genügend Aufwand nachvollziehen lässt.

Das ist mir durauch klar, jedoch gelingt das nicht innerhalt von 2 Minuten (und ohne know how, sprich nur klicken und man sieht den Code) sondern von Monaten und sehr viel Know How oder einer dicken Geldbörse.

Mich würde aber dennoch interessieren, um was für Programmteile es sich handelt, die möglichst niemand nachvollziehen können soll.

Diese Frage versteh ich beim besten Willen nicht?

Versetzt dich mal in die Lage von eines Geschäftsmannes oder einer Firma die damit Ihren Umsatz machen will.

Kleines Beispiel:

Nehmen wir mal an du wärst Entwicklungsleiter eines größeren Softwareunternehmens. So jetzt hast du vor ein Projekt aufzuziehen was vom Umfang her ca. ein Jahr dauert und sagen wir mal 200 000 Euro eingeplannt sind.

Würdest du wollen das eben dieses Projekt (welches deiner Firma ja Umsatz erbringen soll) "eigentlich Quelloffen" ist?

Okay du kannst natürlich in deinen Lizenzbedingungen reinschreiben:

Bitte Bitte lieber Käufer das ist kein OpenSource Projekt also komm nicht auf die Idee das zu decompilieren. Denn das ist Verboten.

Ob sich da jeder dran hällt ist eher zweifelhaft (Zumal es ja in diesem Fall so Kinderleicht ist). Denn nachzuweisen das jemand dein Programm decompiliert hat, ist so gut wie unmöglich.

Für Private Zwecke oder ähnliches, wo man selbst nur seine Zeit opfert und man nicht vom Erfolg/Erlös der Produkte abhängig ist und auch der Kostenaufwand dafür nicht so hoch ist (Da du ja in der Regel bei privat Projekten niemanden bezahlst).

So ich würde sage wir schweifen zu sehr vom eigentlichen Thema ab.

[Guybrush Threepwood]

Ja und was ist dann wenn es einer decompiliert hat?

EDIT: Im ersten Moment denkt wahrscheinlich jeder "Oh nein das geht ja gar nicht dann kann ja jeder mienen Code sehen". Ging mir genauso. Aber wenn man sich da weiter Gedanken drüber macht stellt man irgendwann fest das das gar nicht so ein Problem ist wie man anfangs meint.

Bearbeitet 19. August 2010 von Guybrush Threepwood

[Gateway_man]

Das dachte ich zu anfangs auch. Ich dachte es schaft eh keiner das lauffähig nachzustellen.

Doch als ich den Relector gesehn habe, hab ich diesen mal an den von mir verfassten E-Mail Client ausprobiert. Es war interessant.

Man fügte die exe hinzu und es wurden direkt alle benötigten dll und verweise nachgeladen.

Dann konnte man den 1zu1 decompilierten Code ansehn (selbst die variablennamen waren die gleichen). Der Reflector hat mir sogar angeboten alle zu exportieren also als files zu erstellen .....

Da war ich schon ein bisschen schockiert . Hatte versuch so mein Client lauffähig zu bekommen und das resultat. Es hatte funktioniert.

Ich fande das jetzt nicht so prickelnd. Da ich ca ein Jahr lang dran gearbeitet hatte und immer wieder mal dran arbeite. Okay mag sein das ich es eventuell nur geschafft hatte da ich den Code und die Zusammenhänge ja kenne. Hätte ich gewollt das man in den Code sehn kann hätte ich es Open Source gestellt .

Nuja

Lg

Gateway

Bearbeitet 19. August 2010 von Gateway_man

[Guybrush Threepwood]

Ich weiß wie der Reflector funktioniert

Nochmal die Frage: Welchen Nachteil hast du dadurch?

[ToolsDevler]

Ja gut, des mit dem decompilieren is bei mir durchaus ein Thema... ich erklär mal die Lage im klartext:

Mein Vater (ein purer Hardwareprogrammierer(-freak) der in erster Linie unter dem Z80 Forum als winelektronik zu finden ist) hat vor längerem (knapp 30 Jahre?^^) angefangen Hardware zusammen zu löten un später auch noch ICs zu programmieren. Im Laufe der Zeit hat er die so optimiert, dass er mittlerweile ein komplett eigenes System mit BIOS, Betriebssystem, Mutlitasking... usw. hat.

Als mein Vater sich mit der Firma Zilog in Verbindung gesetzt hat, kam einiges an Euphorie auf und es wurden sofort Hard- und Softwarekits zugeschickt und sogar Entwicklungsgeld zur Verfügung gestellt.

Meine Aufgabe war es, für das Betriebsystem (das mein Vater geschrieben hat) fürs erste ein Clientprogramm zu schreiben, womit man mit dem Teil von einem Windowsrechner übers Internet kommunizieren kann, was ich auch schon mit C# umgesetzt habe! Allerdings möchte Zilog unsere Entwicklungen mitverfolgen und ich möchte nich, dass bei einer Vorführung der Software (nich dass Zilog n Gaunerladen wäre... aber ich kenn die halt au ned!) ne Kopie unterm Ärmel verschwindet un die des Programm dann decompilieren!

Problem kommt hinzu, dass ich angefangen habe, Übertragungsprotokolle in Form von XML-Strukturen zu entwickeln, die natürlich später in der DLL keiner sehen sollte wie des zusammengesetzt wird (Die Übertragung selber wird natürlich verschlüsselt).

Hoffe, dass meine Situation jetz etwas klarer is

Grüße

ToolsDevler

[Gateway_man]

Ich weiß wie der Reflector funktioniert

Nochmal die Frage: Welchen Nachteil hast du dadurch?

Ganz einfach, es lässt sich relativ leicht herausfinden, wo die jeweiligen Logindaten stehen, wie diese verschlüsselt wurden, sowie das Passwort. Es ist demnach nicht gerade schwierig eine Routine zu schreiben, welche diese sensiblen Daten abgreift....

Du redest davon, als wäre es das normalste auf der Welt.

Nicht desto trotz will ich mein Geistiges Eigentum schützen wenn du versteht...

Zumal es wie oben schon erwähnt durchaus zu Sicherheitsrisiken führen kann.

[Guybrush Threepwood]

Zumal es wie oben schon erwähnt durchaus zu Sicherheitsrisiken führen kann.

Dann ist nicht die Tatsache das du es einfacher dekompilieren kannst das Sicherheitsrisiko sondern die das du eine absolut unsichere Anwendung geschrieben hast.

Ein Passwort kannst du aus jeder Anwendung ohne Probleme in wenigen Minuten ermitteln wenn das irgendwo einfach so im Code steht.

Wovor willst du dein geistiges Eigentum schützen? Das es niemals jemand zu Gesicht bekommt? Dann darfst du es nicht aus der Hand geben...

PS: Nimms mir nicht übel weil das ist nicht böse gemeint aber ich glaube deine Befürchtungen bezüglich der dekompilierbarkeit von .Net Anwendungen kommen hauptsächlich dadurch das du nicht weißt was man mit "normalen" Anwendungen alles machen kann.

[Gateway_man]

Ich nehm dir nichts übel . Allerdings versteh ich deine Argumentation nicht.

Dann ist nicht die Tatsache das du es einfacher dekompilieren kannst das Sicherheitsrisiko sondern die das du eine absolut unsichere Anwendung geschrieben hast.

Ein Passwort kannst du aus jeder Anwendung ohne Probleme in wenigen Minuten ermitteln wenn das irgendwo einfach so im Code steht.

Prinzipiell kommen keine Passwörter direkt in den Code.

Aber ich weiß nicht ob du folgenden (relativ simpler Algorithmus) kennst:

Caesar-Verschlüsselung

Dieser wird benutzt und ich muss wohl kaum sagen, das wenn man in den Code sehen kann und sieht, das es sich hierbei um eben diesen Algorithmus handelt man eigentlich leichtes Spiel hat.

Jetzt kommt der Knackpunkt. Er bleibt Sicher, solange niemand weiß das dieser eingesetzt wird. Du versteht mein Dilema?! Denn solange niemand weiß, welcher Algorithmus eingesetzt wurde, muss ich mir auch keien Sorgen um die Daten machen.

Eigentlich hatte ich mich schon längst damit abgefunden, dass das Decompilieren von .NET Assembly's so einfach geht.

Schließen wir das Thema einfach ab und ich geb dir einfach recht

[Klotzkopp]

Er bleibt Sicher, solange niemand weiß das dieser eingesetzt wird.

Das darf angezweifelt werden:

Security through obscurity ? Wikipedia

[Gateway_man]

Das darf angezweifelt werden:

Security through obscurity ? Wikipedia

Ja ich gesteh ein, nicht die beste Sicht.

Aber ich kann es Drehen und Wenden.

Lege ich zum Beispiel die Daten verschlüsselt in ner Config Datei oder in einer XML, muss dieses Passwort ja auch wieder vermerkt werden. Und durch decompiling ist es möglich zu sehen wo und wie dieses vermerkt ist.

Und wenn wieder dieses verschlüssle brauch ich ja wieder einen key um es wieder zu entschlüsseln und muss dieses ja auch wieder irgendwo ablegen und das muss ich auch wieder per Code machen, in welchen man ja auch wieder einsehen kann.

Meines erachtens ein Teufelskreis.

Und auch wenn der User selbst das Passwort zur verschlüsselung bestimmt, muss ich dieses wieder irgendwo vermerken um es später wieder vergleichen zu können. Und das ist auch durch Codeeinsicht nachvollziehbar.

Nungut es gibt natürlich auch alternativen. Beispielsweise eine Fixe erste Zeile an die Verschlüsselte Datei zu hengen, welche bei der Entschlüsselung verglichen werden kann. Aber alles in allem ist das nachvollziehbar und umgehbar.

Ich bin offen für Alternativ vorschläge. :old

[Bubble]

Das ist mir durauch klar, jedoch gelingt das nicht innerhalt von 2 Minuten (und ohne know how, sprich nur klicken und man sieht den Code) sondern von Monaten und sehr viel Know How oder einer dicken Geldbörse.

Und wo ist das Problem, wenn jemand einen äquivalenten Source sieht, wenn er denn unbedingt will? Wenn man diesen in den 2 Minuten auch noch versteht, wird vermutlich eher nichts besonderes passieren.

Diese Frage versteh ich beim besten Willen nicht?

Ich will einschätzen können, ob es sich um das Schützen wollen wirklich cleverer Ideen handelt, oder eher das Gegenteil.

Doch als ich den Relector gesehn habe, hab ich diesen mal an den von mir verfassten E-Mail Client ausprobiert. Es war interessant.

Und was macht der E-Mail Client so besonderes, dass das Know-How der Implementierung bestmöglich geschützt sein muss?

Ich fande das jetzt nicht so prickelnd. Da ich ca ein Jahr lang dran gearbeitet hatte und immer wieder mal dran arbeite.

Hier liegt vielleicht eines der eigentlichen Probleme: Zeitaufwand für eine Implementierung ist für sich alleine nicht vergleichbar mit wirklich cleveren Alleinstellungsmerkmalen oder auch sonstigen in die Implementierung geflossenen Ideen, die vielleicht einen gewissen Vorsprung vor ähnlichen Programmen darstellen können.

Ich glaube es gibt primär zwei Gründe, ein Programm möglichst gut schützen zu wollen: Wirklich clevere Ideen (vermutlich eher selten) und das genaue Gegenteil: Die Benutzer (Kunden) sollen nicht mitbekommen, wie furchtbar die Umsetzung ist.

Ganz einfach, es lässt sich relativ leicht herausfinden, wo die jeweiligen Logindaten stehen, wie diese verschlüsselt wurden, sowie das Passwort.

Erstmal ist es eine seht schlechte Idee vertrauliche Logindaten in ein Programm hineinzucompilieren, egal ob verschlüsselt oder nicht. Und dann stellt sich auch gleich eine weitere Design-Frage: Warum benötigt das Programm ein Passwort, dass der Benutzer nicht kennen darf?

Jetzt kommt der Knackpunkt. Er bleibt Sicher, solange niemand weiß das dieser eingesetzt wird. Du versteht mein Dilema?! Denn solange niemand weiß, welcher Algorithmus eingesetzt wurde, muss ich mir auch keien Sorgen um die Daten machen.

Das ist kompletter Unsinn. Sobald das Passwort entschlüsselt ist, kann es, wenn keine besonderen weiteren Schutzmaßnahmen vorhanden sind, im Klartext abgegriffen werden.

[Gateway_man]

Ich will einschätzen können, ob es sich um das Schützen wollen wirklich cleverer Ideen handelt, oder eher das Gegenteil.

Ich habe schon eingesehn das das MSIL to Nativ Compiling Sinnfrei ist. Allein der Aufwand ist es bei weitem nicht Wert.

Und was macht der E-Mail Client so besonderes, dass das Know-How der Implementierung bestmöglich geschützt sein muss?

Es geht in diesem Fall nichtmal sosehr ums Know How vielmehr das derjenige

sehr viel Schweiß und Arbeit da reingesteckt hat (zumal das nur ein Modul des Ganzen ist).

Ich glaube es gibt primär zwei Gründe, ein Programm möglichst gut schützen zu wollen: Wirklich clevere Ideen (vermutlich eher selten) und das genaue Gegenteil: Die Benutzer (Kunden) sollen nicht mitbekommen, wie furchtbar die Umsetzung ist.

Du scheinst da was nicht verstanden zu haben. Um das Programm zu nutzen muss man nicht zwangsläufig den Code kennen. Zumal werden wohl eher die wenigstens User eines Programmes das Programm nach dem Code (Zumal diese meist nicht die möglichkeiten dazu haben) bewerten sondern nach der Userbillity etc.

Erstmal ist es eine seht schlechte Idee vertrauliche Logindaten in ein Programm hineinzucompilieren, egal ob verschlüsselt oder nicht. Und dann stellt sich auch gleich eine weitere Design-Frage: Warum benötigt das Programm ein Passwort, dass der Benutzer nicht kennen darf?

Wie ich bereits gesagt hatte ich das nicht der Fall. Das Programm ist ein Multi-User System, sprich mehrere User sind möglich. Diese Angelegten User können Ihren Account wahlweise mit Passwort schützen, welches verschlüsselt in die XML des jeweiligen Profils abgelegt wird. Sie kenne das Passwort in der Regel das Sie angelegt haben.

Mir geht es vielmehr darum, das die die es nicht kennen es auch nicht erfahren....

Das ist kompletter Unsinn. Sobald das Passwort entschlüsselt ist, kann es, wenn keine besonderen weiteren Schutzmaßnahmen vorhanden sind, im Klartext abgegriffen werden.

Das Passwort wird ja nach dem Entschlüsseln nicht in ein File abgelegt sonder existiert nur in einer Stringvariable eines Moduls zum vergleich der Eingabe des Users.

[Klotzkopp]

Das Passwort wird ja nach dem Entschlüsseln nicht in ein File abgelegt sonder existiert nur in einer Stringvariable eines Moduls zum vergleich der Eingabe des Users.

Wer irgendwelche Sicherheitsprüfungen in deinem Programm aushebeln will, wird dafür vermutlich nicht zu einem Decompiler greifen, sondern eher zu einem Debugger. Er kann dann die Prüfungsfunktion einfach überspringen, oder so lange Schritt für Schritt durchs Programm gehen, bis das Passwort im Klartext im Speicher steht.

Darum macht man das auch nicht so. Man legt Passwörter niemals irgendwo ab, weder unverschlüsselt noch verschlüsselt. Passwörter werden durch eine kryptologische Hashfunktion gejagt und das Ergebnis abgelegt. Einen Hash kann man nicht (oder nur mit sehr sehr großem Aufwand) zurückrechnen.

Andererseits ist die Passwortprüfung einfach: Du schickst die Benutzereingabe durch dieselbe Hashfunktion. Wenn dabei der richtige Hash herauskommt, kannst du davon ausgehen, dass das Passwort richtig ist.

Kryptologische Hashfunktion ? Wikipedia

Das Problem, dass die gesamte Passwortprüfung mit einem Debugger übersprungen werden kann, hast du aber immer noch.

[Gateway_man]

Hashfunktionen sind ja schön und gut, sind aber dann fehl am Platz, wenn ich den ursprünglichen String benötige.

Beispielsweise müssen die Anmeldedaten für den POP3 oder IMAP sowie die vom SMTP Server hinterlegt werden. Logischerweise kann ich diese nicht Hashen sonst wird es bei der Anmeldung mehrere Probleme geben.