Login ja, aber sicher?

[penizillin]

splasch: was ist denn daran sicherer? das bruteforcing kann man auch eleganter vermeiden, indem man nach 5 fehlversuchen eine auszeit von 10 minuten einlegt (oder so). (sehe gerade, du hast es ja auch schon selbst vorgeschlagen) also schließen wir das bruteforcing aus. wozu denn dann noch etwas von der frontend-seite ausdenken?

was bleibt übrig? richtig, jemand bekommt einen einblick in die tabelle "users". was liest er da? richtig, irgendwie muss man die passwörter schon veränden. dafür eignen sich hash-funktionen hervorragend. md5 ist dir zu "unsicher"? nimm sha1. oder - schreibe dir eine eigene. du redest von diesen datenbanken mit standardwörterbüchern, in denen man hashes "lookup'en" kann? nutze "salt". dann geht das auch (fast gar) nicht mehr.

[wahsaga]

Original geschrieben von penizillin
das bruteforcing kann man auch eleganter vermeiden, indem man nach 5 fehlversuchen eine auszeit von 10 minuten einlegt (oder so).

Nicht unbedingt - denk dir ein System wie eBay, wo ich damit unliebsames Konkurrenz in den letzten Minuten vom Einloggen und damit auch vom Mitbieten abhalten könnte ...


Was er beschrieben hat, ist ein klassiches Challenge-Response-Verfahren.

[penizillin]

stimmt, das sollte natürlich mit der inhaltlichen problematik abgestimmt werden.

[onemorenerd]

Pw1 = hans, pw2 = *2, also das gleiche Beispiel wie oben.

Pw1 wird beim unserem brute forcing von a bis hans durchiteriert.
Bei jedem Loginversuch gibt dein System eine Kontrollzahl aus. Die interessiert uns allerdings nur insofern, dass wir eine Zahl zwischen -1000 und +1000 als Kontrollpasswort wählen und beide Zahlen abspeichern.
Damit bauen wir eine Tabelle auf wie diese
(Pw1, Kontrollzahl, Pw2) = (a, 14, -1000)
(Pw1, Kontrollzahl, Pw2) = (a, 30, -1000)
(Pw1, Kontrollzahl, Pw2) = (a, 56, -1000)

Irgendwann kommt die Kontrollzahl 14 wieder. Dann nehmen wir natürlich nicht nochmal -1000 sondern -999.
Wenn irgendeine Kontrollzahl insgesamt 2000 mal versucht wurde, weiß man, dass Pw1 nicht a ist und kann mit aa weitermachen.

Unter den Annahmen, dass
1. deine User auch nicht über den Bereich von -1000 bis +1000 hinaus rechnen und ihr Pw2 entsprechend gewählt haben,
2. die Kontrollzahlen zw. 0 und 100 liegen,
3. die Mindestlänge für Pw1 4 Zeichen ist,
4. nur alphanumerische Zeichen und keine Umlaute zulässig sind,
haben wir 'hans' nach 1632960 * 200000 < 32,e+10 Versuchen geknackt. Der Aufwand hat sich durch die Kontrollzahlgeschichte also um den Faktor 200000 erhöhrt.

Zum Vergleich: Passwörter mit 8 Zeichen brauchen auch 282,e+10 Anläufe, sind also schwerer zu knacken als dein Kontrollzahlgedöns.

[splasch]

Ich geh mal davon aus das deine Rechnung stimmt habs nicht nach kontrolliert.

Dann haben wir ja unser Ziel erreicht.

Der Aufwand hat sich durch die Kontrollzahlgeschichte also um den Faktor 200000 erhöhrt.

Die User mit schlechten Pw haben nun einen angemessen schutz gegen Acount hacking (ich denke mal da an Onlinebroswer games die sind ja für solche sachen beliebte angriff ziele)
Es würde also Jahre dauern bis jemand den Zugang geknackt hat. Und bei den meisten Broswergame ist da eh schon lang die Spielrunde zu ende.
Dadurch die login versuche ja auch begrenz sind zieht sich das Massive in die Länge.

So Fassen wir mal das zusammen wie Weit wir bis jetzt gekommen sind:

1.)Kontrollzahl ....Sinvoll oder nicht Sinvoll

Also ich find das Sinvoll bei Online game statt der üblichen Spam kontroll brüfung wo man die Bildinformation eingeben muß.

2.) Login Versuchen begrenzen und auf Zeit sperren ...sinvoll oder nicht

Ich würde es als sehr sinvoll betrachten zum Thema Sichherheit.

3.) Das Password gehast oder verschlüsselt speichern ...sinvoll oder nicht

Ich würde das zuerst mit crypt verschlüsseln und dann md5 hasen

4.) Das Login Formular wurde noch nicht besprochen vorschläge sind immer willkommen.


So dann will ich mal kurz den nächsten Punkt anschneiden. Was kann man allles machen damit das Login Formular sicher wird.

Übergabe mit Post da Get viel zu unsicher ist.Prüfen ob Formular 2 mal abgeschickt wurde (Sever entlastung bwz bug using damit unterdrücken)
Prüfen ob überhaupt ein pw eingeben wurde wenn nicht die Datenbank garnicht abfragen(Sql injection damit verhindert das jemand nur versucht über das Login feld daten zu senden ohne andere angaben zu machen)
Eingaben aus dem Formular Filtern datentyp festlegen( Bsp mit sprintf )
Sonderzeichen und Html zeichen entfernen aus komentieren.
Mit Trim hinten und vorne Leerzeichen entfernen.

So wenn euch noch jetzt was spontan dazu einfällt bwz wie mans besser machen kann dann Posten.Sollte uns nix mehr dazu einfallen können wir zum nächsten Punkt gehen. ( Der Datenbank eintrag)

[penizillin]

ich muss meine vorredner zitieren: dein vorgehen ist einfach paranoid, der unterschied zwischen sicherheit und überschuss an kontrollmechanismen ist dir nicht klar, du setzst einfach alles ein, was dir einfällt ohne zu verstehen, was es wirklich bringt.

Kontrollzahl ....Sinvoll oder nicht Sinvoll

OffTopic:

---

stimmt, manchen "pisa-kindern" würde kopfrechnen nicht schaden.

---

Ich würde das zuerst mit crypt verschlüsseln und dann md5 hasen

du scheinst noch nicht mal zu wissen, wie "hash" und die abgeleiteten wörter geschrieben werden, also unterstelle ich dir einfach, dass du nicht weißt, was die funktion macht (das bestätigt nur deinen (oben beschriebenenen paranoiden) drang, etwas zu verschlüsseln vor dem hashen). informiere dich lieber über die verwendung von "salt" mit hashing.

[stekoe2000]

OffTopic:

---

Den Bot, der für 30-10*5+32=132 ausrechnet ... den musste dir auch erstmal schreiben ^^

---

[onemorenerd]

Original geschrieben von splasch
1.)Kontrollzahl ....Sinvoll oder nicht Sinvoll

8 Zeichen minimale Passwortlänge ist sicher und viel benutzerfreundlicher. Also nicht sinnvoll.

Imho hast du nicht die nötige Peilung für eine ernstzunehmende Diskussion über Sicherheit. Für dich ist es schon eine Maßnahme, zu "Prüfen ob überhaupt ein pw eingeben wurde".