nicht angemeldet
Hi!
Das sollte man nicht tun. Immer vollständig testen.
Richtig, aber man muß ja nicht von Anfang an vollständig testen!
Genau, MD5 wirft eine Hexcodierte Zahl aus. [a-f0-9] (Können auch Großbuchstaben sein)
AHA! Wußte ich natürlich nicht, dadurch relativiert sich meine Rechnung ;-)
ODer meinst Du das mit rand()? Das muß allerdings so bleiben, da man sonst sehr leicht auf den MD5() String kommen kann!
Nein, warum?
Ein Passwort aus einem Generator (auch sowas ist standardisiert) reicht normalerweise. Kannst ja da noch MD5 drüberlegen.
rand() ist deshalb nicht gut, da es keine wirklicher Zufallsgenerator ist.
Was ist denn besser? Der von mir verwendete Code mit Microtime als srand() ist das zufälligste was PHP erzeugen kann, wenn ich den Kommentaren im Manual glauben schenken darf! Was soll ich denn statt dessen verwenden?
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,
Ich komme da auf 16 ;-)
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!
Das ist nicht ganz korrekt. Die MD5Sum ist wirklich eine Summe, also eine Zahl (128 Bit lang) keine Zeichenkette.
Gesamte Permutationsanzahl liegt also bei:
2^128 = 340.282.366.920.938.463.463.374.607.431.768.211.456
Die Statistik für die Wahrscheinlichkeit aus (2^128)-10 weißen Kugeln eine von 10 schwarzen zu ziehen überlasse ich Dir ;-)
Zumindest Sicher genug wieich finde, oder? Absolute Sicherheit gibt es nicht! Aber ich denke in der Tat inzwischen darüber nach, ob man zuusätzlich doch noch einen User-Login davorschalten soll...
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?
Das ist für einen Zugang, aber ich kann soviele paralell laufen lassen, wie der Server hergibt solange Du keine Gegenmaßnahmen getroffen hast.
Ja, und das max. was ich bis jetzt an Parallelen "Angriffen" hinbekommen habe war unter 100 Requests pro Sekunde!
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, siehe oben.
Ein schlichtes Login mit Zähler ist wirklich das einfachste und nach technischem Stand sicherste im Netz. (Vorrausgesetzt, die Übertragung selber ist verschlüsselt)
Aber das setzt doch voraus, das ich einen Weiteren Parameter brauche, die UserID, wenn möglich würde ich gerne einen weiteren Parameter verhindern, wie mache oich das am besten?
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!
Er muß erst Die ID (Den Usernamen) haben, darauf kannst Du dann den Zähler ansetzen. Wenn also eine ID versucht sich mehr als dreimal vergebens einzuloggen ist die ID gesperrt. Das ist eine sehr alte Technik, die sich sehr gut bewährt hat. Was spricht dagegen?
s.o.
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?
Das ist Vorraussetzung, ansonsten ist Snail Mail zu wählen.
Ja ich weiß, aber Sicherheit ist nicht zum Nulltarif zu haben, das kostet und wenn es "nur" Mühe ist.
Naja, selbst dann hat man keine 100%ige Sicherheit, und wenn man hier mit solchen Maßstäben mißt muss man das überall tun. Wenn im Sicherheitskonzept das verschlüsseln von Mails nicht vorkommt kann man es vergessen. Außerdem schätze ich die Gefahr des abfangens von Emails nicht als wirklich groß ein - ja - sicher gibt es diese Gefahr, aber das ist doch nun mal wirklich nicht ganz so einfach als sich mit einem Brute-Force Tool einer Session zu bemächtigen.
Viele Grüße und Danke für die hilfreichen Antworten!
Andreas