Optionale EF Passwortübergabe per md5() (&md5=1) ?

[mbassus]

Ahoy,..

da ich selbst für mehrere große Seiten Programmiere und somit eigentlich zugriff auf mehrere Milliarden Lose habe, kam mir folgende Idee...

Wenn man einmal als Programmierer Zugriff auf einen Skript hat, hat man theoretisch auch Zugriff auf die darauf befindlichen Lose vom EF. Nun, es gibt viele Skriptkiddies, die hier und da mal was machen wollen, sich den Skript ziehen.. und dann nichts tun.

Da es ja bekannt ist.. das viele Leute Universalpasswörter haben, können wir der doofheit wieder ein stück entgegentreten, indem man das EF Passwort einfach per MD5 übergibt und optional noch den Parameter md5=1 an die URL mit dranhängt.

Den genutzten EF kann man damit natürlich nicht schützen, aber vielleicht viele andere Accounts des eigentlichen User´s.

Liebe Grüße,
Martin.

 

[27o8]

Den genutzten EF kann man damit natürlich nicht schützen, aber vielleicht viele andere Accounts des eigentlichen User´s.

Wenn ein User überall das gleiche PW hat, ist er selbst dran schuld, dann hätte er auch im FTP oder wo das "Scriptkiddie" dran ist, auch das gleiche PW und somit wäre es ja dann schon wieder überflüssig.

Btw: md5 ist auch nicht sicher...

Gruß
Gremlin

 

[tedlemegba]

Zwei weitere Gegenargumente:
- Rainbow Tables (außer es gibt Salz in die Suppe)
- md5-Passwörter auf von Skriptkiddies administrierten Loseseiten, etc. (Missbrauch)

 

[tjark]

md5(md5($pass));

 

[tedlemegba]

md5(md5($pass));

Joa.. glücklicherweise bringt das genauso wenig, wenn nicht noch weniger.
Und die Anzahl an Möglichkeiten fällt auf geht auf 3,4e+38 zurück. (Edit: okay, moment... kann sein, dass das meinerseits keinen Sinn ergibt. )

 

[27o8]

Naja die doppelte "verschlüsselung" bringt schon was aber nicht viel, man kann immer noch an das pw kommen, dauert halt etwas länger als wenn man z.B. nur ein 6 stelliges pw oder so hat

 

[tedlemegba]

Naja die doppelte "verschlüsselung" bringt schon was aber nicht viel, man kann immer noch an das pw kommen, dauert halt etwas länger als wenn man z.B. nur ein 6 stelliges pw oder so hat

Das tolle ist halt, dass man das Passwort ja gar nicht mehr braucht und das Ergebnis von md5 beschränkt sich eben auf [0-9a-f]{32}.

 

[tleilax]

Öhrm, [0-9a-f]{32} trifft immer noch auf 16^32 verschiedene Strings zu. Wenn das jemand bruteforcen will, können wir alle mit 'ner fetten Startseitenvergütungserhöhung rechnen. Dazu wären im Worst-Case nämlich immerhin 6.805.647.338.418.769.269.267.492.148.635.364 EF-Accounts à 50k Abfragen zu je 5€ nötig. Die restliche Mathematik überlasse ich dem geneigten Leser...

Zum eigentlichen Vorschlag:

Irgendwie bin ich dagegen. Wer auf seine Passwörter nicht aufpasst, sollte keine besondere Behandlung erfahren und darf meinetwegen gern auf die Schnauze fallen. Dann lernt er vielleicht wenigstens draus...

 

[scriper]

Irgendwie bin ich dagegen. Wer auf seine Passwörter nicht aufpasst, sollte keine besondere Behandlung erfahren und darf meinetwegen gern auf die Schnauze fallen. Dann lernt er vielleicht wenigstens draus...

mhm, dass kann man jetzt so und so sehen.

Immerhin könnte man dann die Mehrbelastung der Admins durch "zurückholen der Lose" minimieren - vorausgesetzt man sagt den Usern dann auch mal "Pech gehabt - selbst schuld" und macht es als Admin nicht zB. aus Kulanz doch...

 

[Icy]

mhm, dass kann man jetzt so und so sehen.

Immerhin könnte man dann die Mehrbelastung der Admins durch "zurückholen der Lose" minimieren - vorausgesetzt man sagt den Usern dann auch mal "Pech gehabt - selbst schuld" und macht es als Admin nicht zB. aus Kulanz doch...

Was minimiert man den groß? Hat man die EF Zugangsdaten durch ein Bug rausbekommen, dann übernimmt man 1:1 zum Abheben einfach die Daten, die das Skript auch nimmt.

Der EF Tresor ist ein guter Ansatz, ich denke man sollte das EF Passwort zum Transferieren vom normalen EF Login abkoppeln, mit dem potentiell fremden bekannten Losepasswort kommt man schließlich auch nicht zwingend in die Foren- oder Klammaccounts rein.

 

[tedlemegba]

Der EF Tresor ist ein guter Ansatz, ich denke man sollte das EF Passwort zum Transferieren vom normalen EF Login abkoppeln, (...)

Wie meinst du das?

 

[Icy]

Wie meinst du das?

Das man zum EF Login (womit man auch die Daten ändern kann) und für das Skript verschiedene Passwörter nehmen kann

 

[mbassus]

Das man zum EF Login (womit man auch die Daten ändern kann) und für das Skript verschiedene Passwörter nehmen kann

Bringt dir nich viel, außer die Lose sind tatsächlich (und das wird eher selten der Fall sein) im EF Tresor.

 

[Icy]

Bringt dir nich viel, außer die Lose sind tatsächlich (und das wird eher selten der Fall sein) im EF Tresor.

Der primäre Zweck ist auch, das man mit dem potentiell fremden bekanntes Passwort, das unverschlüsselt im Skript oder in der Datenbank steht, nicht gleich den EF Account samt übriggebliebenden Anfragen kapern kann, indem man Email, Daten und Passwort ändert und den Eigentümer ganz aussperrt.
Das die Lose, die nicht im Tresor sind, weg sind, ist mir schon klar.

 

[mbassus]

[...] nicht gleich den EF Account samt übriggebliebenden Anfragen kapern kann, indem man Email, Daten und Passwort ändert und den Eigentümer ganz aussperrt.

Naja, Allgemein stimmt das, aber es lohnt sich nicht. Denn wenn sowas passierd, wird sicherlich schnell was im Abuse-Privat aufgemacht.. und in der Regel bearbeitet Mone das innerhalb weniger minuten..

 

[LasMiranda]

es ist doch völlig egal, ob ich nun Klartext, oder verkrüppelten Text übermittle. Sobald die EF-ID und das EF-Passwort, egal ob nun Klartext, oder MD5-Hash, bekannt ist, kann man von überall aus Buchungen vornehmen.

In den EF direkt kann man damit aber nicht rein (https://ef.klamm.de mein ich), denn der Loginname steht ja nicht dabei.

 

[Icy]

Naja, Allgemein stimmt das, aber es lohnt sich nicht. Denn wenn sowas passierd, wird sicherlich schnell was im Abuse-Privat aufgemacht.. und in der Regel bearbeitet Mone das innerhalb weniger minuten..

Es kann auch passieren, das auf dem EF zum Zeitpunkt des Hacks nix drauf ist, wie es beim Start einer Seite der Fall sein könnte oder alles im Tresor ist.

In diesem Fall, oder wenn die klaubare Losemenge verschmerzbar klein war, würde ich nicht unbedingt ein Admin belästigen müssen und selbstständig handeln können.

es ist doch völlig egal, ob ich nun Klartext, oder verkrüppelten Text übermittle. Sobald die EF-ID und das EF-Passwort, egal ob nun Klartext, oder MD5-Hash, bekannt ist, kann man von überall aus Buchungen vornehmen.

Ja, ich geh noch weiter: Wenn der Fehler nur gravierend genug ist, kann man das Auszahlungsskript auch für sich arbeiten lassen und braucht dann nichtmals die EF Daten zu kennen Trotzdem wäre es schön, den EF Account nicht aus der Hand gerissen zu bekommen wenn das Passwort aus Spaß oder aus Wut geändert wird, vielleicht weil nicht viel ausm EF zu holen war.

In den EF direkt kann man damit aber nicht rein (https://ef.klamm.de mein ich), denn der Loginname steht ja nicht dabei.

Ja, das wäre eine Lösung. Aber kommt mir irgendwie komisch vor, den Loginnamen quasi als "Zusatzpasswort" geheimhalten zu müssen, aber gut, es geht.