[Waq]

Zitat von Bookworm

Ich meine, sicherheitsbewusste Menschen benutzen bei jeder Anwendung ein anderes Kennwort, da nützt einem ein einzelnes doch überhaupt nichts...

Alles ist gut. Niemand liest Spam. Keiner klickt auf Links in E-Mails. Und niemand benutzt ein Passwort zweimal.

Träumen muss natürlich erlaubt sein, aber rumschlagen müssen wir uns trotzdem mit der Realität, und da ist es ein Gebot der Höflichkeit, dass auch ich als Betreiber das Passwort des Benutzers nicht kenne, aus offensichtlichen Gründen.

[Bookworm]

Alles ist gut. Niemand liest Spam. Keiner klickt auf Links in E-Mails. Und niemand benutzt ein Passwort zweimal.

Ja^^ schon klar... Das wusste ich auch so, aber die Tatsache, dass es eh schon zu spät ist wenn der Hacker in der DB ist kannst du nicht abstreiten...

und da ist es ein Gebot der Höflichkeit, dass auch ich als Betreiber das Passwort des Benutzers nicht kenne, aus offensichtlichen Gründen.

Das hat rein moralische Gründe . Wobei ich mich mittlerweile auch dazu entschlossen habe, meinem Team die Passwörter zu verrrschlüsseln, damit nur sie sie kennen....

[Lars]

dass es eh schon zu spät ist wenn der Hacker in der DB ist

Wie sieht es mit SQL-Injections aus? Es gibt genug "Anwendungen", bei denen man durch eine SQL-Injection beliebige Passwörter auslesen kann. Im phpBB hab ich das schon ein paar mal gemacht, zum Glück waren die Passwörter gehasht.

[WarrenFaith]

Ich meine, wenns ein Hacker soweit schafft, da nützt auch eine Verschlüsselung nichts mehr...

Wenn ein Hacker aber nur Daten aus der DB auslesen kann, dann hätte er mit Klartext alles, auch dein Passwort! So hat er erstmal nur nen Hash mit dem er nix anfangen kann. Ziel von Sicherheit ist doch nicht nur eine Barriere aufzubauen und zu sagen "da muss er erstmal durch", sondern eher viele Sicherheitsschichten zu bauen, damit er beim Hack der einen, vor dem nächsten Problem steht.

Ich meine, sicherheitsbewusste Menschen benutzen bei jeder Anwendung ein anderes Kennwort, da nützt einem ein einzelnes doch überhaupt nichts...

Jo als Anbieter kannst du aber nicht feststellen, ob der User sich ein anderes PW ausgesucht hat als er normalerweise nutzt. Außerdem macht das kaum einer.

Entschuldigt mich, wenn das nicht stimmt, aber das war der Ergebnis von einer ICQ Sitzung mit nem anderen, etwas erfahreren (als ich ) PHP-Coder...

Hau ihn!

BTT:

Es handelt sich dabei um den SHA-256, SHA-384 und SHA-512 wobei die angefügte Zahl jeweils die Länge des Hashwerts (in Bit) angibt

Quelle: http://de.wikipedia.org/wiki/SHA-1
Je länger der Hash desto weniger Kollisionen gibt es, denke ich. Daher wäre SHA-512 das sicherste, aber obs notwendig ist, ist eine andere Frage

[Bookworm]

Es gibt genug "Anwendungen", bei denen man durch eine SQL-Injection beliebige Passwörter auslesen kann. Im phpBB hab ich das schon ein paar mal gemacht, zum Glück waren die Passwörter gehasht.

Hm-hm nur weiß ich nicht wie das geht.... Ich weiß ja nichtmal wie ich ne SQL Injection auf nen Server loslass der nich mir gehört... ^^

edit:

Wenn ein Hacker aber nur Daten aus der DB auslesen kann, dann hätte er mit Klartext alles, auch dein Passwort! So hat er erstmal nur nen Hash mit dem er nix anfangen kann.

Jaha toll^^ Wie bereits gesagt dann ändert er den Hash und fertig... Ich mein was für ein Interesse hat ein Ottonormalhacker an 1000 Forenutzer-Passworten? Die richtig interessanten Daten sind doch eh anders geschützt... AH lasst mich raten: es geht ums Prinzip und den Prollfaktor als Coder?

edit2; tut mir leid wenn ich ein bissel aggressiv und dumm argumentier, aber ich hab hier so ne krise, wem soll ich eher glauben, euch oder ihm?

[Lars]

Du vielleicht nicht. Aber glaub mir, es gibt genug "bösartige" (ich unterstelle das einfach mal ) Menschen, die dabei noch Ahnung haben.

[WarrenFaith]

SQL Injections laufen über normale Eingabeformulare wie Loginformulare...
Nachzulesen was das ist geht via Google!
Sollte man kennen...

[Chr!s]

Jaha toll^^ Wie bereits gesagt dann ändert er den Hash und fertig... Ich mein was für ein Interesse hat ein Ottonormalhacker an 1000 Forenutzer-Passworten? Die richtig interessanten Daten sind doch eh anders geschützt... AH lasst mich raten: es geht ums Prinzip und den Prollfaktor als Coder?

Unter der Annahme, dass der Hacker bisher nur an die DB gekommen ist, nützt ihm auch das Verändern des Hashes nicht.

Warum? Ganz einfach.
Er kennt deinen Hashalgorhitmus (z.B. mit Salt) nicht.

[pago]

Wie bereits gesagt dann ändert er den Hash und fertig...

Read-only war wohl gemeint...

Ich mein was für ein Interesse hat ein Ottonormalhacker an 1000 Forenutzer-Passworten?

Daraus baut der sich ne nette Liste, die er dann per Script in anderen Foren testen kann. Vielleicht hat er ja Glück und es ergeben sich Übereinstimmungen. Oder er logt sich als Administrator ein - vorher konnte er ja nur die Passwörter auslesen, nachdem er die aber hat kann er damit auch rumspielen, gell?

Sollte man kennen...

Muss man kennen...

[Waq]

Zitat von Bookworm

AH lasst mich raten: es geht ums Prinzip und den Prollfaktor als Coder?

Erstens können 1000 Passwörter nützlicher sein als man denkt.
Zweitens sollte man, wenn man die Interessen anderer (der Passwort-Ausdenker) derart holzköpfig missachtet, nur noch für den eigenen Keller programmieren und nie wieder jemand anders mit seiner Software belästigen.

Gibt halt Leute, die halten Datenschutz für überflüssig, ausser es geht um ihre eigenen Daten. (Passwörter fallen AFAIK nicht unter den Datenschutz, aber trotzdem)

PS: "Prollfaktor"? DAS SCHREIBEN SICHERER SOFTWARE IST PFLICHT UND KEIN VERFICKTER SCHWANZLÄNGENVERGLEICH!

[WarrenFaith]

Bookworm, du hast hier in ein Bienennest gestochen und Blasphemie betrieben.
Du solltest dringend dein Wissen über Sicherheitsthemen kräftig ausbauen und nachlesen.

[Bookworm]

lol ja aber der Ton hier...^^

[sarc]

So, dann will ich mich auch mal mit einklinken. Ich bin der von Bookworm angesprochene

andere, etwas erfahrere (als ich ) PHP-Coder...

auch wenn mir zumindest das zweite Attribut wies aussieht erst mal wieder aberkannt wird...

Gleich mal vorneweg: Dies ist genau genommen eine relativ hypothetische Diskussion auf Basis einiger Gedankengänge, die ich mir mal gemacht hab. Meine eigenen Passwörter sind gehasht, allerdings vor allem aus den bereits angesprochenen moralischen Gründen: Ich will nicht in die Verlegenheit kommen, die Passwörter anderer Leute zu kennen.

Allerdings bin ich immer noch auf der Suche nach wirklich stichhaltigen Argumenten, warum eine Verschlüsselung oder ein Hashing von Passwörtern wirklich sinnvoll sein soll. Auf die, die hier genannt wurden, geh ich später noch ein.

Aber erst mal folgendes: Wenn mans auf die Spitze treibt, könnte man sogar argumentieren, dass solche Sachen "gefährlich" sind. Denn sie gaukeln dem Benutzer eine Sicherheit vor, die nicht wirklich existiert.
Wenn ich also Otto-normal-Nutzer davon höre, dass die Passwörter "verschlüsselt" gespeichert werden, dann gehe ich natürlich davon aus, dass das auch sicher ist. Also insbesondere, dass niemand, auch nicht der Betreiber, meine Passwörter lesen kann. Zumindest für den Betreiber gilt das jedoch nicht: Ich muss dem einmal glauben, dass er die wirklich verschlüsselt. Daneben muss ich ihm auch glauben, dass er die Passwörter, die im Klartext bei ihm ankommen, nicht irgendwie mitschneidet. Genauso gut kann ich ihm doch auch glauben, dass er Passwörter, die im Klartext in der Datenbank stehen, nicht liest, oder?
Auf der anderen Seite glaube ich dann natürlich auch, dass kein Hacker an meine Passwörter rankommen wird - denn sie sind ja verschlüsselt. Also wähne ich meine Passwörter absolut sicher. Und weil die eh niemand jemals kennen kann kann ich doch auch für jede Seite das gleiche Passwort verwenden, richtig?
Wenn man wüsste, dass die Passwörter im Klartext gespeichert werden, sähe dieser Gedankengang vielleicht ganz anders aus... Inbesondere wirklich wichtige Passwörter wären dann definitiv Einzelstücke.
Ich gebe zu, dies alles klingt ziemlich an den Haaren herbeigezogen. Ist es vermutlich auch... Aber darüber nachdenken kann man trotzdem mal...


Nun aber zu den Argumenten für Verschlüsselung / Hashing:

Zitat von Lars

Wie sieht es mit SQL-Injections aus? Es gibt genug "Anwendungen", bei denen man durch eine SQL-Injection beliebige Passwörter auslesen kann. Im phpBB hab ich das schon ein paar mal gemacht, zum Glück waren die Passwörter gehasht.

Eine Anwendung, die SQL-Injections zulässt, ist, wie du schon gesagt hast, höchstens eine "Anwendung". Und es ist wirklich erschreckend, bei wie vielen professionell vertriebenen Scripten diese immer noch möglich sind.
Allerdings, wenn es einmal so weit gekommen ist, dann brauche ich die Passwörter doch gar nicht mehr im Klartext zu kennen. Oder kann mir einer ein Szenario nennen, bei dem es über eine SQL-Injektion möglich ist, die Passwörter auszulesen, gleichzeitig aber kein Schreibzugriff auf die Datenbank möglich sein soll? Mir fallen nur sehr wenige Anwendungen ein, die nur lesend auf ne Datenbank zugreifen müssen, und die verwenden mit ziemlicher Sicherheit keine Passwörter. Bei allem anderen sollte sich auch irgendwie ein UPDATE mit reinmogeln lassen...
Damit kann man dann tun und lassen, was man will. Und ob das jetzt sofort geht, weil man das Passwort direkt in der Hand hat, oder einen kleinen Umweg bedarf spielt dann eigentlich keine Rolle mehr, die Kacke is dann auf jeden Fall am Dampfen...

Und selbst wenn man das Passwort wirklich im Klartext kennen will: Auch das ist dann doch möglich, solange der Algorithmus, der sich um die Passwörter kümmert, nicht wirklich verdammt gut ist.
Viele Scripte sind frei verfügbar, da scheiden Späße wie doppeltes Hashen schon mal aus. So was wirkt nur, wenn man nix davon weiß...
Salt... Is ne schöne Sache, machts auf jeden Fall komplizierter. Wenn man jedoch die Passwörter alle auslesen kann... Nun, was hindert mich daran, mich in dem System zu registrieren und zu gucken, was aus meinem gewählten Passwort wird? So lang der Salt nur die Länge eines durchschnittlichen Passworts hat, dauert es selbst per Brute Force nicht so lang, auf den Salt zurückzuschließen.

Daraus baut der sich ne nette Liste, die er dann per Script in anderen Foren testen kann. Vielleicht hat er ja Glück und es ergeben sich Übereinstimmungen.

Das ist etwas, bei dem es sich in der Tat lohnen würde, die Passwörter zu verschleiern. Wobei wie gesagt, wenn der Algorithmus nicht wirklich gut ist, ist auch das keine Hürde, wenn mans wirklich drauf anlegt.
Wobei sich auch hier die Frage stellt, was nützen mir die Zugangsinformationen zu irgendwelchen unbedeutenden Forenaccounts? Ok, vielleicht sind ein paar bedeutende dabei, aber da bin ich der Meinung, wer überall das gleiche Passwort verwendet, ist selber Schuld. Und würde es vielleicht nicht tun, wenn er wüsste, dass die Passwörter im Klartext gespeichert werden. Aber lassen wir das...

Zitat von Waq

DAS SCHREIBEN SICHERER SOFTWARE IST PFLICHT

Hier stimme ich dir absolut zu! Allerdings jetzt die provokante Frage: Wie ist eine SQL-Injection, mit der ich sämtliche Passwörter auslesen kann, mit sicherer Software vereinbar? Wenn so etwas möglich ist, dann brennts, und zwar gewaltig! Jeder, der mehr mit PHP und Datenbanken macht, sollte schon einmal von diesem Problem gehört haben und wissen, wie er seine Formulare (und per URL übergebene Parameter...) entsprechend behandeln muss. Jeder, der dies nicht beachtet, programmiert vermutlich eh nur für den Hausgebrauch und wäre darüber hinaus nicht auf die Idee gekommen, mehr als md5() auf seine Passwörter anzuwenden. Was die Sache nicht wirklich wesentlich verkompliziert...
Worauf ich hinaus will: Wirklich sichere Software lässt keine Lücke, über die man an die Passwörter rankommt. Entsprechend sollte es auch nicht notwendig sein, diese zu verschlüsseln. Natürlich ist 100%ige Sicherheit Wunschdenken...

Und noch ein letzter Gedanke: Die größte Gefahr liegt mMn auch nicht unbedingt in der Datenbank, sondern eher in der Art, wie die Passwörter nach der Eingabe behandelt werden. Zum Server werden sie im Klartext übertragen, entsprechend lassen sie sich da (das notwendige Know-How vorausgesetzt) auch auslesen. Oder die unsäglichen Cookies, die die Zugangsinformationen speichern... Könnte man wohl auch böse Sachen mit anstellen, wenn mans drauf anlegt...



Das waren so ein paar meiner Gedanken zu diesem Thema. Und jetzt die Frage: Wo genau liegt der gewaltige Sicherheitsgewinn, wenn ich zig verschachtelte Hashing- und Verschlüsselungsalgorithmen über meine Passwörter laufen lasse? Von den moralischen Gründen mal abgesehen... (Und abgesehen von der Tatsache, dass sich der Prozessor über solche Sachen immer freut und bei wirklich vielen Benutzern elends langsam wird... Ein System, das nicht reagiert, kann man natürlich auch nicht angreifen... )
Ich hoffe einfach mal auf eine schöne, sachliche Diskussion zu diesem Thema. Sprich ohne ein "du hast doch keine Ahnung, wovon du redest" und "es ist sicherer so. Punkt."

[pago]

Wenn SQL-Injections möglich sind, dann ist das ein Bug in der Software. Das ist ne Sache, die passieren kann - sollte sie natürlich nicht. Wenn die Passwörter verschlüsselt sind, dann wird die Gefahr zumindest verringert - sozusagen als extra Fangnetz.

Warum es besonders aufwendig sein soll, einen Salt mit einzubinden, weiß ich leider auch nicht. Den brauche ich pro Installation einmal zu generieren. Ob der Benutzer das Dingen selbst aussucht, oder ob ich nen Timestamp nehme oder den nochmal per md5 verschlüssel (damit ich nicht nur zahlen habe und das ganze länger ist), ist dabei egal.

Was du außerdem nicht vergessen darfst: Wenn man so vorgeht, wie du es vorgeschlagen hast, dann musst du zweimal eine Brute-Force Attacke ausführen. Einmal, um den Salt zu finden, und einmal, um das tatsächliche Passwort zu bestimmen.


Davon abgesehen bezweifle ich, dass ich jedesmal ein neues Passwort benutzen würde, wenn ich nicht wüsste, ob es geheim bleibt. Diese Gewissheit habe ich auch jetzt nicht. Wenn ich dem Anbieter nicht vertraue (d.h. einen Grund habe, ihm zu misstrauen) nehme ich üblicherweise tatsächlich ein anderes Passwort, aber dazu muss ich eben erst einen Grund haben. Ich für meinen Teil kann mir einfach keine 2000 Passwörter merken. Geht einfach nicht und ich gehe sehr stark davon aus, dass andere damit noch größere Probleme haben würden. Ich hab irgendwie 5 oder 6 verschiedene Passwörter, die ich verwende. Und eben das ist das tolle: Ich weiß es nicht mehr! Ich muss jedesmal raten, welches Passwort ich denn nun für diese Seite, dieses Programml, angegeben habe. Ziemlich blöd.

So, jetzt nochmal zum Thema SQL-Injections: Wie gesagt sind das Bugs. d.h. nur weil ein SELECT-Query angreifbar ist, muss das nicht auch für die INSERT/UPDATE/DELETE-Queries gelten. Insofern ist es tatsächlich eine gewisse Extra-Sicherheit, die hier geboten wird.

Eines sollte dir klar sein: Es ist unmöglich, ein 100% sicheres Programm zu schreiben, wenn es um Datenverarbeitung geht. Selbst wenn du alle möglichen technischen Dinge abdeckst, gibt es immer noch den Faktor "Mensch". Alles, was du tun kannst, ist, es einem möglichen Einbrecher so schwer wie möglich zu machen. Und das geht eben dadurch, dass du soviele Barrieren wie möglich aufbaust. Selbst wenn er durch die ersten 5 durchkommt, vielleicht gibt er bei der sechsten auf.

Um über Cookies dran zu kommen müsstest du vorher aber erstmal nen XSS-Bug enttarnen.

So... ich muss zugeben, ein paar Teile deines Beitrages überflogen zu haben. Also ist nur ein kurzer Kommentar.

[Homepagespeicher]

Zu meiner Schande muss ich gestehen, dass ich mich erst seit kurzem intensiver mit Sicherheitsfunktionen von PHP beschäftige.

Das hab ich gemerkt als Du in dem anderen Thread (ich glaub es war: Ingo Wolf wird zerhackt), meintest es käme niemand an meine Passwörter wenn er den php code kenne er wisse nur das Du SH1 oder so am hashen bist.
Aber es wurde bereits festgestlellt: verschlüsseln !=zerhashen
(...wegen ich würd Themen nicht vergfolgen: hab halt nicht immer direkt Zeit meinen Senf dazu zu geben)

Deshalb wäre hier ein Beispiel bei dem verbergen sicherer (nicht sicher!) ist:
Durch den Hash kann nicht auf das Passwort geschlossen werden, wenn aber jemand den Code kennt ist eine Verschlüsselung aber geknackt.
(Das mal als Erklärung für WarrenFaith, wenn auch verspätet)

PS: "Prollfaktor"? DAS SCHREIBEN SICHERER SOFTWARE IST PFLICHT UND KEIN VERFICKTER SCHWANZLÄNGENVERGLEICH!

Da hat WarrenFaith aber recht.
(Klingt politisch, ist aber sachlich korrekt)

Wo also der "erfahrere" grad ne Geschichte am schreiben ist will ich auch mal nicht nachstehen.
Hab grad so nen Fall:
- Ein Kunde möchte das nur angemeldete Gäste Bilder einer Singlebörse betrachten können

Kein Problem also, ich muß nur einfügen:
Userverwaltung, Login, Rechtesystem
Immer noch kein Problem, für das angepeilte Budget für mich gerne machbar.
ABER:
- Die Passwörter des vorliegenden Scripts sind im Klartext gespeichert, es ist kein Schutz gegen MySQL Injektion vorhanden.
- Das Script soll von Kunden mit mehreren tausend Benutzern zum Einsatz kommen
(Das das Script nicht modern ist, noch was ganz anderes)


Ich habe das der Kundschaft erstmal so geschildert.
(Dabei besteht immer die Gefahr vom Kunden mißverstanden zu werden:
Klar kann ich die gewünschten Funktionen eben mal einfügen für den veranschlagten Preis, ich kann aber so keine "saubere Arbeit" abliefern und erfahrungsgemäß denkt der Kunde: "Jetzt will er mir Folgeaufträge abschwatzen bevor überhaupt das scheiß Login funktioniert."
Ich hab schon Depressionen deswegen gehabt.
Es ist so einfach so:
- Entweder zahlt der Kunde mahr als hundert euro, oder
aber er bekommt Schrott.
Das ist sogar bei mir so.
Das ist sogar bei Nutten so.
Oder Du bekommst einen gefälschten Aidstest aus Afrika vorgezeigt.

Es ist oft schwer zu vermitteln das dabei das Kundeninteresse vertreten werden soll.
(Eine Programmierergewerkschaft in Deutschland hat den Betastatus noch nichtmal erreicht...)
Trotzdem muß man dem Kunden sagen das Softwaresicherheit ein Thema für ihn sein sollte.
Nicht nur bei Webanwendungen - es gibt Studien die davon ausgehen das ca. 90% ALLER (privater/kommerzieller...) PCs mit Spionagesoftware verseucht sind.
Es ist furchtbar:
Fast immer wenn ich jemanden auf die Sicherheitschwachstellen in seinem System hinweise, fühlt der Betroffene sich persönlich angegriffen.
Aber es ist klar:
Es werden immer die Kosten mit dem Nutzen relativiert - viele denken dabei zu kurzfristig.

Und jetzt die Frage: Wo genau liegt der gewaltige Sicherheitsgewinn, wenn ich zig verschachtelte Hashing- und Verschlüsselungsalgorithmen über meine Passwörter laufen lasse? Von den moralischen Gründen mal abgesehen... (Und abgesehen von der Tatsache, dass sich der Prozessor über solche Sachen immer freut und bei wirklich vielen Benutzern elends langsam wird... Ein System, das nicht reagiert, kann man natürlich auch nicht angreifen... )
Ich hoffe einfach mal auf eine schöne, sachliche Diskussion zu diesem Thema. Sprich ohne ein "du hast doch keine Ahnung, wovon du redest" und "es ist sicherer so. Punkt."

Wenn Du Programmierer bist, wozu schreibst Du dann solche Geschichten?
Es ist sicherer so. Punkt.

mfg
Till

- md5 kiffen und Gehirne zerhacken, davon wir der Ben schlau.

Ein System, das nicht reagiert, kann man natürlich auch nicht angreifen

Siehst Du doch warum hier keiner reagiert.

mfg
Till

EDIT: - Sehr schade, das wär für mich aber ein Thema mit dem Titel "Softwareethik" gewesen.
Bald hab ich keine Lust mehr hier.
Vorletzte Warnung.

[Waq]

Zitat von sarc

Allerdings, wenn es einmal so weit gekommen ist, dann brauche ich die Passwörter doch gar nicht mehr im Klartext zu kennen.

Sicherheit sollte nach Möglichkeit mehrschichtig sein, sonst baut man nen "single point of failure" ein. Wobei ich hier von der Sicherheit der Passwörter als persönlichem Datum rede, nicht von der gehackten Applikation.
Es muss nicht immer die SQL-Injection sein.

Zitat von Homepagespeicher

- Entweder zahlt der Kunde mahr als hundert euro, oder
aber er bekommt Schrott.
Das ist sogar bei mir so.
Das ist sogar bei Nutten so.

Wie, für 100 Euro gibts keine ordentlichen Nutten mehr? Man ist das teuer geworden...

[..] Es ist sicherer so. Punkt.

Bedingt. Das ist sicherheitstechnisch mehr ein Schritt vor und einer zurück. Würd ich persönlich drauf verzichten. Hatten wir schonmal im Thread hier.

[Jojo]

Ähm..... Der Thread hat zwar schon nen Bart aber ich hab mal nen Vorschlag:
Wir wollen ja den Usern und Gästen hier was bieten.
Und ich denke man kann auch ohne Kristallkugel sagen dass die meisten (PHP-)Programmierer sich in Sachen Passwortverschlüsselung/-hashing auf ziemlich dünnem Eis gegeben.
Das mag daran liegen, dass die Programmierer die nötigen Funktionen nicht kennen oder dass sie sich unsicher über deren Anwendung sind.
Daher mein Vorschlag:
Wollte einer, der sich damit ausgekennt (ich denke, die gibt es hier in diesem Forum) und sich dafür interessiert nicht ein Tutorial über die Verschlüsselung (von Passwörtern) [in PHP] schreiben, dass Unbedarfte an das Thema heranführt?
Das wäre vllt. nicht schlecht und Waq und andere müsste vielleicht nicht immer die gleichen Schlachten schlagen?

Jojo

[Mirod]

Fände ich nen sehr guten Vorschlag, da man nach dem Lesen dieses Thrads hier einfach verwirrt ist.

[Bookworm]

ICh würde der Sache aus zustimmen. Zumal ich einfach keienn BOck hatte, dauernd die BEgriffe nach zu manualen^^

[Lars]

Dazu: http://forum.developers-guide.net/showthread.php?t=4309