Die sichersten Arten des Logins

[Sven Rautenberg]

Moin!

Was bestimmt supergut ankommt, wenn damit der eine blöde Mitarbeiter der gesamten Firma das Login des NAT-Netzwerks sperrt.
Man muss die IP ja nicht dauerhaft sperren. und soltle man feststellen, das dies öfters vorkommt, sollte man sich wohl mal an den Administrator wenden, das der mal in den Logs nachschaut, wer denn da fleißig Passwörter ausprobiert.

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.

Zudem sollte man sich doch schon aus Sicherheitsgründen nicht grade von der Arbeit aus einloggen, wer kennt als Arbeitsnehmer schon den genauen Aufbau des Netzwerkes und weiß ob es sicher ist? (machen tuns halt leider trotzdem viele, aber lieber Sperre ich einen Nutzer für ne gewisse Zeit aus, als das sein Passwort geknackt wird!)

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.

SQL.Injection funktioniert nur, wenn a) extrem schlechter Code geschrieben wurde, bei dem sowas möglich ist
Fehler kommen leider immer vor und unser Threaderöffner hier ist Anfänger - dem wird sowas erst recht leicht passieren.

Dann informiere ihn, wie man SQL-Injection sicher verhindern kann - und verwirre ihn nicht mit derartig abstrusen "Sicherheitsideen".

Zudem kann es ja rein präventiv sicher nicht schaden, anzunehmen das es mal vorkommen kann.

Natürlich kann man annehmen, dass der Hashwert des Passwortes bekannt werden könnte. Das ist einer der Szenarien, die man bei der Sicherheitsbetrachtung beachten sollte. Und darauf folgt dann, eine Risikoabschätzung und mögliche Gegenmaßnahmen zu erörtern. Was immer auch dazu führt, dass man Wahrscheinlichkeiten betrachtet, sowie das Kosten-Nutzen-Verhältnis.

Wenn du argumentierst "Ja, das weiß man eben nicht", dann frage ich mich, was gegen die Verwendung von Salz als Prefix oder Suffix spricht?
Ich habe nie behauptet das etwas dagegen spricht.
Mit dem 2.mal verschlüsseln erreiche ich ja das selbe wie mit einem Prä/Suffix.

Das bestreite ich.

Würde man allerdings den Code kennen, könnte man die Angriffszeit reduzieren, man kennt ja bereits einen Teil des Passwortes im Klartext - bei 2facher Verschlüsselung wäre dies nicht der Fall.

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.

Oh, wahnsinn! Super Idee! Statt den Nutzer einmal in die wirklich sichere Methode einer vernünftigen Passworterstellung einzuweisen, schluderst du wieder rum.
Wenn man ein Passwort z.B. 4mal wiederholt und dann noch was beliebiges dranhängt, ist das in der Praxis nicht unsicherer als n entsprechend langes Passwort, wo sich nichts wiederholt, aber leichter zu merken.

Experte für Kryptoanalyse?

Ich bin die ganze Zeit von SQL Injection ausgegangen oder das man auf anderem Wege mal nur auf die DB Zugriff hat (soll ich einem Anfänger Begriffe wie SQL Injection und Exploits um die Ohren hauen?).

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

Bei selbst erstellten Scripts verfügt der "Angreifer" ja normalerweise nicht über den Code. SQL Injection ist trotzdem möglich ("Blind SQL Injection"). Sieht man ja auf vielen Seiten, wenn man an den GET Parametern was ändert - da häufen sich dann gleich die SQL Fehlermeldungen.

Wie erwähnt: Erstmal muß sich überhaupt etwas injizieren lassen. Zweitens muß das dann wirklich genau passen. Drittens muß es dann auch noch anstelle der normalen, programmierten Funktion den Passworthash sichtbar ausgeben.

Das ist alles so unwahrscheinlich, dass es mir schwerfällt, daran zu glauben, dass ein Anfänger wirklich so dermaßen bösen Skriptcode schreiben könnte. Die üblichen bösen Fallen hinsichtlich SQL-Injection sind mir aus diesem Form ja hinreichend bekannt. Die überwiegend eingebauten Lücken erlauben vielleicht Injection, aber keine Bestimmung der abgefragten DB-Felder.

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

Die doppelte Verschlüsselung bringt nichts. Schwache Passworte bleiben schwach!
Wenn man von der doppelten Verschlüsselung weiß, dann ja. Sonst nicht.

Man muß zwingend wissen, durch welche Transformation das Klartextpasswort durchgeleitet wird, ansonsten kann man nicht sinnvoll bruteforcen. Ein beliebiger, in einer DB gefundener 32-Zeichen-Hexstring kann ja alles mögliche sein. Wer sagt mir, dass da MD5 am Werke war?

Es könnte auch MD4 gewesen sein, oder die ersten 128 Bit von SHA1, oder CRC128, oder sonst irgendeine selbst erstellte Checksummenfunktion.

Ansonsten wird man feststellen, dass man unter der Annahme, es sei MD5, viel Rechenzeit in ein wertloses Ergebnis gesteckt hat - das ist in der Tat so.

Insgesamt kritisiere ich an deiner Vorgehensweise, dass du Glauben machen willst, md5() sein eine Sicherheitsfunktion, und je häufiger man sie anwendet, desto mehr Sicherheit bekäme man.
In besonderen Fällen schon.

In welchen Fällen?

Abgesehn davon ist mir bekannt, das md5() nicht mehr das sicherste ist, und es schon Wege gibt, die Angriffszeit zu reduzieren.

Du bist schlecht informiert. Die angesprochenen Angriffe gegen MD5 betreffen Kollisionen, und damit den Einsatz von MD5 als Signaturfunktion. Damit hat die hier diskutierte Problematik für Passworte nicht viel zu tun.

Zu dem Thema Cookie hatte ich mich noch nicht geäußert - aber das ist auch eine Schwachsinnsidee. Wozu gibt es Session-Mechanismen? Da erhält der Nutzer jedesmal eine andere Session-ID, und man kann an der ID bruteforcen, wie man will - sie hat keinerlei Bedeutung, enthält keine Passworte etc.
Ich wollte mich als Nutzer nicht jedesmal einloggen müssen. Und wenn jmd Zugriff auf den PC bekommt, kann er statt sich das Cookie anzuschauen auch n Keylogger installieren, da bringen dann auch Sessions wenig, XSS jetzt mal ausgenommen.

Ja, aber wozu dann überhaupt das ganze Gehampel?

Und Sessions lassen sich genauso bruten

Nein. Lies die diversen Postings von mir im Archiv, die deutlich zeigen, dass das mit heutigen Rechnern und Netzen nicht machbar ist.

oder es kann passieren das technisch weniger versierte Nutzer diese in diversen boardposts mit hineinkopieren.

Wer das als Anbieter vermeiden möchte, nutzt eben ausschließlich Cookies.

Normal sollte die Session an die IP gebunden sein

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

aber das ist eben auch nicht immer der Fall.

Beide Verfahren haben ihre vor und nachteile. Man sollte dem Nutzer beides zur Auswahl stellen, aber pauschal zu sagen das eines der Verafahren sicherer sei als das andere, halte ich für falsch.

Welche Verfahren? Und warum muß der Nutzer sicherheitskritische Entscheidungen treffen? Das kann der gar nicht! Der Anbieter ist gefordert, zu entscheiden, welchen Level an Sicherheit er haben will.

Naja insgeasmt denke ich könnten wir hier noch Stunden diskutieren, es gibt so oder so zig verschiedene Angriffswege,

Nein, eigentlich gibt es vom Grundsatz her nur relativ wenige Angriffswege.

und wenn man sich anschaut, wie weit sich z.B. Sasser verbreitet hat, obwohl es schon einen Monat zuvor das entsprechende Update gab

Das ist ein ganz anderes Thema.

ist doch klar, das die meisten Nutzer zu wenig Ahnung haben.

Gerade schlägst du noch vor, der Nutzer soll sich ein sicherheitsrelevantes Verfahren aussuchen dürfen!

Es fehlt unabhängig von der Sicherheit der eigenen Website auch das Wissen bei den Besuchern.

Und genau deshalb ist der Anbieter gefordert, die Nutzer zu entsprechend sicheren Passworten oder sonstigen Loginverfahren zu zwingen.

- Sven Rautenberg