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