Wie sicher ist diese Login-Idee???

[Sven Rautenberg]

Moin!

• Username, Passwort und eine 32-stellige Userkennung liegen in einer Datenbank

Wozu die Kennung?

• Vor dem Checken der Daten wird aus Username, Passwort und einem serverseitig generierten md5-Hash eine Kennung generiert (ebenfalls ein md5-Hash). Danach werden Username und Passwort auf leer gesetzt, das heißt sie werden gar nicht übertragen. Das ganze geschieht schon clientseitig und zwar mit einem Javascript.

Hier sehe ich zwei problematische Stichwörter: "clientseitig" und "javascript".

Stimmen die Daten

$usereingabe=$_POST[usereingabe];
$datenbank= md5($user).md5($passwort).md5($_POST[hash]);

if($usereingabe==$datenbank) {

dann wir ein Temp-Cookie gesetzt, das einen Timestamp enthält (für Auto-Logout) und die 32-stellige Userkennung, anhand derer der User dann getrackt werden kann.

Hier sehe ich wieder zwei problematische Stichwörter: "temp-cookie/timestamp" und "auto-logout".

Ich denke die Idee ist schon sicher (bestimmt ebenso sicher wie .htaccess?) aber was sagt ihr dazu? Gibts noch Lücken? SSL fällt leider flach. Auch überlege ich mir gerade eine Lösung mit 401-Headern also PHP-Auth.

Du willst versuchen, die Übertragung von Username und Passwort im Klartext zu verhindern? Vergiß es! Ohne richtige Verschlüsselungsebene wirst du niemals die Sicherheit von SSL hinkriegen. Wirklich! Glaub mir.

Akzeptiere, dass eine Klartextübermittlung immer genau das ist: Eine Klartextübermittlung. Dabei ist es relativ egal, ob du clientseitig mit Javascript rumwerkelst, oder nicht. Javascript ist öffentlich, man kann nachvollziehen, was du da rumwerkelst. Und das Ergebnis wird im Klartext übermittelt, d.h. wenn ein unbefugter Zugriff haben will, muß er nur das Recheneregebnis übermitteln (das er im Klartext abgefangen hat), und schon ist er drin.

Soviel zum problematischen Stichwort "clientseitig".

Zu "javascript": Du solltest dich auf Javascript nie verlassen.

Zu "temp-cookie/timestamp": Dir ist bekannt, dass die Angabe des Verfallsdatums lediglich eine empfehlende Wirkung auf den Client hat? Er _kann_ den Cookie danach verfallen lassen. Er muß es aber nicht.

Zu "auto-logout": Sowas regelst du doch besser serverseitig, anstatt dich auf das Nichtvorhandensein von zeitlich begrenzten Cookies zu verlassen.

Summa summarum: Du hast viel komplexes Zeugs erfunden, nur um ein schlechteres System zu erhalten, als PHP es dir mit seinen Sessions von Hause aus bieten kann. Warum also der Aufwand?

- Sven Rautenberg