Forum

Das große Problem ist ja meiner Meinung nach das jeder Webmaster ein anderes AVS-System bevorzugt bzw. mehrere anbieten möchte.

Es geht ja im Prinzip nur darum Medien (Bilder oder Videos) vor einem Direktverlinken zu schützen.

Jeder Webmaster müsste also beim Anlegen einer Benutzergruppe z. B. *ab18* die Option haben *Backdoorschutz* oder nennt es wie ihr wollt.

Nun müsste es nur noch einen Automatismus geben mit der ein User die Benutzergruppe erlangen kann. Entweder per Hand (bei kleinen Communitys). Oder eben durch ein AVS-Tor. Welchen Anbieter der Webmaster dann wählt ist sein Problem, er haftet ja auch dafür.

Man könnte das AVS-Tor auch bereits bei der Registrierung einbinden. Würde bedeuten, man schaltet nach dem Registrierungsformular noch eine Seite für ein x-beliebiges AVS-Tor.

Dies könnte man ja als Option bei der Registrierung einbauen. Entweder normal oder Registrierung + Jugendschutz.

Die geschützte Benutzergruppe ist aber Voraussetzung.

Keine Ahnung ob das sinnvoll ist, sind nur meine Gedanken.

[ Diese Nachricht wurde bearbeitet von: darksweetys am 16.01.2008 21:15 (Originaldatum 16.01.2008 19:10) ]

Hmm. Hab mal wie in der Email angeraten den accessManager vom Server gelöscht.
Eine Anypage-Seite (sichtbar nur für user) mit dem Tor.
Bei X-Check eine 2. Anypage-Seite (ebenfalls nur für User) als Ziel url angegeben.

So, wenn ich jetzt durch das Tor gehe (also "seite betreten" anklicke) dann geht es über X-Check zur 2. Anypage Seite.

Wenn ich mir die Formdetails der 1. Anypage Seite (mit dem Tor) ansehe:


     formid488041182     post     http://testwiese.ist-crazy.de/system/search/index.php

Elements
Index     Id     Name     Type     Value     Label     Size     Maximum Length     State
0     text-id-1113028022     query     text               14          
1          s     submit                         
2               image                         
3               image                         
Form
Id     Name     Method     Action
     xcGoThrough     post     http://security.personalid.de/loginCheck.php?PID_projectID=452&PID_SESSION=f5bb1fb0e94ac34eb5830f9cf4084d85&PHPSESSID=18b7d5ac5c610a759f4319109987245b008050016172&newPersonalID=1

Elements
Index     Id     Name     Type     Value     Label     Size     Maximum Length     State
0               image                         
1               image                         
Form
Id     Name     Method     Action
     smartGoThrough     post     http://www.x-check.de/goThroughSmartPay.php?PHPSESSID=18b7d5ac5c610a759f4319109987245b008050016172

     

und dann die 1. anypage seite aktualisiere und noch einmal die Formdetails ansehe, stelle ich fest, daß sich die PHPSESSID ändert:



xcGoThrough     post     http://security.personalid.de/loginCheck.php?PID_projectID=452&PID_SESSION=324c09ef4bc5747f3e217a5a63f25c4d&PHPSESSID=4959006d406d791d2188880e3f0ea2fe008050016172&newPersonalID=1

Weiß nicht ob das von relevanz ist, aber erwähnen wollte ich es auf jedenfall einmal.

Also nun "seite betreten" angeklickt. Werde nun weitergeleitet zur 2. Anypage-Seite.
Oben in der Adresszeile des Browsers steht:

http://testwiese.ist-crazy.de/system/anypage/index.php?opnparams=CGgPO1BoAWM&xcKey=d7c2c5aff2e1e94a18fdede92c1a03c4&p1=1&p2=2

Die Parameter p1=1 und p2=2 habe ich (wie von dem Herrn von X-Check beschrieben) in das script der Torseite (1. Anypage Seite) mit angefügt.

Wenn man nun anstatt p1=1 usw . die opn userid und einen zufällig von OPN erzeugten code anfügt, diese Daten mit durch das X-Check Tor schickt. Nach dem Tor landet der User auf der 2. Anypage Seite, wo dann die Userid und der zufällig erzeugte Code gegengeprüft werden.

Das müßte doch sicher sein, oder?

1.
Die User können auf die beiden Anypage Seiten nur zugreifen, wenn sie eingeloggt sind.

2.
Eingeloggte User, die die Ziel url (2. Anypage Seite) kennen sollten, können damit ja auch nichts anfangen, da sie
a.) ihre eigene userid von opn kennen müßten
b.) den zufallscode nicht kennen

3.
bei Ankunft an aypage seite 2 wird der vorher erzeugte zufallscode mit dem übertragenen zufallscode verglichen

4.
man kann die gesendete userid mit der userid des eingeloggten users nochmals vergleichen

5.
vielleicht kann man ja auch mit dem übertragenen xckey (xcKey=d7c2c5aff2e1e94a18fdede92c1a03c4) auch noch was anfangen.



Gruß Luke

Luke auch wenn die mail recht kurz (inhaltlich ist) ich she da nicht ganz das problem opn an sich zu schützen sondern eher eben auch sicherzustellen das der wirklich über 18 ist.

der weg bei x-check wäre nicht sicher man könnte (ohne das jetzt getest zu haben) zwar sicherstellen das eben user a user a ist aber nicht!!! das dieser über x-check kamm. hier wird nur mit einem cookie gearbeitet und der ist nicht mal codiert von daher ist das nicht sicher das er wirklich über x-check kamm.

Hallo!

jetzt versteht er es aber hat ein problem

Ja und nein. Ja, ich habs verstanden, und nein, vielleicht gibt es doch ne Lösung (ich schreibe Dir dazu eine Mail).

---

Über18 usw. alles schön und gut. Das was mich am meisten an der Sache stört ist, daß es für den User immer Geld kostet. Nicht nur einmalig, sondern laufende Kosten (jährlich bei anderen monatlich).

Deswegen bin ich mehr für X-Check.
Wäre natürlich schön, wenn man noch andere Anbieter zusätzlich mit ins Boot nehmen könnte, für die User, die schon bei ueber18.de und co. Mitglied sind.

Im Prinzip ist OPN ja schon ein guter Backdoor-schutz. Mit den benutzergruppen kann man ja wunderbar steuern, welcher User was sehen darf und was nicht, es sei denn ein User bekommt einen Direktlink zu einem FSK18 Medium aus der MG. Aber vielleicht gibt es dafür auch eine Lösung, die ich noch nicht kenne. Dann braucht man keinen Backdoorschutz von Drittanbietern mehr. Dann kann OPN das alleine. Es geht dann nur noch um die zuverlässige Altersverifizierung des einzelnen Users. Da gilt es dann die besten/sichersten Anbieter/AVS-Tore heraus zu finden.


Gruß Luke

Also ich muss mich da mal einmischen, da mich das Thema auch interessiert.

Und zwar gibt es ja nun verschiedene div. AVS-Anbieter. Unter anderem das Über18. Mit dem haben sich schon einige Gerichte herumgeschlagen und es wird anerkannt. Das ist aber Nebensache.

Es funktioniert ähnlich wie X-Check. Nur mit einem kleinen Unterschied. Deren Backdoorschutz ist so gestaltet das er mit mehreren anderen AVS-Systemen funktioniert.

Wie das im Detail aussieht entzieht sich meinem Verständiss da da mein Weissen einfach zu begrenzt ist *fg*

Sollte aber Interesse zum Test bestehen geb ich meinen Account gerne fürs Entwicklerteam frei.

Grüße andré

jetzt versteht er es aber hat ein problem

Hmm, verstehe ich nicht

ich möchte nicht ins detail gehen aber das schutzsystem ist geliende gesagt ein witz.

[url entfernt aus sicherheitsgründen]

geht prroblemlos bei mir

öhm Luke ganz erlich das teil ist mehr wie unsicher damit meine ich nicht mal den php code

Du bist soeben durch das X-Check Tor gegangen

bin ich aber nicht
bin da nicht mal mitglied hab auch keinen accout
bin auch nicht bei dir auf der seite angemeldet

der sheck ist nicht wirklich sinnvoll? rein codetechnisch its da nicht wirklich ne problem bei aber das ganze ist nur unsicher und würde ich nicht als standard in opn übernehmen wollen.

gibt es nichts anderes? wie gesagt das micropayment ist "eigentlich" sicher. von daher es geht nur der anbieter ist was fürn eimer

wie gesagt das zu umgehen dauerte jetzt keine 2 min

Ich hatte die htacces noch mal kurz deaktiviert um was zu probieren. Jetzt ist sie wieder scharf.

Hast Du einfach nur die Ziel Url aufgerufen oder noch was anderes gemacht?

Versuchs doch jetzt nochmal.

Gruß Luke