DotNetNuke speichern von Zugangsdaten der Benutzer

DotNetNuke bietet drei Möglichkeiten die Passwörter von Benutzern zu speichern. Diese können im Klartext, als verschlüsselte Zeichenfolge oder als Hashwert in der Datenbank gespeichert werden. Das die erste Variante höchtens für Test- und Entwicklungsinstallationen in Frage kommt, muss wohl nicht weiter diskutiert werden. Konfiguiert wird die Behandlung von Passwörtern in der web.config direkt bei den Einstellungen des MembershipProvider:

<add name="AspNetSqlMembershipProvider" 
    type="System.Web.Security.SqlMembershipProvider" 
    connectionStringName="SiteSqlServer" 
    enablePasswordRetrieval="true" 
    enablePasswordReset="true" 
    requiresQuestionAndAnswer="false" 
    minRequiredPasswordLength="7" 
    minRequiredNonalphanumericCharacters="0" 
    requiresUniqueEmail="false" 
    passwordFormat="Encrypted" 
    applicationName="DotNetNuke" />

Worin besteht aber der genau Unterschied zwischen veschlüsselt und hashed?

Verschlüsselte Zeichenfolgen

Bei diesem Modus werden die Passwörter durch einen Verschlüsselungsalgorithmus unleserlich gemacht, so das bei einem Auslesen der Tabelle, die Passwörter nicht im Klartext zur Verfügung stehen. DotNetNuke bzw. jedes DNN-Module ist in der Lage die Passwörter ohne Probleme zu lesen.

Hashwerte

Wenn man als Modus "Hashed" wählt, dann wird nur ein Hashwert vom Passwort abgespeichert und nicht das eigentliche Passwort. Aus dem Hashwert kann man das Passwort nicht mehr in Klartext umwandeln und somit hat auch kein Module mehr Zugriff auf die Passwörter. Das bedeutet aber auch, dass die "Passwort zusenden"-Funktion nicht mehr das Passwort dem Benutzer zur Verfügung stellen kann. Ob das eine Anwendung überhaupt machen sollte ist eine ganz andere Diskussion. Die Funktion "Passwort vergessen" funktioniert aber natürlich trotzdem, in diesem Modus wird von DotNetNuke einfach ein neues Zufallspasswort erzeugt.

Welche Variante

Es gibt keine klare Empfehlung für eine der verfügbaren Methode. Für die Auswahl sollten im Vorfeld Überlegungen angestellt werden, ob man das Passwort wirklich jemals im Klartext benötigt. Aus der Perspektive eines Datenschützers wäre eigentlich nur die Möglichkeit "als Hashwert" akzeptable.


Kommentar schreiben