nicht angemeldet T-Rex
Nico
T-Rex
T-Rex
Camping_RIDER
T-Rex
Camping_RIDER
T-Rex
T-Rex
Camping_RIDER
tk
Moin,
ich soll Informationen an eine URL anhängen, die von Außenstehenden nicht ohne weiteres gelesen werden können. Dabei geht es nicht um eine 100% Sichere Verschlüsselung. Es handelt sich nicht um ein Passwort.
Die Maskierung soll auf der Zielseite wieder Rückgängig gemacht werden.
Beispiel:
An die url www.example.org soll ein Parameter mit dem Wert "selfhtml" angehängt werden. Normalerweise würde es so aussehen: www.example.org?par=selfhtml. selfhtml soll jedoch maskiert werden. Also sieht der Link am Ende eventuell so aus www.example.org?par=15%gzlk5$2. Wichtig ist, dass der Wert am Ende wieder ohne Große Umrechnungstabelle zu selfhtml ausgelesen werden kann.
Das einzige was ich mit "maskierung" bislang gemacht habe sind die einwege Sachen sha, md5 und der ganze Krams. Gibt es eine Möglichkeit via php einen String zu maskieren und demaskieren?
Gruß
Masken
T-Rex
Hakuna matata!
helfen Dir die Funktionen Base64 Encode und Base64 Decode weiter?
Wohl kaum, base64 ist eine Kodierung und keine Verschlüsselung. Aus kryptographischer Sicht sind base64-kodierte Daten genauso sicher einzustufen, wie die Rohdaten selbst. Das kann man sich also schenken.
Wohl kaum,
Vielleicht richtig, vielleicht nicht.
base64 ist eine Kodierung und keine Verschlüsselung. Aus kryptographischer Sicht sind base64-kodierte Daten genauso sicher einzustufen, wie die Rohdaten selbst.
richtig
Das kann man sich also schenken.
Vielleicht, vielleicht nicht.
Aber:
Dabei geht es nicht um eine 100% Sichere Verschlüsselung.
Die MASKIERUNG soll auf der Zielseite wieder Rückgängig gemacht werden. [Großschreibung hinzugefügt]
selfhtml soll jedoch MASKIERT werden. [Großschreibung hinzugefügt]
Wichtig ist, dass der Wert am Ende wieder OHNE Große Umrechnungstabelle zu selfhtml ausgelesen werden kann. [Großschreibung hinzugefügt]
Sessiondaten sind sicherlich auch eine Möglichkeit. Möglich ist bis auf weiteres auch das T-Rex genau so etwas sucht. Auch wenn natürlich Maskierung ungleich Kodierung könnte trotzdem sowas gemeint sein
Ahoi!
Jup, dass war es. Genau ins Schwarze! Danke!
Gruß
der auf Twitter jetzt positiv erwähnte
T-Rex
Hakuna matata!
Jup, dass war es. Genau ins Schwarze! Danke!
Stammt der Vogelstrauß direkt vom T-Rex ab? Wie auch immer, hier oben mit dem Kopf über dem Sand, ist es nicht so schwarz.
Deine Daten gehören URL-kodiert, nicht base64-kodiert. Kodierungen sind da um technische Randbedingungen bei der Informationsübertragung zu bewätigen, sie sind nicht dafür da, um Kummunikationskanäle vor unbefugten Eingriffen zu schützen. Das ist Aufgabe der Kryptographie.
Der Morsecode ist zum Beispiel eine einfache Kodierung. Morsecodes werden in der Seefahrt eingesetzt, wo es häufig keine Kabel- oder Funkverbindungen gibt. Aber jeder, der den Morsecode kennt, kann Nachrichten mitlesen und auch selber versenden.
UTF8 ist eine Kodierung, damit wird der Unicode-Zeichensatz auf Binärdaten abgebildet. Natürlich kann jeder, der UTF8 versteht solche Binärdaten auch wieder zum ursprünglichen Text umwandeln. Dieser Vorgang nennt sich Dekodierung.
Mit Base64 bildet man Binärdaten auf ein 64-Zeichen-umfassendes Alphabet ab. Und auch hier kann jeder, der Base64 kennt, ohne Audwand auf die ursprünglichen Daten schließen und seine eigenen Base64-Nachrichten verfassen.
Die URL-Kodierung bildet Zeichen, die in einem URL eine eigene Rolle spielen, auf harmlose Escape-Sequenzen ab, damit diese den URL nicht ungewollt verfremden. Das sind also die Sonderzeichen, dazu gehört zum Beispiel das Leerzeichen, welches auf die Zeichenfolge %20 abgebildet wird. Dazu gehört auch der Schrägstrich, welcher auf %2F abgebildet wird. Der Schrägstrich kommt übrigens auch im Base64-Alphabet vor und allein das ist ein guter Grund, warum du die Daten url-kodieren solltest.
Für dein Problem ist Base64 jedenfalls das falsche Werkzeug. Du möchtest, dass deine Logs mit den tatsächlichen Bestellungen übereinstimmen, bei deinem Problem geht es also um die Integrität von Daten.
Im einfachsten Fall greift man so ein Problem an der Wurzel und man sorgt dafür, dass erst gar keine Integritätsverletzungen auftreten können. Dies könntest du zum Beispiel machen, indem du die Daten dann logst, wenn die Bestellung auch tatsächlich abgesendet wird und nicht irgendwann später.
Falls das keine Option ist, was ich mir nur sehr schwer vorstellen kann, dann kannst du auf eine Prüfsumme zurückgreifen. Du kannst bei der Bestellung eine Prüfsumme erstellen und zwischenspeichern, wenn dann später die Daten für das Logging kommen kannst du abermals die Prüfsumme bilden und mit der vorherigen Prüfsumme vergleichen. Stimmen sie nicht, dann sind die Daten offenbar verfremdet worden.
Du könntest die Bestell-Parameter auch vor dem Logging mit einer digitalen Signatur versehen, um dich deren Echtheit zu vergewissern.
Es gibt viele Lösungsansätze, aber Base64 ist mit Sicherheit keine. Was in deinem Fall am besten ist, können wir immernoch nicht diskutieren, weil die Informationen noch zu spärlich sind.
Danke für deine Ausführungen.
Base64 ist genau das passende. Meine Informationen waren ausreichend genug damit zwei unabhängige Poster auf den gleichen Schluss kamen, der meine Frage und mein Problem lösen.
Gruß
befriedigter
T-Rex
Aloha ;)
Für dein Problem ist Base64 jedenfalls das falsche Werkzeug. Du möchtest, dass deine Logs mit den tatsächlichen Bestellungen übereinstimmen, bei deinem Problem geht es also um die Integrität von Daten.
Nein, ich glaube da hast du T-Rex falsch verstanden. Es geht T-Rex (zumindest so wie ich ihn verstehe) weder um Sicherheit noch um Integrität der Daten - sondern einzig und allein darum, Daten nicht im Klartext zu übertragen. Nicht weil eine mögliche Manipulation schlimm wäre, sondern weil zumindest eine gewisse technische Hürde von allzu einfachen Manipulationen "aus Spaß" abhalten soll.
Außerdem: Security through Obscurity zählt ja immerhin auch noch was.
Wenn ich als Anwender auf eine Seite verlinkt werde
http://example.org/?data=IchHabeEinmalGeklickt
Dann ist für mich der Anreiz viel höher, die Statistik zu fälschen indem ich mutwillig
http://example.org/?data=IchHabeZweimalGeklickt
aufrufe, als wenn da steht
http://example.org/?data=45HjkL904Q-/%99sGfs
URL-kodieren zugunsten der Datenintegrität kann man ja trotzdem...
Wenn du so willst, geht es nicht TATSÄCHLICH darum etwas zu verhindern, sondern nur darum, interne Mechanismen zu verschleiern um allzu einfache Aushebelung zu blockieren.
Grüße,
RIDER
Tag.
Für dein Problem ist Base64 jedenfalls das falsche Werkzeug. Du möchtest, dass deine Logs mit den tatsächlichen Bestellungen übereinstimmen, bei deinem Problem geht es also um die Integrität von Daten.
Nein, ich glaube da hast du T-Rex falsch verstanden. Es geht T-Rex (zumindest so wie ich ihn verstehe) weder um Sicherheit noch um Integrität der Daten - sondern einzig und allein darum, Daten nicht im Klartext zu übertragen.
Auch nicht. Ihm geht es darum, seinem Chef irgendeinen schnell zusammenzuschusternden Mist unterzuschieben, damit der Trottel endlich Ruhe gibt.
Die Frage ist nur, wann ihm das auf die Füße fällt :-)
Auch nicht. Ihm geht es darum, seinem Chef irgendeinen schnell zusammenzuschusternden Mist unterzuschieben, damit der Trottel endlich Ruhe gibt.
YYYYEEEEEEAAAAAHHHHHH !!! Jemand der mich versteht *schnief*
Die Frage ist nur, wann ihm das auf die Füße fällt :-)
Uhi das passiert aktuell schon. Das ganze System fällt jeden Monat ein Stück mehr auseinander ;). Aber anstatt etwas kleines Richtig zu machen, wird nach einem Investor gesucht um den Scheiß den man hat auf der ganzen Welt zu verteilen *seufz*.
Guckt man sich aber mal Zalando, Amazon, Facebook und Twitter an, dann darf man Erfolg nicht mit Gewinn verwechseln. Erfolg haben anscheinend diejenigen die super mega fette rote Zahlen schreiben. Also sind wir bald sehr Erfolgreich!!
Gruß
Aktien an Privatidioten verkaufender
T-Rex
Hakuna matata!
Für dein Problem ist Base64 jedenfalls das falsche Werkzeug. Du möchtest, dass deine Logs mit den tatsächlichen Bestellungen übereinstimmen, bei deinem Problem geht es also um die Integrität von Daten.
Nein, ich glaube da hast du T-Rex falsch verstanden.
Mir geht es nicht nur um T-Rex. Das Problem, das er hat, tritt im Alltag recht häufig auf und dieser Thread wird vielleicht irgendwan mal von einem Nutzer gelesen, der ein ganz ähnliches Problem hat, der sich aber nicht mit Fusch zufrieden geben möchte. Und Fusch ist hier noch sehr gelinde ausgedrückt. Auf jedenfall möchte ich auch für jene Nutzer hier eine zweite Meinung einbringen und diese mit möglichst viel Hintergrund untermauern.
Um den Spieß mal umzudrehen, was hätte denn eine gewissenhafte Lösung, die mit Sicherheit Datenmanipulation erkennen kann, für Nachteile gegenüber der Base64-Schlamperei?
Aloha ;)
Mir geht es nicht nur um T-Rex. Das Problem, das er hat, tritt im Alltag recht häufig auf und dieser Thread wird vielleicht irgendwan mal von einem Nutzer gelesen, der ein ganz ähnliches Problem hat, der sich aber nicht mit Fusch zufrieden geben möchte. Und Fusch ist hier noch sehr gelinde ausgedrückt. Auf jedenfall möchte ich auch für jene Nutzer hier eine zweite Meinung einbringen und diese mit möglichst viel Hintergrund untermauern.
Das ist auf jeden Fall sinnvoll, richtig.
Um den Spieß mal umzudrehen, was hätte denn eine gewissenhafte Lösung, die mit Sicherheit Datenmanipulation erkennen kann, für Nachteile gegenüber der Base64-Schlamperei?
Meine erste Intention wäre eine Session-basierte Speicherung. Wenn man auf eine Seite umgeleitet wird, die nichts anderes tut als Daten-Logging, dann können da auch Sessionbasierte Daten aufgerufen / benutzt werden.
Ich bin auf dem Gebiet der Sicherheit allerdings deutlich mehr interessierter Laie als Experte.
Grüße,
RIDER
Um den Spieß mal umzudrehen, was hätte denn eine gewissenhafte Lösung, die mit Sicherheit Datenmanipulation erkennen kann, für Nachteile gegenüber der Base64-Schlamperei?
Zeit und somit Kosten.
Gruß
Frau Efi Zient-Rex
Hakuna matata!
ich soll Informationen an eine URL anhängen, die von Außenstehenden nicht ohne weiteres gelesen werden können.
Du möchtest serverseitig Informationen verschlüsseln, an einen Link hängen und zum Nutzer schicken. Der kann dem Link folgen, und wenn er das tut, werden die Daten auf dem Server wieder entschlüsselt. Habe ich das richtig verstanden?
Offensichtlich hat der Nutzer gar nichts mit diesen Daten zu schaffen, wieso muss er also überhaupt in diese Kommunikation miteinbezogen werden?
Wenn es möglich ist, würde ich den Nutzer ganz aus diesem Prozess raushalten, er hat offenbar keinen unmittelbaren Zugriff auf die Informationen, und muss deshalb auch nicht zum Mittelsmann gemacht werden. Eine Session wäre möglicherweise ein geeigneter Ansatz.
In jedem Fall wären ein paar Informationen mehr notwendig, um zu einer sinnvollen Einschätzung zu gelangen.
Dabei geht es nicht um eine 100% Sichere Verschlüsselung. Es handelt sich nicht um ein Passwort.
50% sicher ist wie 50% schwanger.
Nein zum User wird nichts geschickt.
Es gibt einen Kaufen-Link (Button). Da klickt der User drauf. An dem Link hängen gewisse Informationen dran. Der User kommt auf eine "Weiterleitungsseite". Dort werden die Informationen ausgewertet, in ein Log geschmissen (in diesem Fall Google Analytics) und der User wird weiter zum Angebot geleitet, welches sich nicht auf unserer Domain bzw. unter unserer Kontrolle befindet. Diese Logs sollen Aufschluss geben, welcher Button wie oft gedrückt wird und wie hoch am Ende die Abschlüsse (Sales) sind.
Mein Chef möchte, dass die Informationen nicht lesbar sind, weil er sich einbildet dass dann jedermann diese Informationen manipulieren wird und die Logs nutzlos werden (Die User haben ja auch nix besseres zu tun...*seufz*).
Also ganz einfach:
Ich möchte einen String an einer stelle maskieren (unleserlich) und an einer anderen Stelle demaskieren (leserlich) machen und das in PHP.
Gruß
maskierter
$-%h&
Aloha ;)
Mein Chef möchte, dass die Informationen nicht lesbar sind, weil er sich einbildet dass dann jedermann diese Informationen manipulieren wird und die Logs nutzlos werden (Die User haben ja auch nix besseres zu tun...*seufz*).
Kann ich verstehen. Schließlich gibt es einen Unterschied zwischen der Möglichkeit einer ganz einfachen Manipulation und einer Manipulation, die einen gewissen (sei er auch noch so gering) Aufwand bedeutet. So ähnlich wie Youtube das Downloaden technisch zwar nie gänzlich ausschließen kann, die technische Hürde aber schon viele Downloader abhält. Wenn es um Statistik geht ist eine Maskierung zwar nicht sicher, aber definitiv effektiv gegen die meist halbherzigen Standardangriffe von Spammern und Co.
Also ganz einfach:
Ich möchte einen String an einer stelle maskieren (unleserlich) und an einer anderen Stelle demaskieren (leserlich) machen und das in PHP.
Dann verweise ich hiermit einfach auf das schon genannte Base64Encode, das kann exakt das, was du brauchst... Ansonsten wäre auch eine einfache, selbst geschriebene Cäsar-Verschlüsselung möglich, ist fast n Einzeiler.
Grüße,
RIDER
Hallo,
Ansonsten wäre auch eine einfache, selbst geschriebene Cäsar-Verschlüsselung möglich, ist fast n Einzeiler.
Das *ist* ein Einzeiler, selberschreiben muss man da nämlich nix: str_rot13() existiert …
Gruß,
Tobias
Sag doch gleich du möchtes (Affiliate-)Links tracken und cloaken. Da hast du auch schon die Suchbegriffe Link cloaken (maskieren) und Link (affiliatelink) tracken (tracking). Hier mit sollten genug technische Möglichkeiten in der SUMA auftauchen.
Aber dran denken die Ergebnisse werden abweichen. Das ist aber ganz Normal.
Dort werden die Informationen ausgewertet, in ein Log geschmissen (in diesem Fall Google Analytics) und der User wird weiter zum Angebot geleitet,
Das ist murks. Wenn ein Link angeklickt wird bekommt der Server das ja bereits mit uns du kannst diese Information direkt in einer Datenbank oder Textdatei speichern und auch ohne Google Analytics selber auswerten/mit zählen.
Diese Logs sollen Aufschluss geben, welcher Button wie oft gedrückt wird und wie hoch am Ende die Abschlüsse (Sales) sind.
Dann vergleiche deine Textdatei am Monatsende mit den erfolgten Sales.
Mein Chef möchte, dass die Informationen nicht lesbar sind, weil er sich einbildet dass dann jedermann diese Informationen manipulieren wird und die Logs nutzlos werden (Die User haben ja auch nix besseres zu tun...*seufz*).
Eine verschlüsselte URL wird von Bots ebenso aufgerufen wie eine normale und verfälscht deine Statistik dadurch genau so. Gegen Bots in der Statistik verwende ich eine Erkennung des Useragents, da viele Bots darin eine URL enthalten. 100% kannst du Bots jedoch auch mit der robots.txt nicht ausschliesen. Dafür brauchst du ein Capcha Code oder ne Frage wie heisst die Kanzlerin?
Mein Chef möchte, dass die Informationen nicht lesbar sind,
Dann überleg dir ein Passwort und lass eine While Shleife jeden Buchstaben des zu verschlüsselnden Wertes mit dem ASCII Wert deines Passwortes multiplizieren oder Link einfach auf Produkt 1 bis 100 statt den Produktname zu nennen. Das alles hilft dir wie gesagt aber nicht gegen automatische Bots mit "Search, Archive, crawl, index" etc im Useragent.
ich soll Informationen an eine URL anhängen, die von Außenstehenden nicht ohne weiteres gelesen werden können. Dabei geht es nicht um eine 100% Sichere Verschlüsselung. Es handelt sich nicht um ein Passwort.
Die Maskierung soll auf der Zielseite wieder Rückgängig gemacht werden.
Variante 1:
Mit strtr() lassen sich Zeichen beliebig gegen andere austauschen. Übergebe der Funktion zwei Listen, eine mit sämtlichen Buchstaben, Ziffern und was dir sonst noch einfällt, eine zweite mit dem Inhalt der ersten Liste, nur kräftig durcheinandergewürfelt (das kannst du einmal mit str_shuffle() machen, danach bleiben die beiden Listen konstant).
Entschüsseln auf dem gleichen Wege.
Variante 2:
Falls Quell- und Zielsystem identisch sind, benutze die $_SESSION-Geschichte von PHP. Du kannst sie IIRC auch mit Datenbank umsetzen und die ID in der URL transportieren (statt im Cookie), falls längere Haltezeit erwünscht ist.
Der Aufwand ist deutlich größer als bei Variante 1, dafür ist dieser Weg aber auch praktisch nicht angreifbar.
Was spricht gegen Verschlüsselung?
In die Verschlüsselung kannst du noch andere Werte packen falls du das mal willst, z.B. einen Zeitstempel der den Link irgendwann wieder ungültig werden lässt und ihn außerdem einmalig macht.
Sowas dürfte schneller umgesetzt sein als du für die Suche nach irgendwas schnellem brauchst, das somit gar nicht mehr so schnell ist :-)
