Sicherheit LogIn

[Olli]

Hallo zusammen,
zur Zeit Programmiere ich ein Backend für unsere Vereins-Website. Neben der Aufgabe, das Frontend auf dem Laufenden zu halten, möchte ich dort auch einige Vereinsinterne Vorgänge vereinbaren. Dazu zählt auch die Rechnungsstellung -verwaltung, Mitgliedsverwaltung usw..

Da wir ja hier nun über sensible Daten sprechen, mache ich mir natürlich Gedanken über die Sicherheit. Vernünftiges Coden ist hier natürlich angebracht, so weit klar.

Allerdings mache ich mir jetzt noch Gedanken zum Thema Brute-Force-Attaken und Sicherheit der Passwörter. Wie würdet ihr Euch hiergegen absichern? Meine Ansätze waren:

1. IP-Sperre bei zu vielen LogIn versuchen
2. zusätzliche TAN-Liste zum einloggen
3. Ein Kreuzliste, wie sie z.B. bei Schufa-Online gefragt ist

Krteuzliste Beispiel:

A | B | C | D | E
1|5 | 6 | 0 | 1 | 8
2|7 | 7 | 6 | 2 | 9

Der jeweilige User würde nun eine Liste mit "seinen" Nummern bekommen (es handelt sich um höchstens 5 User, also der Aufwand überschaubar) und müsste nun beim einloggen zusätzlich zufällige Werte eingeben, wie zum Beispiel A2 C2 E1

(Hoffe meine Erklärung war nicht zu verwirrend).

Was haltet Ihr von den Ansätzen, was würdet ihr empfehlen?

Euer für jeden Rat dankbarer Olli

[M.]

Mahlzeit,

1. IP-Sperre bei zu vielen LogIn versuchen
2. zusätzliche TAN-Liste zum einloggen
3. Ein Kreuzliste, wie sie z.B. bei Schufa-Online gefragt ist

Da in deiner Liste nicht SSL (https) als Punkt 1 auf der Liste steht, ist dein Konzept fehlerhaft. Immerhin sprichst du von sensiblen Daten.

1. macht kaum Sinn weil leicht zu umgehen
2. dürfte (vorallem ohne SSL) den Aufwand-Nutzen-Faktor in den Keller befördern.
3. siehe 2.

[Olli]

Da in deiner Liste nicht SSL (https) als Punkt 1 auf der Liste steht, ist dein Konzept fehlerhaft. Immerhin sprichst du von sensiblen Daten.

okay, sorry mein Fehler. Natürlich handelt es sich um eine sichere Übertragung mit SSL.

Greetz

[M.]

Mahlzeit,

okay, sorry mein Fehler. Natürlich handelt es sich um eine sichere Übertragung mit SSL.

Dann reicht IMO ein einfaches Session-Login. Denn der Schwachpunkt ist dann der Mensch und das lässt sich durch deine Massnahmen nur bedingt ausschalten. TAN-Listen können weitergegeben werden, IP-Sperre umgehen ist grad mal der Reboot des Routers und eine Kreuzliste ist unsicherer als eine TAN, weil es immer das gleiche Muster ist.

Ich würde evtl. noch ein Captcha als Einmal-Code reinbringen. Auch wenn hier die Meinungen auseinandergehen, Brute-Force hat damit keine Chance, solange du keine solchen Daten hast, an die ein Spezialbot ranwill, der Captchas lesen kann.

Was Sinn macht, bei fehlerhaften Loginversuchen das Login X Minuten sperren, dadurch sinkt die Anzahl der möglichen Angriffsversuche und die zeit für ein erfolgreiches Brute-Force steig enorm.

[Sven Rautenberg]

Moin!

Ich würde evtl. noch ein Captcha als Einmal-Code reinbringen. Auch wenn hier die Meinungen auseinandergehen, Brute-Force hat damit keine Chance, solange du keine solchen Daten hast, an die ein Spezialbot ranwill, der Captchas lesen kann.

Brute Force verhindert man nicht mit Captchas. Sondern mit Brute-Force-Detection. Das System kann mitzählen, wie oft Logins versucht wurden. Captcha-Lösungen kosten 1 Dollar pro 1000 Stück bei menschlicher Eingabe, ansonsten sind viele so schlecht, dass maschinelle Texterkennung leichtes Spiel hat. Oder Menschen ihre Schwierigkeiten kriegen, was zu erkennen.

- Sven Rautenberg

[1UnitedPower]

Meine Herren!

okay, sorry mein Fehler. Natürlich handelt es sich um eine sichere Übertragung mit SSL.

Am sichersten™ wärst du aufgestellt, wenn du die Client-Zertifikate von SSL nutzen würdest. Auf diesem Weg könntest du deinen Redakteuren den Passwort-Login sogar ganz ersparen. Im Gegenzug fällt dafür die einmalige* Erstellung und Installation der Client-Zertifikate an.

[Rowland]

Servus Olli,

das Backend ist für 5 User? Eine IP Sperre und eine Mindestlänge der Passwörter von z.B. 8 Zeichen reicht da eigentlich für Brute Force Attacken, eventuell ein Captcha.

Jeder Buchstabe als Case-Sensitive ergibt bei Verwendung deutscher Buchstaben allein schon 59 Möglichkeiten. Bei einer Passwortlänge von 1 ist das 59, bei einer Länge von 2 ist das schon 59*59 = 3481 Möglichkeiten eines 2 stelligen Passworts. Nimmt man die Zahlen mit rein von 0-9, sind bei einer Passwortlänge von 1 schon 69 Möglichkeiten gegeben, ab 2 Buchstaben sind es 69*69 = 4761, nimmst du noch Sonderzeichen hinzu hast du schon einiges. Und je länger das Passwort, umso mehr Möglichkeiten werden abgeklappert. Bis dahin hast du schon zahlreiche IPs gesperrt.

Selfhtml kommt z.B. auch ohne TAN-Listen aus und die haben aufgrund der Bekanntheit viel mehr Attacken zu fürchten. Ich gehe nicht davon aus, dass deine Seite für Angreifer so interessant ist, dass sie mit Spezialequipment anrücken um deine Seite zu knacken.

Wichtig ist, dass keine Sicherheitslücken, insbesondere durch SQL Injections möglich sind. Nutze dafür am besten PDO (wenn du mit PHP arbeitest).
Und schließe die Sicherheitslücke "Benutzer" z.B. durch Informieren. Brute Force Attacken gehen meistens garnicht mehr nach dem Prinzip bei a anzufangen, sondern mit Passwörtern wie "$|CH€R€$ P/$$W0RT', "Geheim", "Test123" usw. ;-)

Vergiss nicht, dass ihr eure Seite auch nutzen möchtet und kein Bankkonto eröffnen wollt.

lg,
Rowland

[Sven Rautenberg]

Moin!

Wichtig ist, dass keine Sicherheitslücken, insbesondere durch SQL Injections möglich sind. Nutze dafür am besten PDO (wenn du mit PHP arbeitest).

Diese Aussage ist, so wie sie da steht, irreführend. PDO hilft kein bißchen gegen SQL-Injections. Man muß immer noch wissen, was man da tut.

- Sven Rautenberg

[Rowland]

Servus Sven,

PDO hilft kein bißchen gegen SQL-Injections.

Das ist nicht nur irreführend, sondern komplett falsch.

Man muß immer noch wissen, was man da tut.

Genau deswegen. Das hat nichts mit PDO selbst zu tun. Es bietet ideale Bedingungen.

Wichtig ist, dass keine Sicherheitslücken, insbesondere durch SQL Injections möglich sind.

Daran gibt es nichts zu meckern!

Nutze dafür am besten PDO (wenn du mit PHP arbeitest).

Dafür ist PDO am besten geeignet, aus meiner Sicht. Mehr steht da nicht. Es ist das Empfehlenswerteste. Er kann es auch mit mysql_real_escape_string machen, gerne. Vll. noch in Verbindung mit sprintf und anderem Krimskrams. Es steht nirgends, dass PDO sicher ist, wenn es falsch verwendet wird, denn dann lässt sich fast jede hier bisher auf selfhtml getätigte Aussage kritisieren. Wenn ich aber PDO verschlage, gehe ich davon aus, dass der jenige sich im Vorfeld richtig informiert. Und dann wird derjenige auch sofort die Vorteile von PDO kennenlernen und darauß erkennen, warum es am "besten" dafür geeignet ist. Anwenderfehler gibt es immer, dafür kann das PDO nichts und meine Aussage auch nicht.

Man muß immer noch wissen, was man da tut.

Eben deshalb. ;-)

Ganz nebenbei, wenn ich gerade mit dir hier im Gespräch bin. Du hast nicht zufällig eine gute Seite, die gängige Fehler bei der Verwendung von PDO beschreibt (bzw. ein sehr gutes Tutorial zu dem Thema), das du hier als Hinweis posten könntest? So Sachen mit fehlgeschlagener Verbindung kenne ich zwar, aber andere gängige Fehler würden mich auch interessieren, wenn du damit z.B. schonmal Erfahrung gesammelt hast.

lg,
Rowland

[Encoder]

Ich schreibe meine Gedanken die mir dabei gekommen sind, auch wenn sie keine Antwort auf deine Frage sind. Vielleicht lösen sie ja trotzdem dein Problem.
Überleg dir ob die Daten wirklich auf der Webseite sein müssen.

Nehmen wir mal an es geht um einen lokalen Verein in dem sich alle kennen und immer wieder mal sehen.

Muss da wirklich eine Mitgliederliste im Internet sein oder kann man die nicht auch händisch an die paar Kollegen weitergeben die sie brauchen?
Müssen Rechnungen im Internet stehen, dort hochgeladen werden oder was auch immer du vorhast, oder kann man die nicht dem Kassenverwalter in den Briefkasten werfen oder persönlich übergeben?

Dein Vorhaben klingt nach etwas das ich selber auch kenne. Man will was schönes entwerfen das alle recht einfach nutzen können und das möglichst alles abdeckt. Ich bin froh dass ich mir den Aufwand nicht angetan habe. Alle die nicht so technikaffin sind wie ich sind bestimmt auch froh dass sie nicht erst den PC anmachen müssen und dann irgendwelche undurchschaubaren Dinge tun müssen bis sie da sind wo sie hin müssen. Die freuen sich dass sie nach wie vor einen Zettel jemandem in den Briefkasten werfen dürfen oder bei ihm klingeln und dann nebenbei noch das neueste Stadtgeflüster erfahren :-)

Neben allen Sicherheitsmechanismen steht noch eine Gefahr: Hoster werden auch gelegentlich Opfer eines Angriffs. Da kannst du dann machen was du willst um Webseitenbesucher abzufangen, wenn der Angreifer als root schon auf dem Rechner sitzt, hat er auch deine Daten.