Hallo!

a) Wie Sicherheit umgesetzt worden ist, hier

Das wurde doch in den Postings erklärt, oder? Ist das noch nicht klar?

b) Wie komplex (sagen wir mal wie schwierig für mich nachzuvollziehen) die Sache umgesetzt worden ist

s.o.

c) ob mein eigenes einfaches Sicherheitskonzept (eine Tabelle "Sessions", eine Tabelle "Benutzer" und eine Tabelle "Rechte"; dann Sitzung anlegen, Sitzung authentifizieren und "Sitzung-GUID" hin und herschicken), welches ich einige Male umgesetzt habe, unzureichend sein könnte.

Das kann man zum einen pauschal nicht sagen da ich zumindest das genaue Konzept(Quellcode) nicht kenne. Außerdem kommt es darauf an _was_ Du schützen willst. Für mich hat basic/digest Authentifizierung den Vorteil das man hiermit alle HTTP zugriffe schützen kann, nicht nur die Zugriffe auf "manuell" geschütze Scripte.
Außerdem ist es ein standardisiertes Verfahren was bekannt, sicher und performant ist. Verwalten läßt sich das genauso gut wie eine eigene Lösung mit Sessions.

Ich frage mich nur wofür Du 3 Tabellen benötigst? Es würde doch die Tabelle "Benutzer" reichen in der Du auch die Rechte speichern kannst denn die mußt Du sowieso pro Benutzer speichern. Den Sinn der Tabelle "Sessions" sehe ich nicht, außer vielleicht um zu verhindern das es gleichzeitig mehrere Sessions pro Benutzer gibt.

Ich mache das immer so dass ich die Zugangsdaten in der Session speichere und die dann mit der Tabelle "Benutzer" bei jedem, Zugriff validiere und ggfs. die Rechte auslese. Das ist IMHO sogar sicherer als basic und digest authentification, da die Zugangsdaten nur einmal übertragen werden, halt beim einloggen, und dann nur noch die Session ID, im Gegensatz zur HTTP Authentification. Wobei der Sicherheitsgewinn auch hier nur marginal ist, da man zum einen auch innerhalb der Session genug anrichten kann, und vor allem, wenn jemand einmal in der Lage ist den HTTP-Traffic zu belauschen dass er an die HTTP Auth Daten kommt, dann kommt er mit etwas Geduld auch an die Zugangsdaten einer Session-basierten Lösung. Außerdem ist bei der Session-Lösung noch zu beachten, dass die SessionID ggfs. im Request-String übertragen wird, und so in verschiedenen Logfiles auftauchen kann, wenn man da schnell genug dran kommt ist der "Einbruch" also erheblich einfacher. Außerdem kann man sich in Eigenbau-Lösungen leicht Sicherheitslücken einbauen, was bei HTTP-Auth schon etwas schwieriger sein sollte.

Viele Grüße
Andreas

Moin moin!

Einloggen könnte man sich ja auch mit dem md5-string, nur nicht mit einem "handelsüblichen" Browser, aber ich vermute das Leute die nicht im selben LAN sitzen und an die Zugangsdaten eines fremden Teilnehmers kommen bestimmt ohne große Schwierigkeiten z.B. den Quellcode des Mozilla dahin gehend modifizieren könnten, sich auch mit den md5-strings im Auth-Fenster einloggen zu können, oder? (ich könnte es nicht, ich wüßte aber auch nicht wie ich an die Zugangsdaten außerhalb meines lokalen LANs kommen könnte)

Du hast das nicht so explizit gesagt, aber es scheint mir, dass Du glaubst, bei der Digest-Authentication wird einfach der md5-Hash ueber die Zugangsdaten gebildet und dann statt des Username/Passworts geschickt. Das waere natuerlich ziemlich sinnlos, da der Hash an die Stelle der Zugangsdaten tritt, und zwar so komplett, dass man die Zugangsdaten an sich nicht mehr braucht. Der md5-Hash waere einfach der neue Zugangscode, und er liegt im Klartext vor (wenn jemand an der Leitung mitlauscht, meine ich).

Aber Digest Auth funktioniert anders. Der Webserver gibt dem Client eine staendige wechselnde Zeichenkette vor (nonce value). Der Client bildet dann die md5-Summe ueber diese nonce value zusammen mit Benutzernamen, Passwort, angeforderter URL und der HTTP-Methode. Wegen der staendig wechselnden nonce value aendert sich auch die md5-Summe immer wieder und kann also nicht wiederverwendet werden. Rueckschluesse auf die Klartext-Zugangsdaten sind auch nicht moeglich.

So long