Die sichersten Arten des Logins

[Daniel (nun registriert)]

Wenn du ein größerer Anbieter mit einigen hunderttausend bis Millionen Accounts bist, und mehrere Mitarbeiter einer Firma oder sonst eines per NAT am Internet angeschlossenen Netzwerkes sich bei dir einloggen, und deren IP durch irgendeinen blöden oder absichtlichen Zufall gesperrt wird - dann wird es dich als Anbieter vermutlich nicht sonderlich interessieren können, und es wird in der Firma wohl kaum einen Administrator geben, der dort irgendwelche Logs nachsehen kann.

Ergo: Du erzürnst deine Kunden, ohne gegen wirklich gut gemachte Bruteforces eine Chance zu haben. Daraus folgt: IP-Sperrung ist kein Mittel der Wahl.

Naja, eigentlich tut man den Kunden ja n gefallen, denn bei nem Firmennetz weiß man als Nutzer nicht, wie das sicherheitsmäßig aufgebaut ist. Auf der anderen Seite werden die wenigsten Nutzer dafür Verständnis haben und die miesten Heim PCs auch nicht grade sicherer sein, insofern ist es wohl wirklich keine Lösung.

Aber mich interessiert, wie deiner Meinung nach ein gut gemachter Bruteforce aussieht? Was anderes als die Nutzung von zig Proxys bleibt dem Angreifer ja nicht übrig, und zig Proxys wären je nach Passwort Millionen (da hätte man dann am Ende eher n DDos statt nem Login?)

Du denkst gerade in die falsche Richtung. Wenn der Arbeitnehmer sich im Auftrag der Firma zur Nutzung als Arbeitsmittel einloggen will, und ein anderer Arbeitnehmer den Kollegen böse ist und Trouble macht (Mobbing, Kündigung, Spionage), ist das Szenario gar nicht so abwegig.

Ich verstehe, dass man das missbrauchen kann. Aber von der Formulierung werde ich aus "ist das Szenario gar nicht so abwegig." nicht schlau, das klingt so, als sollte da noch zwischendrin etwas stehen. Aber ich vermute mit "Szenario" meinst du den Missbrauch?

Was hilft es dir, einen Teil des gehashten Passwortes, nämlich einen konstanten Prefix oder Suffix, zu kennen? Daraus berechnen sich die MD5-Hashes nicht schneller. Im Gegenteil: Das schlichte Nachgucken eines möglicherweise tabellarisch erfaßten schwachen Passwortes wird garantiert verhindert.

Nehmen wir wieder unser tolles Passwort "test" und ignorieren jetzt mal, dass es dictionary attacks gibt.
ist mir das präfix oder suffix bekannt, muss ich, würde ich am anfang beginnen (was ja sinn macht, wenn man nicht gerade weiß, das es passwortregeln gibt, die dies verhindern) 52^4 kombinationen ausprobieren, Salza, Salzb - das Präfix/Suffix ist ja konstant, d.h. erzeugt nicht mehr Kombinationen.
Hätte ich das ganze 2x verschlüsselt, wäre dies in diesem Fall sogar efefktiver, denn hier habe ich genausoviele Möglichkeiten, aber aufgrund der doppelten Verschlüsselung doppelte Rechenzeit.
(zumindest in der Theorie, das einfügen des Suffix zusätzlich zur aktuellen Zeichenkombination nimmt ja auch Zeit in Anspruch, aber zumindest sollte man durch die doppelte Verschlüsselung in diesem Fall keinen Nachteil gegenüber einem Präfix/Suffix haben)

Das hattest du erfolgreich verschwiegen und nicht als Begründung geliefert.

Es ging die ganze Zeit um die DB und ich habe ja auch geschrieben, dass man an den PHP Code selbst dann meistens schwerer drankommt, wobei das je nach (my)sql konfiguration ja dann auch über (my)sql möglich ist... (php datei über (my)sql erstellen ("export" von (my)sql in php datei, also den code in der db schreiben und dann dumpen), die dann die anderen dateien ausliest/darstellt)

Oder sind dir aus der Praxis solche Lücken, die von Anfängern typischerweise eingebaut werden, bekannt?

Erschreckenderweise passieren sie selbst fortgeschrittenen Entwicklern. Warum sollten sie einem Anfänger dann nicht passieren (ok, dessen Skripte sind weniger komplex, aber da können dann doch trotzdem genauso Fehler drinne sein). Und ich habe mir bisher nicht die Mühe gemacht, irgendwelche Seiten auf SQL Injection zu untersuchen, weder kleine, noch große.

Was technischer Schwachsinn ist, weil User nicht an die IP gebunden sind.

Sicherheitstechnisch würde es aber was bringen und kaum ein Nutzer ändert dauernd seine IP, selbst die Nutzer, die nen Proxy benutzen, nutzen dann meistens ne weile einen, so das dies in der praxis eher weniger ein problem darstellen sollte.

was hälst du denn von session cookies?
man könnte sie ja etwas anders nutzen als sie definiert sind (session im sinne von zerfällt beim schließen des browsers) - kein verschlüsseltes passwort oder so, sondern eine session id drinne speichern. da diese kann nicht per url übertragen wird, könnte der nutzer sie auch nicht versehentlich mitkopieren. dann wäre auch eine ip überprüfung unrelevant.