ExportForce verbesserungsvorschlag

[chrissel]

ich möchte auch mal was vorschlagen...
ich würde es gut finden wenn man per EF das losepasswort auslesen kann, natürlich wird das passwort dann verschlüsselt sein(verschlüsslung sollte bekannt sein)
wenn nämlich sich jemand anmeldet und man nen accountcheck per EF macht kostet das ja anfragen, wenn der user jetzt andauernd ein falsches losepasswort z.b. eingibt kostet das ein haufen anfragen. könnte man das verschlüsselte losepasswort auslesen dann muss man nur einmal das LP auslesen und dann andauernd vergleichen!
ich weiß zwar nicht ob andere klammuser dieses bräuchten, aber mich würds freuen wenn es sowas geben würde

PS: macht mal bitte wieder im forum ne ExportForce kategorie! (oda habe ich sie übersehen)

 

[Mone]

Bist du sicher, dass du das EF-Prinzip verstanden hast ?

 

[birdman01]

noch was: Es heißt ExportForce. Es kommt vom exportieren

 

[chrissel]

öhm, nö^^
ich zahle damit nur lose aus oder ziehe welche ein
userchecks mache ich auch

edit: habe is in ExportForce umgeändert, thx birdman01 für den hinweis

 

[Mone]

Das Losepasswort ist dafür da, dass Lose nur abgenbucht werden, wenn das richtige Passwort bei der EF-Abfrage mitgeschickt wird. Wenn das Losepasswort per EF geholt werden kann, ist das ziemlich unsinnig.

Abgesehen davon, dass ein User das Losepasswort ändern kann (und auch oft tun sollte).

 

[chrissel]

stimmt, also wird das wohl nix
auch nicht schlimm

 

[Aradiv]

Ich hätte dembezüglich trotzdem eine Idee.

Der md5hash des Passworts wird auslesbar gemacht. mithilfe des md5 hash würde sich dann auf der Seite eine abfrage realisieren lassen die überprüft ob das Passwort stimmt und das mit nur einer Abfrage.
Das Sbgehohlte Passwort wird dann in einer Sessionvariablen gespeichert.

Momentan ist es theoretisch möglich 10.000 mal zu versuchen sich anzumeleden. Dabei wird das Losepasswort abgefragt, die Abfrage ergibt das das Passwort nicht stimmt und das ganze geht von vorne los. So lange bis der Betreiber keine EF-Anfragen mehr hat.

Wie ihr seht wäre das ganze auch eine Art Verbraucherschutz


Zur erklärung für alle unwissenden md5 ist eine nichtzurückrechenbare Verschlüsselungsvariante. Also selbst wenn jemand den md5hash eures Passworts haben sollte so ist er immernochnicht im Besitz eures Passwort.

hier mal ein Beispiel für md5.

7fc56270e7a70fa81a5935b72eacbe29 - A
515322af1eb924f2a4cee609d1f39bfa -- Au
63f77af3d2986c3112cd081049efcc50 -- Aut
06b9281e396db002010bde1de57262eb - Auto
8b1f1e8c6f406c3a224d03498e7f45a9 -- Autob
8c449959572d7b688ba2ad9f4d00b517 - Autoba
b735091543b3873bb24f607e1e5f5329 -- Autobah
a1082e570aada77666085196f13818f6 -- Autobahn

und wer mir nicht glaubt das es mit dem md5hash nahezu unmöglich ist das passwort herauszufinden der kann sich ja mal hierdran versuchen

a191567c739bcd6d444544af31083c74

mfg
Aradiv

 

[Mone]

Der md5hash des Passworts wird auslesbar gemacht. mithilfe des md5 hash würde sich dann auf der Seite eine abfrage realisieren lassen die überprüft ob das Passwort stimmt und das mit nur einer Abfrage.

Versteh ich nicht.

Es gibt
validate.php 1 Abfrage, um zu prüfen, ob ein Losepasswort stimmt
saldo.php 1 Abfrage, ob das Losepasswort stimmt und wie der Losestand ist
get.php 1 Abfrage, ob das Losepasswort stimmt und gleichzeitig Einziehen von Losen
send.php 1 Abfrage, ob das Losepasswort stimmt und Lose verschicken

Also was willst du denn noch?

Das Sbgehohlte Passwort wird dann in einer Sessionvariablen gespeichert.

Und wenn der User zwischendurch das Losepasswort ändert, wird das nicht bemerkt. Das wäre eine große Sicherheitslücke.

 

[Bububoomt]

und wer mir nicht glaubt das es mit dem md5hash nahezu unmöglich ist das passwort herauszufinden der kann sich ja mal hierdran versuchen

a191567c739bcd6d444544af31083c74

mfg
Aradiv

Genau an dem fettgedruckten ist der Springende Punkt.

nahzu unmöglich heißt nicht unmöglich!!!

Es gibt schon viele Hastabellen, wo man nach dem passenden Wort des Hashes suchen kann


*edit*

Versteh ich nicht.

Nun er spielt darauf an, das ein User/Faker dem Webmaster schaden kann indem er immer wieder fehlerhafte anfragen macht. Kostet ja dann eine Ef-abfrage. (Andere Seiten haben es so das nur korrekte anfragen bezahlt werden müssen)


Müßte der Webmaster halt eine IPsperre, Maximal Versuche einstellen...
Oder halt eine Gebühr bei x fehlern nehmen...

 

[theHacker]

Müßte der Webmaster halt eine IPsperre, Maximal Versuche einstellen...
Oder halt eine Gebühr bei x fehlern nehmen...

Aber da sind die Webmaster zu faul dazu und wollen lieber klamm die Drecksarbeit machen lassen

 

[Bububoomt]

Ja ich habs auch noch nicht drin, aber beschwere mcih net. bin am überlegen wie ich das umsetze, also ob ich ne Gebühr nehme, wenn man zum xten male das PW falsch eingegeben hat...

 

[theHacker]

bin am überlegen wie ich das umsetze, also ob ich ne Gebühr nehme, wenn man zum xten male das PW falsch eingegeben hat...

Is quatsch
Wenn ich dir Stress machen will, POST ich dir das Anmeldeformular, wo sicherlich auch nach dem Lose-PW gefragt wird, im Sekundentakt.

Effektiv is nur n IP-basierender Flood-Schutz. Der Rest is User-Abzocke.

 

[Bububoomt]

Ja nee, ich würde ja ne IP-Sperre drin haben.

Also meine Idee:

Ip xyz versucht es zum 5 mal
x minuten sperre
dannach das selbe
xy sperre
beim dreitten *5 Versuche komplette sprerre bis user sich meldet etc....


User versucht es mit der IP xyz 5 mal und dann klappt es, hier meine Überlegung
Ziehe ich ihm eine Gebühr für dummheit ab!?


Ich sehe es nicht ein, das ich 5 Abfragen zahle, weil der Uer zu blöd ist sein PW einzugeben, bzw der Uer sein nick eingibt und nicht die Klamm-iD, obwohl es dort extra steht, auch bei der Fehlermeldung...

Meinst das ist User abzocke??
Und das ist nciht die seltenheit, vorallem kriege ich immer wieder mails,

"das geht nicht, bekomme die und die meldung..."

Komisch das hunderte andere es schaffen...

 

[theHacker]

beim dreitten *5 Versuche komplette sprerre bis user sich meldet etc....

Das is klasse. Ich kann ohne mich überhaupt anzumelden, beliebige User auf deiner Seite sperren:
Ich tu einfach 3x (neue IP holen und danach 5x Formular abschicken) und schon is der User gesperrt. Klasse, das wird ein Spaß

 

[tleilax]

Nur mal so am Rande:

Wieso wollt Ihr die Sperre IP-basiert machen? Ich würde das Account-bezogen machen. User gibt das Passwort 3x falsch ein und sein Account wird für Logins für 15 Minuten gesperrt. Gibt er danach sein Passwort wieder einmal falsch ein, wird der Account für 30 Minuten gesperrt und so weiter. Ist einfach umzusetzen und recht effektiv. So umgeht man zuviele Abfragen und Bruteforce-Versuche.

Wenn's nur darum geht, zu verhindern, dass ein User zuviele EF-Abfragen verbraucht oder diese gar mutwillig dezimieren will, kann man eh nicht nur beim Login Sicherheitsmassnahmen einbringen. Ich könnte mich ja beispielsweise auch per Skript einloggen und dann x Mal pro Sekunde versuchen lassen, 100 Lose einzuzahlen, obwohl mein Klammaccount Lose-technisch leer ist.

@Aradiv:

1. Ist md5 keine Verschlüsselungsmethode. Was man verschlüsselt, sollte man auch immer wieder entschlüsseln können. md5 ist ein Hashverfahren, was mit Verschlüsseln quasi gar nix zu tun hat.
2. Das Auslesen des Losepassworthashes über die EF-API wäre ein Riesensicherheitsrisiko. Ich könnte mir zu allen IDs die Hashes ausgeben lassen, dazu bekomme ich über die API auch ohne Losepasswort den Nickname des Users und - et voila - hab ich für knapp 200k User schon einen grossen Teil interessanter Daten. Geht man nun her und hat 'ne DB mit schön vielen, aussagekräftigen Klartext/MD5-Tupeln, krieg ich grob geschätzt für mindestens 1/6 der User gültige Nickname/Passwort-Kombinationen, die man entweder direkt auf klamm für den Login verwenden könnte oder man probiert's bei ebay oder sonstwo. Ich an Lukas' Stelle würde sowas nicht machen...

 

[Bububoomt]

Natürlich muß es auch eine KID-Sperre geben eine KID-Sperre würde ja nicht langen, weil sonst würd eman über die ip erstmal kid x versuchen, dann kid y....

Also eine IP, Kid sperre, die getrennt von einander aber kombiniert funktioniert.
Ihr wisst wie ich das meine oder!?

Alos das sowohl geguckt wird bei der ip adresse wieviel fehlversuche als auch bei der kid...
Bsp

IP x 3 fheler, ip z 2 fehler jeweils kid 1 =>sperre
ip 5*fehler aber 1. id 2 2. id3 3.5 id 5 =>sperre

 

[Bububoomt]

Das is klasse. Ich kann ohne mich überhaupt anzumelden, beliebige User auf deiner Seite sperren:
Ich tu einfach 3x (neue IP holen und danach 5x Formular abschicken) und schon is der User gesperrt. Klasse, das wird ein Spaß

Tjo und wenn ich dann di IP weiter gebe an die staatsanwaltschaft!?!?

Außerdem kann man ja weiteren schutz einbauen, muß man denn alles vorher verraten??

 

[theHacker]

Tjo und wenn ich dann di IP weiter gebe an die staatsanwaltschaft!?!?

Ja klar. Die fragt dich dann erstmal, ob du noch ganz sauber bist
Ich begehe doch keine Straftat, wenn ich 15 HTTP-Requests an deine Seite schicke und du daraufhin einfach einen User sperrst

 

[Bububoomt]

Es hörte sich ja eben nach 1500 an und net nach 15...

Und was heißt hier sperren?? Wir haben doch hier von loginsperre für xx Zeot gesprochen... Ist ein kleiner aber feiner unterschied.

So ich verabschiede mich shcon mal in nen kleinen Urlaub...

 

[Anguished]

Naja, einen perfekten Schutz gibt es nicht.

-Vorhin hat einer vorgeschlagen, den MD5-Hash nur ein mal abzurufen, und den dann in einer Session zu speichern und damit zu vergleichen. Mir sind bisher nur Session-Implementierungen bekannt, die die momentane Session anhand
* eines Cookies
* eines GET-Parameters o.ä. oder auch
* der IP
identifizieren. Ein böswilliger User könnte jetzt die Anfrage einfach per Hand (oder einem Script) an den Server POSTen, dabei keine Cookies mitgeben und auch keine Sessionid-Parameter. PHP-Sessions zum Beispiel würden sich dadurch IMHO jedes mal neu anlegen, und damit auch jedes mal den Hash abrufen.

-Eine IP-Sperre ist, besonders hier in Deutschland, auch nicht besonders effektiv. Wer es böse meint trennt eben die Verbindung nach jedem Versuch. Zur Not lässt sich das auch in ein Spam-Script einbauen (ich weiß nicht, ob Provider da eine Sperre vorschieben?).


Als Kompromiss, der mit momentanen EF-Mitteln möglich ist, wäre vielleicht eine Sperre nach KlammId, IP, und mit größerer "Kapazität" auch nach IP-Subnetz, alle drei unabhängig voneinander, denkbar. Alle Sperren natürlich nur temporär. Wenn einer gar keine Ruhe gibt, kann man ja die IPs von ihm verfolgen und entweder komplett sperren, oder nach dem ersten Fehlversuch direkt für 10 Stunden.

Und als absolute Notfallmaßnahme das komplette Deaktivieren der Registrierung (oder wo auch immer das Authing gebraucht wird) bei starkem Spam, wenn man die Felle davonschwimmen sieht. So ab 60 Anfragen pro Minute aufwärts, wenn das bei der Seite eher auf 0.1 Registrierungen pro Minute hinauslaufen sollte.

Aber man kann es auch übertreiben. Sobald dann ein Useraccount angelegt ist, kann man die Sperre einfach Account-Based anlegen, das macht dann keine Probleme mehr, da kann der so oft IP und Sessions wechseln, wie er lustig ist.