Hallo @all,

könnte mich mal bitte jemand aufklären wie das Mycrypt Modul eingebaut werden kann in PHP?

- mit regsvr32 ???
- Ziel-Directory???

gesaugt hab ich es schon, nur weiss ich nicht genau was Sache ist damit.

Ich muss jetzt leider auf Mycrypt zurückgreifen, da die gepostete Verschlüsselung im anderen Thread für meine kleinen Action Wörtchen zu klein und zu einfach verschlüsselt wird so dass jeder das ohne Prob leicht rausfinden kann.

Brauche mal einen schlauen Kopf eben, wie das implementiert wird

Danke schon mal

*VERSCHIEB* :D

Wir haben hier verschiedene Foren, bitte sortiere deine Beiträge demnächst in die entsprechenden Foren ein.:

ach das gehört hier her, wusste nicht recht wo es hinkommt.

bin neu hier, sorry

Kein Problem. Dafür bin ich ja da.

Gibts zu dem Mycrypt denn keine Anleitung?

Hey,

ne ich hab das Teil runtergeladen, als ich dann in die *.zip File reingeschaut habe, konnte ich nur Unmengen von *.dll Files entdecken aber eine Anleitung fehlte.

Weisst du das, wie das geht???

das hilft uns nicht

wo haste es den runtergeladen???

Im Forum wurde ich mal auf einen Thread verwiesen, dort war ein downloadlink welcher auf einen FTP-Server verwies.

Mehr weiss ich leider auch nicht mehr.

Es wird doch einen hier geben der weiss wie das Plug-In installiert werden soll oder nicht?

Wie binde ich das Plug-In ein mit den ganzen *.dll????

eine Antwort wäre nicht schlecht

Du musst Dir mcrypt selber compilieren.
http://mcrypt.hellug.gr/
Unter Linux/Unix musst du dann php auch noch mit mcrypt compilieren.

@TobiaZ: Wieso hast du es ins PHP Forum verschoben?
Das gehört ins Forum "Fragen zu Installation (LAMP, WAMP & Co.)" :o

Soviel mit compilieren habe ich auch mitbekommen, na super und wie mach ich das bitte schön?

Hab hier bei meinem Windows einen Apache laufen und da wollte ich das mal zunächst implementieren.

Jetzt sag auch bitte wie ich das ganze machen soll

Was übergibst du eigentlich so wichtige Daten über deine PHP Scripte, dass du unbedingt eine solch starke Chiffre brauchst?
Kannst du mir da mal ein beispiel geben, was du da übergibst?

ganz einfach ich hab dutzende von skript befehlen die ziemlich klein gehalten sind,

also start vereinfacht: weiterleitung.php?site=book&nick=rudi&pass=Hanswurst

ich möchte in erster Linie die Parameter verschlüsseln besonders das Passwort, mit wghwer ist unzureichend. Das Skript schützt zwar unauthorisierte Loggins aber das Passwort sollte man nun absolut nicht einsehen und daher wollte ich eine Verschlüsselung in der Art von web.de zum Beispiel.

Kannst du mir in dieser Beziehung bitte helfen?

Dann würde ich die Daten erst gar nicht über GET verschicken.
Ich hab' auch mal versucht, mir die mcrypt library zu installieren. hab's aufgegeben. ich hab mal im internet ne fertige php_mcrypt.dll gefunden, die ging aber nicht, hat nicht zur vorkompilierten phpversion gepasst.
Zudem ist mcrypt ja auch auf kaum einem server installiert. und du kannst es selber ja nicht installieren (es sei denn du hast nen eigenen server).

Mein Vorschlag. Wenn beide Scripte auf dem selben Server liegen, müssen sie nicht per GET kommunizieren. Speicher doch die Daten auf dem server temp. oder auch in einer db speicher und erst gar nicht per GET verschicken. Die Daten "nick" und "pass" kommen ja sowieso aus einer sicheren Quelle aus dem Server (nehme ich mal an) und nicht vom Clienten (Loginformular etc.). Bei letzterem würden deine ganzen Überlegungen sowieso nichts bringen, weil die Daten auf der Übertragung schon unverschlüsselt für jeden offen wären. :rolleyes:
Oder was meinst du genau? Dein Beispiel ist wenig konkret!? :rolleyes:


PS: web.de wird sicherlich auch keine Benutzerdaten per GET übergeben, sowas dürfte eigentlich niemand machen.



wghwer
Was ist wghwer?

wghwer
So eine Beispiel einer selbst programmierten Verschlüsselung

Aber wenn ich das ganze in einer MySQL Datenbank habe, was ich sowieso habe, dann müsste ich für jedes einzelne Skript bei der Datenbank nachfragen ob es übereinstimmt! Das Passwort müsste dann aber trotzdem weitergegeben werden da ansonsten jemand eine der folgenden Seite bookmarken könnte und indem Fall wäre die ganze Autorisierung sinnlos!

Und da ich nicht auf sessions als auch cookies verwende ist das nicht möglich.

Was kann ich stattdessen machen????

Aha.. Aber du hast nur meine letzte Frage beantwortet.

du liegst mit deiner Erkenntnis ganz richtig!
Was hab ich nicht beantwortet?

Du hast deinen Beitrag bearbeitet, das geht auch.


da ansonsten jemand eine der folgenden Seite bookmarken könnte und indem Fall wäre die ganze Autorisierung sinnlos!

Daran verhindert aber die Verschlüsselung der GET parameter nicht.
Vorrausgesetzt du identifizierst den Benutzer anhand von "nick" und "pass" die du per GET übergibst, dann braucht man nur den Link im Browsercache nachzuschauen und schon ist man drin in deinem System, obwohl sich der Benutzer schon ausgeloggt hat.
Ich würde ein Sessionsystem empfehlen, das ist in jedem Fall sicherer.

Also ich würde dir empfehlen, das ganze mal ganz ganz gründlich zu überdenken. Dein Konzept scheint jedenfalls nicht sehr gut durchdacht zu sein. :teach:
Ich würde sagen, les' dir mal den owasp Guide (http://owasp.org/guide/) (OWASP Guide to Building Secure Web Applications and Web Services) durch.

aber sessions sind nicht überall verfügbar, was auch wieder ein Problem ist

Und Cookies braucht man doch wohl auch dazu oder?

Ist Neugebiet für mich, Cookies kommen nicht in die Tüte

Lassen sich Session durch User blockieren.

wie richte ich in meiner Testumgebung Sessions ein, hab gerade so ein Tool runtergeladen weil ich mir das mit den Session anschauen wollte, aber die Installation funzt nicht da Sessions fehlen,

danke für deine Hilfe

Sessions sind sowohl ohne Cookies als auch mit Cookies möglich. Damit kann der User sie auch nicht blockieren.
Sessiondaten werden serverseitig gespeichert, deshalb sind dort die Daten sicher - sie werden nicht übers Web versand. Das einzige, was der User braucht ist die Session ID. Die wird entweder in einem Cookie gespeichert oder per URL weitergegeben. (seite.php?session_id=$session_id). Die Cookievariante ist wenn möglich vorzuziehen, weil es doch etwas mehr Aufwand ist, den Cookie auszuspionieren, als die Session ID im Verlauf des Browsers nachzugucken. Das Dilemma entschärfst Du aber, weil Sessions nur eine begrenzte Lebensdauer haben und nach einer Stunde (oder 20 Minuten, wie du willst) wieder vom Server gelöscht werden. Wenn du unbedingt möchtest, kannst Du noch die IP Adresse an die Session binden (sprich: Integrität der IP innerhalb der Session prüfen).

Sessions sind an sich ne schöne Sache. Gut, die Sessionfunktionen von PHP sind "erst" ab PHP4 integriert, aber wer hat denn noch PHP3. Soviel zur Verfügbarkeit. Und wenn nicht, kannst Du dir deinen eigenen Sessionsystem schreiben, was auch nicht so viel Arbeit ist (wir helfen Dir schon ;D).
Das ganze erfordert natürlich auch ein wenig Einarbeitungszeit, ganz klar.
Aber an der Verfügbarkeit von Sessions soll es nicht scheitern - da ist die mcrypt library ein viel größeres Problem.

Aber gerade wenn Du einen Mitgliederbereich oder sonstwas (alles was mit Benutzerauthentifikation oder Login zu tun hat) planst, sind Sessions doch schon recht nützlich und auch weitverbreitet.
Schau mal unter http://owasp.org/guide/ im Kapitel Benutzerauthentifikation/Sessions, etc. etc. Ist ganz interessant, wenn auch in englisch.
Oder schlag mal in einem Buch über PHP Sessions nach.