Dubu+2008-10-20 21:33:18--

Was spricht gegen Sessionkey + gemeinsame Datenbank?

Das Ploblem ist der Zugriff. Die Systeme sollen ja nicht alle auf dem selben Rechner laufen. Datenbankzugriffe übers Netz würden mir Bauchschmerzen machen, da so was ein beliebtes Ziel für Angriffe ist. Man könnte die Datenbank hinter einem Script verstecken, aber für dieses braucht man dann wieder eine Benutzerkennung und Zertifizierung. Man könnte über ssh tunneln, aber das wird von einigen Hostern nicht gerne gesehen. Auch die Bandbreite könnte unter Umständen ein Problem darstellen.

Hagen+2008-10-20 21:24:09--

Mmmh ... interessant, dass du die IP (mit) zur Identifizierung nutzten willst. Ich hatte auch darüber nachgedacht, es dann aber schnell wieder verworfen, da mehrere Benutzer die gleiche IP haben können (wg. Proxy, ...).

Eindeutig ist ja nicht die IP sondern "Name + IP + Passwort". Und ich halte es für reichlich unwahrscheinlich, das sich zwei verschiedenen Benutzer über den selben Namen von der selben IP aus mit dem selben Passwort anmelden. Wenn noch was sicherer sein willst kannst du z.B. noch eine md5Summe über die Browser-Kennung machen und mitschicken. (in so ein Cookie passt viel rein :-) )

Hagen+2008-10-20 21:24:09--

Also dein Vorschlag wäre (von der Idee her):

Code: (dl )

1
2
3
4
5
6

index.cgi?action=login&sid=$sid

mit

$timestamp = localtime()
$sid = GCrypt($benutzer_id.'-'.$ip.'-'.$timestamp, 'Schlüssel')

ja so in der Art.
Man kann das noch etwas Verfeineren.

Das "pack('C', int rand 255)" fügt eine ein Byte Zufallszahl hinzu. Das macht das Knacken schwerer
Mit dem "$applicationkey" weißt du wo sich der Nutzer eingeloggt hat. Das ist ganz Sinnvoll, wenn Leute von bestimmten Systemen nicht überall hin dürfen. Kann ein Login von einer Adminseite einen anderen Applikationkey tragen, als der von einem Guestlogin.
Es ist damit auch ersichtlich, das sich der Nutzer woanders Eingeloggt hat, und er unter Umständen nicht ganz so "vertrauenswürdig" ist wie einer, der sich auf dem eigenen System eingeloggt hat.
Mit dem md5-verschlüsselten Passwort kann auch noch nachträglich nach dem Passwort gefragt werden. z.B wenn der User wichtige Daten löschen will.
"$version" beschreibt welcher Schlüssel verwendet werden soll. Das ist nötig, da der Schlüssel regelmäßig ausgetauscht werden sollte. (je nach Wichtigkeit, alle 2Monate bis einmal im Jahr)
Base64 solltest du nutzen, damit die Daten nicht bei der Übertragung oder dem Zwischenspeichern im Browser verstümmelt werden.

Hagen+2008-10-20 21:24:09--

Irgendwie habe ich immer darüber nachgedacht, dass ich zum "verschlüsseln" z.B. md5 anwende. Nur zum entschlüsseln (mir ist klar, dass man md5 nicht rückgängig machen kann) hatte ich keine (gute) Idee.

Der Vorteil ist, das der Nutzer all seine wichtigen Daten mitbringt. Ein System braucht den Nutzer gar nicht zu kennen. Es muss nur der Verschlüsselung trauen können. Mit den übergeben Daten könnte auch ein minimaler Account angelegt werden.

Aber ich will hier nicht in einer Featuritis ausbrechen :-)