Sven Rautenberg: SHA1 Verschlüsselung: Verständnisfrage

Beitrag lesen

Moin!

Im Prinzip mache ich mir gerade Gedanken, einen Benutzer an einem Server zu authentifizieren. Grundsätzlich bastle ich also die Sessions von Php nach - nur dass die Session-Id jedesmal anders sein soll, weil mir eine statische Session-Id zu anfällig erscheint.

Warum? Benutzername und Passwort sind auch statisch - wer das kennt, kommt rein, egal ob er erwünscht oder unerwünscht ist. Und irgendwann einmal MUSS diese Information zum Server gesendet werden.

Eine Session-ID ersetzt nun für eine gewisse Zeit die Info "Username+Passwort", das bedeutet: Man tauscht den einen String (wenn man Username und Passwort einfach mal zusammensetzt, ergibt sich daraus eine Zeichenkette, die "stimmen" muß, um Zugang zu erlangen) durch einen anderen String (der für eine gewisse Zeit Synonym für Username und Passwort wird) - an einer Tatsache aber ändert sich nichts: Wenn man dem Server als Angreifer den richtigen String schickt, wird dieser Informationen rausrücken.

Der Server schickt bei jeder Antwort eine (jedesmal andere zufällige) Session-Id für den Benutzer mit. Der Benutzer verschlüsselt mit seinem Passwort bei der nächsten Antwort die Id - der Server entschlüsselt diese wieder und kontrolliert, ob es sich dabei um die zuletzt gesandte Id handelt. In der Antwort schickt er dann wieder eine neue Id mit. usw.

Das hilft dir alles nichts, wenn du unverschlüsselt arbeitest. Denn wenn du unverschlüsselt arbeitest, kann man die legitime Kommunikation immer noch mitlesen, muß also gar nicht selbst aktiv werden. Oder man baut dein komplexes Machwerk nach, bzw. erhält irgendwie Zugang zu deinem Client - und schon bricht dein ganzes schönes Konstrukt zusammen.

Glaube mir: Es bringt dir nichts, den Sessionmechanismus bzw. dessen ID-Wechsel zu manipulieren. Wenn dir die MD5-IDs (128 Bit) nicht gefallen, weil sie dir angeblich zu kurz sind, dann verwende einfach längere. SHA-1 bietet sich an (160 Bit), alternativ SHA-256, SHA-384 oder SHA-512 (jeweils soviele Bits, wie in der Nummer angegeben).

Das Prinzip scheint für mich OK - das Handling eher nicht so, da ich dafür jedesmal die Session-Daten des Benutzers aus einer DB auslesen und auch neu setzen muss. Bei tausenden Benutzern kommt da schon für das Session-Handling allerhand zusammen :-(

Das Prinzip ist auch Müll. Wenn du Sicherheit haben willst, verwende SSL. Dann kann keiner die Kommunikation abhören.

Und gegen die bösen Buben, die dann eben per SSL mit deinem Server kommunizieren, verwendest du vernünftige Passworte.

Der Session-Mechanismus ist jedenfalls nicht dein Problem.

- Sven Rautenberg

--
"Love your nation - respect the others."