IP's hashen? about yform_spam_protection HOT 13 CLOSED

Hab nachgefragt, seiner fachlichen Einschätzung nach passt das. Ich meine, ich hätte das bei Erstellung auch schon Mal abgeklärt.

from yform_spam_protection.

Sollte eigentlich passieren, scheinbar aktuell nur im Debug-Modus. Ich bin mir nicht sicher, ob #52 das zufriedenstellend löst, aber du kannst es mal ausprobieren - einfach die entsprechenden Zeilen bei dir ändern.

Hashen wäre möglich, sehe ich aber nicht als erforderlich an, wenn die Datensätze ohnehin wieder gelöscht werden und finde es auch praktischer, falls man bspw. die IP über den Server dauerhaft blocken will.

from yform_spam_protection.

Danke für die Antwort @alxndr-w
Du hast natürlich recht, wenn denn die Einträge gelöscht werden.
Ich werde den Code dann anpassen. Danke für den PR.

from yform_spam_protection.

Ich mache hier noch mal auf, da die Diskussion noch mal aufkam.

Im Addon heißt es: DSGVO-konform – sofern keine Konfiguration mit externen Anbietern gewählt wird.
Das kann ich nicht einschätzen, aber eventuell ist das nicht korrekt.

Dazu: https://skymonitor.com/why-hash-dont-anonimize-an-ip-address-and-what-this-affects-gdpr/

from yform_spam_protection.

Die meines Wissens beste Lösung wäre ein sha256-Hash mit Salt.

IPs für einen kurzen Zeitpunkt zu speichern, um Spam zu verhindern, sehe ich als technisch notwendig an, ähnlich wie logfiles.

from yform_spam_protection.

Vielleicht wäre das eine bessere Lösung.
Letztlich muss das ein Gericht im einzelfall entscheiden, aber man hätte wenigstens ein bisschen was dagegen unternommen.
Den Salt könnte man, ähnlich wie WP das macht, in die config.yml schreiben?

from yform_spam_protection.

Ich bin nicht mehr so tief im Thema, REDAXO hat ja eine Hashing-Methode für Passwörter, die aber korrekterweise immer unterschiedliche Hashs erzeugt.

In einer von mir für später geplanten Version, die ich nicht mehr aktiv verfolge, wäre ein Ablaufdatum für die IP vorgesehen gewesen, sodass man schon beim Aufruf der boot.php kontinuierlich IPs löscht und nicht nur beim Aufruf des passenden Values. Das wäre natürlich nochmal eine Verbesserung, Optimierungsmöglichkeiten gibt. Es war sogar so gedacht, dass das Ablaufdatum weiter in die Ferne rückt, je öfter der Bot es danach nochmal versucht. (z.B. statt 1h Sperre 24h Sperre dann 7 Tage) oder wieder reduziert wird, wenn es sich um einen Nutzer handelt, der sich weiter auf der Seite bewegt.

Alles in allem bleiben die Daten auf dem eigenen Server, was eine wesentliche Verbesserung ist im Zweifel zu externen Lösungen ist. Denn da fallen sie eh schon an und werden nur lokal ausgewertet.

from yform_spam_protection.

Ich bin nicht mehr so tief im Thema, REDAXO hat ja eine Hashing-Methode für Passwörter, die aber korrekterweise immer unterschiedliche Hashs erzeugt.

Nun gut, vergleichen kann mann diese schon. Man müsste im schlechtesten Fall über alle Einträge iterieren.
Bis eine neue Version kommt, könnte man das vielleicht erst mal so lösen.

from yform_spam_protection.

@eaCe wenn es dir ein wichtiges Anliegen ist, lass es doch mal über einen Anwalt deines Vertrauens klären.

from yform_spam_protection.

@alxndr-w ich vertraue keinen Anwälten :) Nein Spaß beiseite, ich kenne keinen in diesem Bereich. Dennoch, wenn mein Vorschlag für dich in Ordnung wäre, werfe ich einen PR mit der passwordHash Funktion rein.

from yform_spam_protection.

@eaCe soweit ich weiß ist "Security by Obscurity" ein Anti-Pattern, weil es ja keine Verbesserung bewirkt. Und ich bin mir gerade nicht sicher, ob wir nicht genau diesen Weg verfolgen. (Kommt aber auf die Methode an)

Ich kann auch nicht abschätzen, wie die Performance bei vielen Seitenbesuchen aussieht, wenn in einem Szenario einer gut besuchten Website 10.000 Hashs zur Laufzeit miteinander verglichen werden müssen.

Mir ist es im Endeffekt egal, ich bin ja auch nicht mehr Lead dieses Addons. Mir wäre nur daran gelegen, dass eine Änderung zu Ende gedacht ist, ein tatsächliches Problem löst und das so elegant löst, dass es keine neuen Probleme schafft, weshalb ich mich da so einmische.

Ich werde den Anwalt meines Vertrauens konsultieren und der wird mir eine nicht bindende aber für mich ausreichende Einschätzung mitteilen können.

(Abgesehen davon sehe ich, dass ganz viele WordPress-Addons das machen, die für sich genommen auch mit DSGVO-Kompatibilität werben, solange halt auch sichergestellt ist, dass die Aufzeichnung nur temporär ist. Dazu habe ich ja auch die Tabelle schon mal so angelegt, dass diese nicht in automatischen Backups landet)

from yform_spam_protection.

@alxndr-w bei einem Password Hash würde ich nicht von Obscurity sprechen. Das sollte schon etwas sicherer sein.
Wie gesagt, ich habe keinen Schimmer. Fühlt sich einfach etwas besser an.
Aber auch mir ist es egal, ich kann das für den einen Kunden für den ich das Addon nutze selbst anpassen.

Du kannst ja mal nachfragen, wenn dir dadurch keine Kosten entstehen.

Das die Adressen nur zeitweise gespeichert werden ist nun richtig, aber eben in allen Versionen vorher nicht :)

Dann mache ich hier wieder zu, falls jemand anders ähnliche Bedenken haben kann man ja wieder öffnen

from yform_spam_protection.

@alxndr-w danke für die Mühe

from yform_spam_protection.