Sicherheitskonzept aktzeptabel?

Hallo. Ich weiß es gibt diverse Möglichkeiten aber ich möchte nun einfach mal wissen, ob dieser Login-Gedanke in Ordnung ist oder ob ich da große Gefahren übersehe:

Logindaten (username, password) sind in einer extra SQL-Datenbank geschrieben.

Bei Eingabe der Logindaten (über ein HTML Formular) wird halt kontrolliert, ob die Daten übereinstimmen. Wenn nicht: Falsche Eingabe und wenn es stimmen sollte wird ein Cookie gesetzt und eine Zahlenkombination reingeschrieben. Das Cookie verfällt nach 300 sek.

Wenn man nun versucht, die Adminseite (/admin) aufzurufen, kontrolliert er vorher ob es das oben genannte Cookie existiert. Um sicher zu gehen, kontrolliert er zusätzlich , ob das Cookiewert richtig ist. D.h. selbst wenn jemand diesen Cookie nachbasteln würde, müsste er auch den Cookiewert wissen.

D.h.
Wenn Cookie existiert und der Value = ...... ist, dann zeige Admin_panel

ansonsten: lade Login-Fenster.

Kann man das so realisieren? Oder sind da grobe Sicherheitsfehler drinne?

Ps.
Warum ich keine Sessions benutze? Das Framework, mit dem ich arbeite , hat damit derzeit noch kleine Probleme.

Dann kannst du auch gleich Benutzername und Passwort im Cookie speichern. Hat den gleichen Effekt.

Alternativ bastelst du dir halt deine eigene Implementierung von Sessions. Da ändert sich die Nummer halt immer. Musste halt in eine Tabelle anlegen, in der die Nummer einem Nutzer zugewiesen wird.

Dein Vorgehen ist (in allen drei Fällen) so lange sicher, wie keiner deine Verbindung belauscht. Nur in den ersten beiden Fällen hat der Angreifer sofort Zugriff auf den Accout, im letzten nur auf die Session.

SeppJ

Dump34 schrieb:

Logindaten (username, password) sind in einer extra SQL-Datenbank geschrieben.

Falls du das mit dem Passwort wörtlich meinst, bräuchte man an dieser Stelle gar nicht erst weiterzulesen. Aber ich bin mal im Zweifelsfalle für den Angeklagten und setze voraus, dass du schon einmal etwas von Hashes gehört hast.

Bei Eingabe der Logindaten (über ein HTML Formular) wird halt kontrolliert, ob die Daten übereinstimmen.

Auch hier könnte man wieder sofort aufhören zu lesen, aber ich nehme mal an, dass das Formular per HTTPS übertragen wird.

Wenn nicht: Falsche Eingabe und wenn es stimmen sollte wird ein Cookie gesetzt und eine Zahlenkombination reingeschrieben. Das Cookie verfällt nach 300 sek.

Denk aber unbedingt daran, das Cookie so zu setzen, dass der Browser es nur über sichere Verbindungen verschickt. Cookie-Hijacking ist ein ganz verbreiteter Angriff. Und auch sonst gibt es viele verbreitete Attacken, die auf den Inhalt von Cookies abzielen. Du musst dir sicher sein, dass du, der Browser und der Anwender da keinen Mist machen.

Wenn man nun versucht, die Adminseite (/admin) aufzurufen, kontrolliert er vorher ob es das oben genannte Cookie existiert. Um sicher zu gehen, kontrolliert er zusätzlich , ob das Cookiewert richtig ist. D.h. selbst wenn jemand diesen Cookie nachbasteln würde, müsste er auch den Cookiewert wissen.

Herzlichen Glückwunsch, du hast die digitale Signatur erfunden! Mal wieder...
Deine hat jedoch den Nachteil, dass die Signatur zwischendurch verschickt werden muss, anstatt die ganze Zeit auf einem Computer zu verbleiben. Potentielle Angreifer könnten sie irgendwie abfangen.

hustbaer

Was hat das mit Signatur zu tun?
Das ist einfach nur ein ganz normales Cookie...

Und ja, liest sich ziemlich schrecklich.

Falls du das mit dem Passwort wörtlich meinst, bräuchte man an dieser Stelle gar nicht erst weiterzulesen. Aber ich bin mal im Zweifelsfalle für den Angeklagten und setze voraus, dass du schon einmal etwas von Hashes gehört hast.

Ja das Passwort wird natrlich verschlüsselt in die DB gespeichert. Muss halt nur mal gucken, welchen Algorythmus ich da nehme. Für MD5 gibt es ja schon endliche Encoder...

Auch hier könnte man wieder sofort aufhören zu lesen, aber ich nehme mal an, dass das Formular per HTTPS übertragen wird.

Reicht doch wenn ich einfsach nen https:// vor die URL setze oder?
Kenn mich da nicht all zuu gut aus.

Michael E.

dump34 schrieb:

Ja das Passwort wird natrlich verschlüsselt in die DB gespeichert.

Hashen, nicht verschlüsseln!

Muss halt nur mal gucken, welchen Algorythmus ich da nehme. Für MD5 gibt es ja schon endliche Encoder...

Na das will ich mal hoffen, dass die endlich sind
[quote]

Reicht doch wenn ich einfsach nen https:// vor die URL setze oder?
Kenn mich da nicht all zuu gut aus.

Dann solltest du dich noch ein wenig mehr informieren, wenn du deine Authentifizierung selbst schreiben willst.

Reicht doch wenn ich einfsach nen https:// vor die URL setze oder?
Kenn mich da nicht all zuu gut aus.

Dann solltest du dich noch ein wenig mehr informieren, wenn du deine Authentifizierung selbst schreiben willst.

War das jetzt ein Ja bzgl. meiner Frage?

DerBaer

Michael E. schrieb:

dump34 schrieb:

Ja das Passwort wird natrlich verschlüsselt in die DB gespeichert.

Hashen, nicht verschlüsseln!

Dumme Frage nebenher: wo ist der Unterschied? Ich meine in beiden Fällen wird doch das Passwort in eine nicht mehr zu lesende und nicht(schwer) rückgängigmachbare Form gebracht, oder nicht?

ipsec

DerBaer schrieb:

Michael E. schrieb:

Hashen, nicht verschlüsseln!

Dumme Frage nebenher: wo ist der Unterschied? Ich meine in beiden Fällen wird doch das Passwort in eine nicht mehr zu lesende und nicht(schwer) rückgängigmachbare Form gebracht, oder nicht?

Verschlüsselung ist in der Regel so angelegt, dass man sie wieder rückgängig machen kann...

otze

DerBaer schrieb:

Dumme Frage nebenher: wo ist der Unterschied? Ich meine in beiden Fällen wird doch das Passwort in eine nicht mehr zu lesende und nicht(schwer) rückgängigmachbare Form gebracht, oder nicht?

Das Problem ist, dass du sowohl zum ver- als auch entschlüssen den privaten Schlüssel brauchst und der somit irgendwo für das Programm zgänglich auf dem Server liegt (und damit angreifbar ist). Ein Hash funktioniert ohne Schlüssel, ist aber eine nicht umkehrbare Funktion. Der Hash schützt dich vor Sicherheitsverlust, wenn dir jemand deine DB klaut. Mit den hashes kann man nichts mehr anfangen, außer man kennt die Passwörter bereits (oder hat eine komplette Hashtabelle, was bei einem 512Bit hash mehr Platz bräuchte als Atome im Universum existieren...)

hustbaer

@otze: naja wenn man den Hash hat kann man schlechte Passwörter sehr schnell mit Brute-Force knacken.
Bzw. wenn "ungesalzene" Hashes verwendet werden einfach in entsprechenden Listen nachgucken.

Also ganz so ohne ist das auch nicht.

Allerdings schützt es immer noch User mit starkem Passwort, und das ist ja immerhin auch was.

Warum ich das erwähne: ohne die Hash-Liste kann man ein Passwort kaum Brute-Force knacken, da a) die meisten Server mitloggen und irgendwann Alarm schrein und b) ein Versuch das Passwort zu erraten übers Internet viel zu lange dauert.

p.S.: nicht falsch verstehen. Ich will damit nicht sagen dass man evtl. auf Hashes verzichten könnte. Das auf keinen Fall. Ich meine nur: "problemlos" ist das "Verlieren" der Hash-Liste auch nicht (bei weitem nicht).

rüdiger

Nur hashen ist keine gute Idee! http://en.wikipedia.org/wiki/Rainbow_Table Und gerade MD5 gilt mittlerweile als geknackt.

Nutze für die Passwörter lieber ein Verfahren, dass von Profis in dem Bereich entwickelt wurde. zB bcrypt oder SHA-crypt.

Also, ich weiß ja nicht, ob hier wirkliche niemand (!!) davon gehört hat, oder aus Arrogranz diesen Tip nicht gibt...

Üblich ist es mehrere Wiederholungen mit der Hash-Funktion zu machen.

Beispiel in C-pseudo-code ->

string passwort // kommt von außen

string salt // darf nicht an die außenwelt

string hash = md5(passwort + salt)

for (int i; i < 50; i++)
{
    hash = md5(hash + salt);
}

Zusätzlich könnte man noch den salt bei jeder iteration ändern, also zb. salt + itoa(i), was kaum nötig sein dürfte, da kaum jemand zeit hat, für 50/100/500 md5-stufen eine rainbow-tables zu basteln. Alleine, wenn es sich bei deinem Zeug um nichts handelt was irgendwie mit wichtigen Daten zu tun hat, reichen schon 5 iterationen.

Also, ich weiß ja nicht, ob hier wirkliche niemand (!!) davon gehört hat, oder aus Arrogranz diesen Tip nicht gibt...

Üblich ist es mehrere Wiederholungen mit der Hash-Funktion zu machen.

Beispiel in C-pseudo-code ->

string passwort // kommt von außen

string salt // darf nicht an die außenwelt

string hash = md5(passwort + salt)

for (int i; i < 50; i++)
{
    hash = md5(hash + salt);
}

Zusätzlich könnte man noch den salt bei jeder iteration ändern, also zb. salt + itoa(i), was kaum nötig sein dürfte, da kaum jemand zeit hat, für 50/100/500 md5-stufen eine rainbow-tables zu basteln. Alleine, wenn es sich bei deinem Zeug um nichts handelt was irgendwie mit wichtigen Daten zu tun hat, reichen schon 5 iterationen.

und für das session hijacking gut einfach bei wikipedia, natürlich nicht die deutsche, da bekommst du anregungen.

http://en.wikipedia.org/wiki/Session_hijacking

hustbaer

rudolf the rednosereindee schrieb:

Also, ich weiß ja nicht, ob hier wirkliche niemand (!!) davon gehört hat, oder aus Arrogranz diesen Tip nicht gibt...

Aber sonst geht gut hoffe ich...