@Nephtyz:
Angeregt von Deinem Artikel hab ich über das Problem auch bei mir nachgedacht und muss sagen, dass die Lösung mMn nicht so einfach ist, ohne dass man Gefahr läuft, dass sich Benutzer als andere Benutzer ausgeben. Immerhin hab ich den Vorteil, dass meine Anwendung Server-basiert ist, d.h. jede Aktion auf dem Server berechnet wird, geprüft werden kann und dabei eine Authentifizierung anhand der Credentials/SessionID durchführen kann. Wenn sich aber jemand durch Man-In-the-Middle oder Network-Sniffing die Daten abfängt, kann er immer auch sich als der Benutzer ausgeben. Es sei denn ich fang jetzt mit SSL und Public-/Privatkeys an. Das Sessionobjekt könnte seine SessionID von Anfrage zu Anfrage auf Zufallsbasis modifizieren. Evtl. hilft das dann, dass ein "Eindringling" max. 1 Aktion als der andere Benutzer auführen kann.
Bei deiner P2P-Anwendung muss ich ja auch nur den Benutzer kennen und dann im lokalen Speicher die Stelle des Datenbereichs der Anwendung wo der Benutzer abgelegt ist überschreiben und schon bin ich ein anderer. Ich nehme mal an dass du Strings verwendest, um den Benutzer zu speichern, da könnte ich mir vorstellen, dass das evtl. gar nicht schwierig rauszubekommen ist. Die Bindung der Session an einen Socket mag da helfen.
Letzten Endes ist das alles Kokollores, wenn die Benutzer nicht sorgfältig mit Ihrer e-Mail, ihrem Passwort und Benutzernamen umgehen.