Losemenge.de - Mindestlosemenge, Loseumlauf, Losevernichtung, Kontostände von mehr als 40 Projekten!

[jgry]

Zitat von DaxDony

Es gibt schon erste Werte.
Auf den Teil mit dem PHP-Parser möchte ich jetzt mal nicht eingehen ().

Schade...

Zitat von chrissel

(Zitate kommen aus dem Thread der GLVA)



Sollte der PHP-Parser aussetzen auf einer Loseseite, werden dort auch die Passwörter sichtbar. Dann muss man dort nämlich nur die Konfigurationsdatei aufrufen und hat mindestens das MySQL-Passwort.. damit kommt man dann gut weiter.
Wenn man die URL des Losemenge-Scriptes kennt und der PHP-Parser setzt aus sieht man den Inhalt des Scriptes auch im Klartext und somit das Passwort, da hast du völlig recht.

Nein.
Man lege die Zugänge in einer PHP-Datei auserhalb des öffentlichen bereichs / in einem mit htaccess geschützen Bereich des Servers => Zugriff nur vom Localhost aus möglich.

Diese Datei wird in die öffentlichen Scripts die zugänglich sein müssen Includiert.
Fällt der Parser aus sieht man nur noch den Include Befehl, nicht aber die Daten. Den Dateinahmen zu kennen nützt einem auch nichts, wegen der Zugriffsbeschränkung auf den Bereich wo sich diese Datei findet.

Wer natürlich die Konfigurationsdatei nicht schützt, ist selber schuld, und sollte vielleicht mal drüber nachdenken ob es nicht besser wäre die eigene Seite dicht zu machen. Hart formuliert, aber so ist es nun mal.
Im öffentlichen Bereich hat diese nichts zu suchen.

Zwar ist ein Abschuss des PHP Parsers unwahrscheinlich, aber man sollte sowas bedenken, man weis ja nie was passiert...

Das ist genau so schlimm dann, als wenn man direkt die Loseseite aufruft. Dafür muss dann der böse Mensch auch die URL zu dem Script wissen, die auf Losemenge auf jeden Fall verschlüsselt gespeichert wird, ob der Seiteninhaber die URL dann verbreitet oder nicht ist seine Sache.

Ich denke bei einigen Seiten wir die URL dank dummheit auch zu erraten sein, da ich kaum glaube das sich jemand die mühe macht diese Dateien zu verstecken.

Aber als Tipp: Die Leute sollen das Script htaccess protecten so das nur deine Server IP auf dieses Verzeichnis Zugriff bekommt. Dies bringt schon mal einen guten Schutz gegen fremde aufrufe.

€:

Und das mit dem FTP: ich kann mir denken woher du das hast... nur ist es schon unwahrscheinlicher das jemand den FTP Knackt, anstatt das er durch eine ServerPanne (PHP Parser) oder durch einen Scriptfehler an die Daten kommt.

€²:

Zum Thema verlässliche Daten, es ist halt eine Vertrauenssache, entweder die User Vertrauen auf die Sicherheit der Daten bei dir, oder du vertraust auf die Richtigkeit der Daten der User.

Ich fände es durchaus machbar wenn die Seiten ein eigenes Script betreiben das den EF Stand ausliest und man diesen Stand einfach nur einliest (bevor es wer Überliest: Ich spreche hier nicht von Userguthaben.).
So ist es in der Verantwortung des EFs inhaber wie sicher das Script ist, und nicht in deiner

[DaxDony]

Du solltest ein Buch schreiben: "Sichere PHP-Applikationen entwickeln" und am Ende von jedem Kapitel schreibst du dann:

Zitat von jgry

Wer natürlich die X nicht schützt, ist selber schuld, und sollte vielleicht mal drüber nachdenken ob es nicht besser wäre die eigene Seite dicht zu machen. Hart formuliert, aber so ist es nun mal.

[jgry]

Zitat von DaxDony

Du solltest ein Buch schreiben: "Sichere PHP-Applikationen entwickeln" und am Ende von jedem Kapitel schreibst du dann:

was soll das werden? hast du immer noch ein Problem damit das ich meine Meinung dazu geäußert habe wie du Bankdaten gespeichert hast?
Lass es doch einfach sein, wenn du nichts Sinnvolles zur Sache beitragen kannst.

[chrissel]

Zitat von jgry

Nein.
Man lege die Zugänge in einer PHP-Datei auserhalb des öffentlichen bereichs / in einem mit htaccess geschützen Bereich des Servers => Zugriff nur vom Localhost aus möglich.

Ja klar, ist mir bekannt.
Wird nur imho von den wenigstens Seiten hier auf klamm so gemacht (alleine die Scripts die im Umlauf sind bieten das glaube ich auch nicht ohne Änderungen an).
Und das der PHP-Parser versagt genau in dem Moment, in dem jemand die URL austestet ist finde ich sehr unwahrscheinlich.
Mal schauen ob ich dennoch die Passwörter in einer Konfigurationsdatei auslagere.

Zitat von jgry

Aber als Tipp: Die Leute sollen das Script htaccess protecten so das nur deine Server IP auf dieses Verzeichnis Zugriff bekommt. Dies bringt schon mal einen guten Schutz gegen fremde aufrufe.

Das wäre eine Idee. Müsste ich nur schauen ob mein Script so etwas erlaubt. Also damit meine ich folgende URLs aufzurufen: http://username:passwort@www.example.com/losemenge.php

Zitat von jgry

Und das mit dem FTP: ich kann mir denken woher du das hast...

Woher ich was habe?

Zitat von jgry

Zum Thema verlässliche Daten, es ist halt eine Vertrauenssache, entweder die User Vertrauen auf die Sicherheit der Daten bei dir, oder du vertraust auf die Richtigkeit der Daten der User.

Ja, entweder viele Personen vertrauen einer (=mir) oder eine (=ich) vertraut vielen Personen.
Was wird wohl wahrscheinlicher sein? Das eine Person Mist baut oder das unter vielen Personen eine Mist baut?

Zitat von jgry

Ich fände es durchaus machbar wenn die Seiten ein eigenes Script betreiben das den EF Stand ausliest und man diesen Stand einfach nur einliest (bevor es wer Überliest: Ich spreche hier nicht von Userguthaben.).
So ist es in der Verantwortung des EFs inhaber wie sicher das Script ist, und nicht in deiner

So war es bei der damaligen Version von losemenge.de.
Allerdings vertraue ich ehrlich gesagt nicht allen Loseseitenbetreibern, dass diese mir richtige Daten übermitteln. Will einer mal die Losemenge hochtreiben übermittelt der einfach eine höhere Summe als er wirklich auf seinem EF-Account hat.
Und genau hierdurch kann ich am Ende nicht sagen, dass es wirklich mindestens so viele Lose gibt wie ich ermittelt habe. Man kann dann einfach keine verlässliche Zahl angeben..

[DaxDony]

Zitat von jgry

Zum Thema verlässliche Daten, es ist halt eine Vertrauenssache, entweder die User Vertrauen auf die Sicherheit der Daten bei dir, oder du vertraust auf die Richtigkeit der Daten der User.

Ich fände es durchaus machbar wenn die Seiten ein eigenes Script betreiben das den EF Stand ausliest und man diesen Stand einfach nur einliest (bevor es wer Überliest: Ich spreche hier nicht von Userguthaben.).
So ist es in der Verantwortung des EFs inhaber wie sicher das Script ist, und nicht in deiner

Du hast das Prinzip von diesem Projekt absolut nicht verstanden. Es geht darum Daten zu bekommen, die 100% richtig sind. Das kann nur gewährleistet werden, wenn die Daten direkt über die Klamm-API ausgelesen werden, alles andere ist Schwachsinn.

Was meinst du wie viele Leute es geben wird, die es lustig finden werden einfach mal ein EF einzurichten, wo angeblich 1 bio Klammlose drauf sind.

[ice-breaker]

So, ich habe mir jetzt auch mal eine Stunde Gedanken gemacht.
Ich habe eine sichere Variante gefunden
Für irgendetwas muss Erfahrung doch gut sein. Es wundert mich, dass die noch niemand hatte...

kurzer Umriss:
Lukas bietet keine EF-Statistikfunktion an und die bisherigen Optionen sind für Seitenbetreiber nun nicht die optimalsten, jedoch gibt es doch Statistikpasswörter für normale Klamm-Konten, dies machen wir uns zu Nutze: Wenn der Losestand gemessen werden soll transferieren die Seitenbetreiber ihre Lose selbst auf ihren eigenen Klamm-Account von wo die Menge abgelesen werden kann und wenn die Menge erfasst wurde, können die Lose wieder zurück-transferiert werden.

lange technische Erklärung:
Mittels curl_multi_exec() wird parallel bei allen Seitenbetreibern ein Script aufgerufen, welches diesen mitteilt, dass sie ihre EF-Lose auf ihren Klamm-Account verschieben sollen (1). Diese Transaktion gilt nur für 30 Sekunden, d.h. dass die Seitenbetreiber selbst per Cron, wenn sie möchten, die Lose wieder nach der Zeitspanne abziehen können (Sicherheitsfunktion) oder erst wenn sie von LoseMenge.de die Nachricht erhalten, dass der Losestand fertig gemessen wurde.
Bekommt das LoseMenge.de nun von allen Seiten den Status zurück, dass sie fertig sind beginnt wiederum parallel (2) das Auslesen aller Klamm-Accounts mit den Statistikpasswörtern.
Ist dies fertig werden jetzt erst (3) alle Seitenbetreiber informiert, dass sie ihre Lose zurücktransferieren können, wenn sie dies selbst noch nicht durch die 30-Sekunden-Regel gemacht haben (unter der Annahme der Vorgang dauerte länger als 30s).
Nun ist das LoseMenge.de Script fertig und hat einen einigermaßen konsistenen Snapshot aller teilnehmenden Seiten ohne auch nur einmal in Besitz der Passwörter des EFs oder deren Lose zu sein.

Wer den Ablauf nun noch nicht ganz verstanden hat, kann sich das angehängte Sequenzdiagramm ansehen.



(1) dabei müssen natürlich nicht alle Lose verschoben werden, es kann ein Sicherheitspuffer aus dem EF für einen reibungslosen Betrieb bleiben. Dadurch hat man zwar nicht jedes Los in der Statistik, aber durch die breitere Akzeptanz des Verfahrens im Endeffekt eine viel höhere absolute Menge

(2) damit gleichzeitig stattfindende Transaktionen am wenigsten den Gesamtlosestand beeinflussen

(3) wenn dies nicht so wäre, und Seitenbetreiber direkt informiert werden würden, wenn sie ausgelesen wurden, könnten Sie ihre Lose auf einen anderen Account transferieren - mit dem sie kooperieren - in der Hoffnung, dass dessen Klamm-Account noch nicht ausgelesen wurde, dementsprechend würde die Losemenge doppelt gezählt werden.


@chrissel: du kannst mich auch gerne kontaktieren, falls noch Fragen sind

[jgry]

Zitat von chrissel

Ja klar, ist mir bekannt.
Wird nur imho von den wenigstens Seiten hier auf klamm so gemacht (alleine die Scripts die im Umlauf sind bieten das glaube ich auch nicht ohne Änderungen an).
Und das der PHP-Parser versagt genau in dem Moment, in dem jemand die URL austestet ist finde ich sehr unwahrscheinlich.

Unwahrscheinlich, aber nicht unmöglich, sowas ist einfach die feine art das man dies so macht. Nur weil es andere nicht machen, muss man selbst die Fehler ja nicht kopieren.

Das wäre eine Idee. Müsste ich nur schauen ob mein Script so etwas erlaubt. Also damit meine ich folgende URLs aufzurufen: http://username:passwort@www.example.com/losemenge.php

Nein, das geht viel einfacher über die IP. Ich gehe mal davon aus das dein Server einen Statische IP hat...

Code:

1: 2: 3: 4: 5:

# Datei zum Regeln von IP-Bereichen Order deny,allow Deny from all Allow from A.B.C.D Allow from 127.0.0.1

IPv6 Support ebenfalls möglich

Ersetze A.B.C.D mit deiner IP Adresse.
den localhost kann man sich in diesem Fall eigentlich auch sparen da dieser ja nicht benötigt wird.

Diese Datei mit dem Script in einen eigenen Unterordner und schon ist das Script gegen Fremd-aufrufe abgesichert. Zumal es sonst möglich wäre deinen Server zu "beschäftigen" mit diesem Script, mehr als die EF Idee braucht man ja nicht um eine Anfrage an deinen Server auszulösen.

Woher ich was habe?

Die Tatsache das du erwähnst das eine Verschlüsselung nutzlos ist wenn der FTP Server geknackt wird. Kommt mir so bekannt vor...

Ja, entweder viele Personen vertrauen einer (=mir) oder eine (=ich) vertraut vielen Personen.
Was wird wohl wahrscheinlicher sein? Das eine Person Mist baut oder das unter vielen Personen eine Mist baut?

Da könnte ich jetzt viele böse Beispiele bringen aber dann wird wieder Gepopelt da hab ich keine Lust zu.

Du kannst diese Möglichkeit ja auf Seiten begrenzen denen du vertraust.

Bzw auf EFs. Wie zum Beispiel den der GLVA? (ich kann zwar nicht für die GLVA Sprechen, aber ich denke es wäre wesentlich einfacher zu überzeugen wenn, und ich sehe keinen Grund warum die GLVA ihren EF-Stand manipulieren sollte.
Vorteil du hättest damit auch einen weiteren "größeren" (relativ) EF in der Liste

Dies würde sich auch positiv auf das Gesamtprojekt auswirken, misstrauen ist gut, aber es nimmt auch Möglichkeiten. Du sagst ja selbst, du vertraust nicht allen Seiten, dies beinhaltet das du Seiten/EF-Usern vertrauen würdest.
Diesen könntest du ja dieses Feature anbieten.

Zitat von DaxDony

Du hast das Prinzip von diesem Projekt absolut nicht verstanden. Es geht darum Daten zu bekommen, die 100% richtig sind. Das kann nur gewährleistet werden, wenn die Daten direkt über die Klamm-API ausgelesen werden, alles andere ist Schwachsinn.

Was meinst du wie viele Leute es geben wird, die es lustig finden werden einfach mal ein EF einzurichten, wo angeblich 1 bio Klammlose drauf sind.

Siehe das, was über diesem Zitat steht...

[DaxDony]

Zitat von ice-breaker

Es wundert mich, dass die noch niemand hatte...

Schau mal hier:

Als Alternative gibt es noch ein Script, welches nur die freiliegenden Lose auf dem EF-Account erfassen kann (also keine im Tresor).
Dieses Script kann nur in Verbindung mit einem eingetragenen Klamm-Account genutzt werden und transferiert vor dem Auslesen alle Lose des EF-Accounts auf diesen und anschließend wieder zurück.
Hierdurch fallen allerdings pro Losezählung 3 ExportForce-Anfragen für jeden EF-Account an (Losestand auslesen, Lose einziehen, Lose zurückzahlen). Die einzigen Daten die das Script an Losemenge.de übermittelt sind alle eingetragenen EF-Accounts zum Abgleich mit den bei der ersten Methode eingetragenen EF-Accounts, keine EF-Passwörter!
Die Anmeldung geschieht über die normale Klamm-Account Anmeldung, hier muss einfach bei dem Punkt EF-Script der Link zu dem installierten Script eingetragen werden.
Sollte man sich bereits angemeldet haben mit seinem Klamm-Account kann man die Anmeldung mit dem EF-Script einfach wiederholen um dieses einzutragen.

[ice-breaker]

Neija das genau das damit ersichtlich ist, ziemlich doof beschrieben...
Zudem muss mein Ansatz nicht bei Tresorlosen halt machen.

Also wenn die Beschreibung so kacke ist und wirklich das gleiche beschreibt, sollte man die am besten aktualisieren und dies auch zur 1. Option machen, wer liest denn noch weiter, nachdem man ihm bei Option 1 sagt er soll sein EF-Passwort hergeben ...

[chrissel]

Zitat von ice-breaker

Neija das genau das damit ersichtlich ist, ziemlich doof beschrieben...
Zudem muss mein Ansatz nicht bei Tresorlosen halt machen.

Texte schreiben war noch nie so mein Ding, weiß ich, stehe ich zu

Vielen Dank erst einmal für dein Mühe und überaus ausführliche Darstellung (sollte echt für nahezu jeden verständlich sein, auch die Grafik gefällt mir )
Nuuur.. meine Alternative sollte genau so eine Möglichkeit darbieten.
Das Script auf dem Server des Teilnehmers wird aufgerufen, erhält den Befehl die Lose auf den klamm-Account zu transferieren. Anschließend werden diese mithilfe des Statistik-PWs ausgelesen und danach gibt es ein neuen Befehl diese wieder auf den EF zu transferieren.
Sollte doch so sein wie dein Ansatz? Nur, dass deiner im allgemeinen sicherlich schöner ausgearbeitet ist (gerade das mit den 30sec z.B. gibt es bei mir nicht; wenn keine Antwort kommt, dass die Lose zurück sollen, gehen diese auch nicht zurück).

Zitat von ice-breaker

und dies auch zur 1. Option machen

Ich habe immer noch ein Problem damit, dass zu viele Lose wahrscheinlich im Tresor liegen werden und diese werden bei der 1. Option mit beachtet, daher hatte ich diese auch als 1. Option da gelassen.

Zitat von ice-breaker

wer liest denn noch weiter, nachdem man ihm bei Option 1 sagt er soll sein EF-Passwort hergeben ...

Hm.. dafür steht da dick 'Alternative'? ^^


Aber wie hast du das mit den Tresorlosen vor? Wie kannst du die da mit einbeziehen? Aus dem Tresor kann man ja über die EF-API nichts entnehmen, nur Lose in den Tresor packen (wäre das anders würde der Tresor auch den Sinn verfehlen).
Die können doch nur manuell, also wenn der User sich auf ef.klamm.de einloggt usw, auf einen klamm-Account transferiert werden.


EDIT: ice-breaker, ich sitze gerade an der RSA Verschlüsslung und baue sonst noch ein paar Ideen mit in das EF-Script ein (die von jqry z.T.).
Was ich gefunden habe an RSA-Implementation für PHP ist die Klasse von www.torsten-keil.net; die PEAR-Implementation sieht finde ich nicht so schön aus der Beschreibung nach.

[ice-breaker]

Zitat von chrissel

Sollte doch so sein wie dein Ansatz? Nur, dass deiner im allgemeinen sicherlich schöner ausgearbeitet ist (gerade das mit den 30sec z.B. gibt es bei mir nicht; wenn keine Antwort kommt, dass die Lose zurück sollen, gehen diese auch nicht zurück).

ja dann schon

Zitat von chrissel

Ich habe immer noch ein Problem damit, dass zu viele Lose wahrscheinlich im Tresor liegen werden und diese werden bei der 1. Option mit beachtet, daher hatte ich diese auch als 1. Option da gelassen.

besser als wenn nur 1 EF teilnimmt oder?
Wenn du die Variante noch ausbaust und es kostenlos als FWX und VMS Plugin bereitstellst, finden sich bestimmt noch einige mehr die da mitmachen würden.

Zitat von chrissel

Aber wie hast du das mit den Tresorlosen vor? Wie kannst du die da mit einbeziehen? Aus dem Tresor kann man ja über die EF-API nichts entnehmen, nur Lose in den Tresor packen (wäre das anders würde der Tresor auch den Sinn verfehlen).
Die können doch nur manuell, also wenn der User sich auf ef.klamm.de einloggt usw, auf einen klamm-Account transferiert werden.

ich hab schon ewig nimmer mit dem EF gearbeitet, wenn das nicht geht, dann ignorier es

Zitat von chrissel

EDIT: ice-breaker, ich sitze gerade an der RSA Verschlüsslung und baue sonst noch ein paar Ideen mit in das EF-Script ein (die von jqry z.T.).
Was ich gefunden habe an RSA-Implementation für PHP ist die Klasse von www.torsten-keil.net; die PEAR-Implementation sieht finde ich nicht so schön aus der Beschreibung nach.

nimm die Variante, die am sichersten ist, also folgende Bedingung erfüllt:

• Sie kann RSA-Zertifikate laden (sehr wichtig !!! die Schlüsselerzeugung ist sehr komplex, mach das mit einem Linux)
• sie verschlüselt sicher (sichere Blockchiffre)

Ich würde ja zu Zend_Crypt_RSA raten, ich hab mir die Implementation noch nicht angesehen, aber da haben denke ich viele drübergeschaut.

Edit: Zend_Crypt_RSA benötigt OpenSSL, Torsen Keils Implementierung hingegen nicht (erfüllt aber auch nicht alle Sicherheitseigenschaften) und die Pear-Implementierung kann gar nicht verschlüsseln, bleibt dir also nur die Implementierung von Keil-Implementierung

[jgry]

noch ein kleiner Hinweis zur Idee mit dem Hin und Herschieben der Lose.
Hier ist eine Auswertung um 0 Uhr eher ungünstig, um 0:10 werden einige den Dauerauftrag zur Sicherung der Lose in den Tresor aktiv haben. Daher kann es dort zu unschönen konflikten kommen, wenn die Buchungen etwas verzögert ablaufen und dann nicht zurückgebucht werden kann.

Ich weiß nicht ob du auch schon dran gedacht hast, aber es sollten auch nur die Lose zurück Übertragen werden, die auch vorher auf dem Klamm Account vorhanden waren, nicht das jemand zur Zeit der Zählung auf dem Klamm Account Lose offen liegen hat, und die dann nach der Zählung ebenfalls auf den EF geflossen sind.

[Mano1805]

Die genannte Alternative mag schön und gut sein, aber ich HOFFE das die meisten Lose tatsächlich im EF-Tresor rumliegen und dann wird es schlicht und ergreifend schon nix mehr.
Die Seitenbetreiber mit denen ich im Kontakt bin, als auch ich selbst haben zumindest die meisten Lose einfach im Tresor und nur einen gewissen, meist sehr kleinen Teil, für Auszahlungen frei rumliegen.

[chrissel]

Zitat von ice-breaker

besser als wenn nur 1 EF teilnimmt oder?
Wenn du die Variante noch ausbaust und es kostenlos als FWX und VMS Plugin bereitstellst, finden sich bestimmt noch einige mehr die da mitmachen würden.

Die Idee mit dem Plugin hört sich gut an.
Muss ich mal schauen, ob sich so etwas einrichten lässt. Habe lange nichts mehr mit FWX und VMS gemacht.

Zitat von ice-breaker

bleibt dir also nur die Implementierung von Keil-Implementierung

Diese habe ich auch soeben eingebaut. In meiner Testumgebung hat alles funktioniert, ich hoffe bei der nächsten Zählung gibt es damit keine Komplikationen.
Zusätzlich habe ich ein kleines Installationsscript geschrieben, welches die EF-Daten direkt verschlüsselt in die Konfigurationsdatei speichert. Der Speicherort dieser Datei kann auch freigewählt werden.

Zitat von jgry

noch ein kleiner Hinweis zur Idee mit dem Hin und Herschieben der Lose.
Hier ist eine Auswertung um 0 Uhr eher ungünstig, um 0:10 werden einige den Dauerauftrag zur Sicherung der Lose in den Tresor aktiv haben. Daher kann es dort zu unschönen konflikten kommen, wenn die Buchungen etwas verzögert ablaufen und dann nicht zurückgebucht werden kann.

Puh, stimmt. So etwas gibt es ja auch noch. Ich schau mir das noch genauer an und verschiebe ggf. die Zählung um ein paar Minuten.

Zitat von jgry

Ich weiß nicht ob du auch schon dran gedacht hast, aber es sollten auch nur die Lose zurück Übertragen werden, die auch vorher auf dem Klamm Account vorhanden waren, nicht das jemand zur Zeit der Zählung auf dem Klamm Account Lose offen liegen hat, und die dann nach der Zählung ebenfalls auf den EF geflossen sind.

Es gibt eine 'temp'-Datei bei dieser Methode in welcher der Losestand des EF-Accounts gespeichert wird. Somit werden auch nur die Lose zurück gebucht, die vorher auf dem EF waren.

[ice-breaker]

Zitat von chrissel

Puh, stimmt. So etwas gibt es ja auch noch. Ich schau mir das noch genauer an und verschiebe ggf. die Zählung um ein paar Minuten.

nicht nur um ein paar Minuten, es wäre generell am sinnvollsten wenn du alle Ausleseoperationen auf einen Zeitpunkt verschiebst, an dem möglichst wenig Aktivität herrscht, so dass z.B. Transaktionen die sich mit deinem Script bei Nutzern überschneiden zu keiner Doppel-Zählung führen.
Um 3 Uhr morgens ist da das perfekte Zeitfenster