Die sichersten Arten des Logins

[Sven Rautenberg]

Moin!

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?)

Einen Bruteforce kann man nicht realisieren, wenn die zugrundeliegenden Passworte nicht in endlicher Zeit erratbar sind.

Und wie mach man Passworte nicht erratbar? Indem man sie lang und zufällig macht!

Und wie kriegt man User dazu, Passworte lang und zufällig zu machen? Indem man z.B. dem User das Passwort vorschreibt, anstatt ihn selbst eines aussuchen zu lassen. Gleich bei der Registrierung kriegt er eines verpaßt, das man ihm mitteilt (auf dem Bildschirm oder per Mail), und fertig. Wenn er sein Passwort wechseln möchte oder es vergessen hat, kriegt er wieder ein neues, generiertes Passwort.

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?

Ich meine, dass es genug Gelegenheiten gibt, wo jemand innerhalb einer Firma Trouble machen wollen würde, wenn er denn könnte. Also besser keine Sperre einbauen (jedenfalls nicht als pauschale Lösung), weil man damit als Bösewicht den Zugang für legitime User versperren kann.

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.

Der Punkt ist der: Es gibt nur zwei mögliche Angriffsformen gegen Hashfunktionen wie MD5 (von kryptographischen Angreifbarkeiten abgesehen): Entweder weiß ich zum Hash den Input durch eine Tabelle, oder ich muß durchprobieren.

Wenn das Passwort 1:1 durch MD5 durchgeht, sind solche Tabellen erfolgreich. Wenn irgendein Faktor mir den direkten Lookup versaut, muß ich durchprobieren, also Variationen von Input generieren und den Mechanismus komplett durchrechnen, um das Ergebnis auf Identität mit dem ausspionierten Wert zu prüfen.

ist mir das präfix oder suffix bekannt,

Wenn du das als bekannt voraussetzt, dann mußt du als bekannt voraussetzen, dass der Angreifer den gesamten Hash-Mechanismus kennt.

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.

Verdopplung der Rechenzeit ist aber irrelevant. Dann nimmt der böse Angreifer einfach die doppelte Menge an Rechenpower (zwei statt eine CPU), und schon hat sich die Sache wieder erledigt.

Es ist nicht praktikabel, den Weg vom Input zum Hash mit extrem viel Rechenzeit zu belasten, damit das Brute Force lange dauert. Denn auch die gewollte Anwendung innerhalb der Applikation würde ja darunter leiden, denn das Prüfen von Passworten wird andauernd vorkommen. Unter Umständen bei jedem einzelnen Request. Solch ein Hashvorgang sollte daher möglichst schnell ablaufen.

MD5 bezieht seine Stärke nicht aus seiner Langsamkeit, sondern aus den 2^128 verschiedenen möglichen Hashwerten. Das sind so viele, dass es mit heutigen Methoden länger braucht, alle Möglichkeiten durchzurechnen, als das Universum alt ist.

Angenommen, du hättest die Möglichkeit, pro Sekunde eine Billiarde MD5-Hashes nachzurechnen. Dann würdest du für den kompletten Bereich 1,07e+16 Jahre benötigen.

Unser Universum ist 13,7e+9 Milliarden Jahre alt. Du bräuchtest also die Lebenszeit von knapp einer Million Universen, um einmal alles durchzurechnen.

Das macht extrem deutlich, dass mit Brute Force bei MD5 nicht wirklich viel zu holen ist.

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.

Nun ja, angesichts deines Levels auf PHP-Basis, der sich aus deinen anderen Fragen ergibt, sehe ich nicht, dass du das wirklich beurteilen könntest.

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.

Du hast keine Ahnung, was z.B. bei AOL abläuft! AOL setzt eine ganze Farm von Proxys ein, die zur Lastverteilung beliebig User-Requests verteilt bekommen. Ein User wechselt bei dieser Farm unter Umständen mit jedem Request seine IP.

Also ist es Schwachsinn. Eine IP identifiziert keine User, folglich kann man sie nicht für irgendwelche allgemeinen Sicherheitsmaßnahmen heranziehen.

was hälst du denn von session cookies?

Session Cookies sind absolut in Ordnung.

man könnte sie ja etwas anders nutzen als sie definiert sind (session im sinne von zerfällt beim schließen des browsers)

So sind Sessions nicht zwingend definiert.

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.

Und genau so arbeiten Sessions in eigentlich allen mir bekannten Session-Systemen: Der User kriegt eine vollkommen zufällig generierte, x-beliebige ID zur Wiedererkennung, an der intern im Server dann diverse Werte drangehängt werden, die den Server aber niemals verlassen.

Bei einem Login tauscht man dann sozusagen die Kenntnis über Username und Passwort mit der Kenntnis über die Session-ID. PHP verwendet für die ID auch wieder das Resultat von MD5, also eine Hexzahl mit 32 Ziffern. Und deshalb wird man eine aktive Session-ID auch niemals erraten können, weil man genau wie beim Brute Force einfach viel zu lange bräuchte, alle IDs durchzuprobieren.

- Sven Rautenberg