nicht angemeldet
Hallo,
Das sollte man nicht tun. Immer vollständig testen.
Richtig, aber man muß ja nicht von Anfang an vollständig testen!
Bei komplexen Programmen ist es möglich, das durch Hinzufügung weiterer Teile das das ehemals positiv Getestete im Zusammenhang nicht mehr funktioniert.
Wenn Du Teile testen willst, mußt Du das auch gleich von vornherein beachten. Einfach nur ein paar Zeilen schreiben und dann ausprobieren funktioniert nicht, damit kanst Du ganz schön auf die Schnauze fallen.
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 ;-)
Nein, dadurch, das 16 < 36 ist ;-)
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?
Ein ordentliches Login.
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?
Ein ordentliches Login über SSL ist genauso sicher und vor allem problemloser. Das Letztere heißt natürlich auch, das die Fehlerwahrscheinlichkeit im Code sinkt. Somit ist ein derartiges Login sogar sicherer.
Absolute Sicherheit gibt es nicht!
Das kann ich nur unterschreiben.
Aber ich denke in der Tat inzwischen darüber nach, ob man zuusätzlich doch noch einen User-Login davorschalten soll...
Nein, wenn es über SSL geht reicht ein Userlogin. Alles andere ist nur komplizierter und damit fehleranfällig und somit unsicherer.
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!
Das ist aber sehr mager. Kleine Hardware?
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?
Das verstehe ich nicht, was ist an den zwei Parametern (username/passwort) zuviel? Wenn Du die Loginversuche mitzählst hast Du noch einen Integer zum behalten, aber _das_ dürfte doch kein Problem darstellen, oder?
Versuche nicht das Rad neu zu erfinden, nimm das was schon da ist. Das ist bewährt und bekannt und läuft stabil.
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,
Da bist Du aber juristisch auf der sicheren Seite.
Aber selbst da gilt, ich muß es erwähnen: "Auf hoher See und vor Gericht bist Du in Gottes Hand"
und wenn man hier mit solchen Maßstäben mißt muss man das überall tun.
Was spricht dagegen, es überall zu 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.
Es ist bedeutend einfacher, glaub's mir. Die ganzen Scriptkiddies sind lästig, aber nicht unbedingt gefährlich. Die gefährlichen Leute verfügen über besser Möglichkeiten und vor allem Sachverstand.
"Das ist aber _sehr_ unwahrscheinlich!" waren schon oft "letzte Worte"!
so short
Christoph Zurnieden