Welche authentifizierungs Lib

[TDO]

Hi,

ich bastel grad an ner Website mit Werkzeug... nun bin ich an dem Punkt wo ich ein Login-System brauche... ich meine mal gelesen zu haben das es wohl schon fertige libs gibt welche einem die Benutzerverwaltung und Erstellung bissle abnehmen.

Wollte mal fragen ob ich da recht gehoert hab bzw. welche Ihr mir empfehlen koenntet..

Danke und gruessle
TDO

[Dauerbaustelle]

User-Model mit Secure-Session-Cookie. Einfach mal im werkzeug-Source nachlesen (oder in der Doku).

Gruß

[Leonidas]

Darüber hinaus gibt es auch AuthKit und Barrel.

[lunar]

Und repoze.what ...

[TDO]

und mit welcher habt ihr schon gearbeitet? bzw. als gut befunden?

[Dauerbaustelle]

Oben erwähntes, ganz einfach deswegen, weil ich da wenigsten Doku lesen musste... aber halt ein bisschen was selbst implementieren.

Damals mit werkzeug ging das so: In die WSGI-Klasse folgendes in die dispatch-Methode:

Code: Alles auswählen

if request.cookies.should_save:
        cookies = request.cookies.serialize()
        response.set_cookie('session', cookies, httponly=True)
        # safe cookie

Wobei `self.cookies` (`request.cookies`) eine Instanz der `werkzeug.contrib.securecookie.SecureCookie`-Klasse ist.

Die Überprüfung ob man eingeloggt ist hab ich dann so gemacht:

Code: Alles auswählen

def authenticate_user(request):
    try:
        name, password = request.cookies.get('session', (None, None))
    except ValueError, e:
        name, password = None, None
    if name and password:
        user = User.query.filter_by(name=name).first()
        if user and user.password == password:
            return user

Wobei `User` das User-Model ist (SQLAlchemy-Model).

[lunar]

Mmmh, sonderlich gut ist das aber nicht, da bei jedem Request ein Datenbankzugriff und ein möglicherweise teurer (falls Hashing involviert ist) Passwortvergleich stattfindet. Bei einem Cookie, dessen Werte durch einen serverseitigen Schlüssel gesichert sind, muss man das Passwort nicht erneut prüfen, weil die Existenz des Cookies bzw. der Benutzerkennung im Cookie an sich als Beweis der Identität ausreicht. Schließlich kann man den Keks dank des serverseitigen Schlüssels nicht fälschen oder manipulieren.

Sinnvoller wäre es daher, einfach nur Benutzername, Anmeldedatum (für zeitlich limitierte Sitzungen) und evtl. IP-Adresse im Cookie zu speichern und zu sichern.

Vor allem aber hast du damit nur die Authentifizierung, nicht aber die Authorisierung erledigt, es sei denn, deiner Anwendung genügt es zu wissen, dass der Nutzer nicht anonym ist. Berechtigungen, Rollen und Gruppen musst du bei deinem Ansatz ebenfalls manuell implementieren, was der größere Teil der Arbeit ist.

Ich persönlich nutze repoze.what-quickstart. Damit ist eine WSGI-Middleware, die eine Webform-Authentifzierung gegen eine SQLAlchemy-Benutzerklasse mit sicherem Cookie für die Session bereitstellt, mit einem Funktionsaufruf aufgesetzt. Berechtigungen und Gruppen gibts für lau dazu, außerdem integriert sich das Ganze wunderbar in Pylons.

Bei Interesse kann ich dir morgen auch gerne eine kleine Beispielanwendung dazu zusammenprogrammieren.

[TDO]

also interesse wäre meinerseits da... auch wenn ich wohl nicht gemeint war

[lunar]

Natürlich warst du gemeint, wer denn sonst? Du hast schließlich gefragt

Allerdings habe ich heute keine Zeit mehr dafür, du musst dich bis morgen Abend gedulden.

[TDO]

hehe kein Thema .. dachte du hast Dauerbaustelle gemeint weil dir ja seine Implementierung nicht gefallen hat.

[Dauerbaustelle]

Mmmh, sonderlich gut ist das aber nicht, da bei jedem Request ein Datenbankzugriff und ein möglicherweise teurer (falls Hashing involviert ist) Passwortvergleich stattfindet.

Hashing ist natürlich nicht nötig; ich hoffe doch, dass jeder, der Passwörter speichert, dies in bereits gehashter Form tut...

Bei einem Cookie, dessen Werte durch einen serverseitigen Schlüssel gesichert sind, muss man das Passwort nicht erneut prüfen, weil die Existenz des Cookies bzw. der Benutzerkennung im Cookie an sich als Beweis der Identität ausreicht. Schließlich kann man den Keks dank des serverseitigen Schlüssels nicht fälschen oder manipulieren.

Hm, ich weiß grade garnicht wie der Cookie erzeugt wird. Müsste ich mir bei Gelegenheit mal ansehen.

[Dauerbaustelle]

Hab mir das mal angeguckt. Der Keks wird durch (Pseudocode!) `base64(secretkey, passwort, username))` erzeugt. Da der Secret-Key wirklich secret ist, müsste ich das nicht mehr überprüfen, weil der Key ja nie rausgegeben wird und somit Manipulation unmöglich ist. Aber für den Fall, dass jemand zufällig eine passende Zeichenkette (welche das Ganze sinnvoll entschlüsselt) erzeugt....*ausred*

[lunar]

Mmmh, sonderlich gut ist das aber nicht, da bei jedem Request ein Datenbankzugriff und ein möglicherweise teurer (falls Hashing involviert ist) Passwortvergleich stattfindet.

Hashing ist natürlich nicht nötig; ich hoffe doch, dass jeder, der Passwörter speichert, dies in bereits gehashter Form tut...

Bei der Anmeldung aber wird das Passwort meist im Klartext übertragen, daher wäre es denkbar gewesen, dass das Passwort im Klartext im sicheren Cookie abgelegt wird. Wenn die Werte des Cookies nicht nur durch einen Hash gesichert, sondern wirklich verschlüsselt sind, wäre das nicht unbedingt ein Nachteil gewesen.

[Dauerbaustelle]

Bei dem Beispiel kommen die Passwörter als Hash.

[nemomuk]

Ist es eigentlich sinnvoll das Passwort auf Clientseite per JavaScript schon zu hashen und dann per AJAX an den Server zu schicken? Hätte ja eigentlich den Vorteil, dass das Passwort nicht Plaintext duch's Netz geht (wenn man kein SSL hat).

[Dauerbaustelle]

Ist es eigentlich sinnvoll das Passwort auf Clientseite per JavaScript schon zu hashen und dann per AJAX an den Server zu schicken? Hätte ja eigentlich den Vorteil, dass das Passwort nicht Plaintext duch's Netz geht (wenn man kein SSL hat).

Jop, finde ich sehr sinnvoll (halt kein SHA1 und MD5, die werden langsam alt...). Für deaktiviertes JS ggf. noch auf dem Server überprüfen, ob das jetzt ein Hash ist oder nicht.

[lunar]

Denkt mal kurz darüber nach, woher der Javascript-Code kommt und ob er vertrauenswürdig ist ...

[Dauerbaustelle]

Wo ist das Problem? Wenn ich den Schlüssel nachher serverseitig validiere ist das einzige, was passieren kann, dass ich eine falsche (nicht ungültige!) Hashsumme habe. Das macht mir nichts, nur dem User ;)

[apollo13]

Und was für einen Unterschied macht es nicht ob nen „man in the middle“ den Hash oder das Klartextpasswort hat? Genau: Keinen, einloggen kann er sich mit dem einen so wie den anderen…

[Dauerbaustelle]

Er kennt aber das Plaintext-Passwort nicht. Und wenn man abwägt, dass man mit Plaintext-Auth keine Vorteile und mit Hashauth mindestens diesen einen, dann weiß man auch schon, was man verwenden sollte ;)