nicht angemeldet
Hi!
Denn schrief ouck "https://..."!
*grummel*
;-)
sorry, in der Testphase verzichte ich noch darauf, daher hatte ich nicht daran gedacht ;-)
Dann mach ich mal hier ein C&P des Originalpostings:
ich frage mich gerade wie sicher es ist, wenn ich eine Seite wie folgt schütze:
ca. 10 User bekommen eine email mit dem Link zu der gegen alle anderen Cracker... und böswilligen User zu schützenden Seite.
Der link sieht so aus: http://www.server.de/seite.php?id=123&user_id=12312kj3lk12j39023j12lkj3lkj12
id bechränkt die zusammengehörigen User (ca. 10), und user_id ist ein MD5-String den ich wie folgt erzeuge(PHP):
srand ((double)microtime()*1000000);
$randvalue = rand();
$user_id = urlencode(md5($randvalue.$email_adresse));
Das ist unnötig kompliziert. MD5 alleine reicht. Allerdings ist die ID zu einfach, wenn, dann sollte die auch per MD5 verborgen werden.
Was ist jetzt kompliziert? Das urlencode? Ja, das habe ich mir schon gedacht, ursprüngluch ging ich davon aus das md5() auch ungültige Strings ausspuckt, aber anscheinend nicht. ODe2r meinst Du das mit rand()? Das muß allerdings so bleiben, da man sonst sehr leicht auf den MD5() String kommen kann!
Ich hatte mir das jetzt mal so gerechnet, wenn jemand anders die id errät(ist ja nicht ganz so schwer), dann braucht er viel Glück eine gültige user_id zu erraten:
32^36 / 10 = 1,5324955408658888583583470271503e+53
Und wenn Du noch erklärst, wie Du auf diese Funktion kommst? ;-)
Naja, 32 Zeichen hat der MD5 String, so wie ich das sehe kann jedes zeichen entweder ein klein geschreibener Buchstabe sein(6 mögliche Zeichen), oder eine Zahl(10 mögliche Zeichen), also insgesamt 36 mögliche Zeichen, das macht 32^36 Möglichkeiten, und da er aber 10 verschiedene gültige Strings gibt, braucht der böse Bub ja nur 1/10 der Vesuche, also 32^36 / 10, und wenn meine Kopfrechenkenntnisse noch die sind die sie mal waren sollten das in etwa 1,5324955408658888583583470271503e+53 verschiedene Möglichkeiten sein, also eine 1 mit 53 Nullen!
wobei mir hier immer verdächtig viele Zahlen drin sind, evtl läßt sich ein Algorythmus beschleunigen, aber auch das sollte nicht viel bringen, denn selbst 32^10 / 10 = 1.125.899.906.842.624
Das ist enstschieden zu wenig!
Ja? Wenn ich ein sleep(1) einbaue, dann braucht er egal wie schnell das ganze quer über das Internet funktioniert immerhin im Idealfall 1.125.899.906.842.624 Sekunden, macht über den Daumen noch ca. 35.702.051 Jahre. Oder habe ich mich jetzt grob verrechnet?
Selbst wennihc das weglasse, vermutlich schafft er ca. 100, max 200 Anfragen in der Sekunde, wenn ich davon ausgehe er schafft 1000 pro Sekunde, dann braucht er immer noch 35.702 Jahre!
und wenn ich dann noch ein sleep(2) einbaue(am besten nur dann wenns die Fehlermeldung gibt), dann wird es per Brute-Force vermutlich unmöglich - vor allem über das Internet, oder?
Nein. Eine Verzögerung alleine ist nicht sinnvoll. Nur das Beschränken auf eine begrenzte Zahl an Fehlversuchen hilft.
Wenn das den so einfach wäre, wie willst Du das machen? Das wurde schonmal groß und breit diskutiert, wenn der Angreifer sich auskennst kannst Du ihn im Prinzip schon beim 2. mal nicht mehr wiedererkennen!
Und das ist auch die einzige Schwachstelle an der ganzen Sache, die Klartext-Email, aber das Problem wird man wohl immer haben, aber wenn jemand der ein Interesse hat da einzubrechen bereits in der Lage ist entweder bei mir oder bei dem betroffenen User emails mitzulesen ist eh fast alles verloren!
Nicht nur fast. Deswegen ist ja auch keine Unterschied zur User/Password Kombination.
Es wird hier also noch eine kryptographische Methode benötigt, die Übergabe des Paswortes zu verschlüsseln. Diese Methode ist Open PGP, ein standardisierter Algorithmus http://www.ietf.org/html.charters/openpgp-charter.html, die Software dazu ist frei erhältlich http://www.gnupg.org/de/gnupg.html.
Das kann man wohl bei keinem GEschäftspartner als vorhanden voraussetzen, oder?
Grüße
Andreas