User Autentifizierung - was ist das? Es geht darum, einen User, der beispielsweise in einem Forum einen Beitrag erstellen möchte, oder in einem Blog, als solchen zu identifizieren und angemessen zu authorisieren.

Eine funktionierende Authentifizierung muss dabei zweierlei Aufgaben bewältigen:

  1. Zunächst muss eine sichere Korrelation hergestellt werden zwischen einem Usernamen und einer realen Person.
  2. Es muss sicher gestellt werden, dass die Person, die den Beitrag verfasst, auch die Person ist, die sie zu sein vorgibt.

Es gibt dazu verschiedene Ansätze. Die gängigste ist eine Registrierung in dem Forum oder dem Blog. Der Nachteil ist, dass der Foren- oder Blogbetreiber notwendigerweise eine Menge Nutzerdaten speichern muss. Dies ist aus Datenschutzgründen sowie aus Sicherheitsgründen ein Problem. Darüberhinaus kann sich nur ein Nutzer unter einem Usernamen registrieren. Mehrere Nutzer mit dem gleichen Usernamen sind nicht möglich.

Der hier vorgestellte Ansatz ermöglicht nicht nur die Nutzung von Foren, Blogs und ähnlichen Diensten mit beliebigen Usernamen, auch gleichen Usernamen für verschiedene Personen, sondern vermeidet auch vollständig die Speicherung der Nutzerdaten auf dem fremden Server. Jeder Nutzer hält seine eigenen Nutzerdaten auf seinem eigenen Webspace vor. Eine Speicherung durch Dritte wird komplett vermieden.

Der hier vorgestellte Ansatz basiert auf den Ideen zu microid, erweitert dieses Konzept jedoch um einen entscheidenden Teil. Das hier vorgestellte Konzept soll nicht dazu dienen, die übliche Prozedur einer Authentifizierung zu ersetzen. Diese Prozedur wird vollständig und ohne Änderung beibehalten. Lediglich die Registrierung und die Speicherung der Nutzerdaten entfällt vollständig.

Ebensowenig ist dieser Ansatz eine Alternative zu openID. Letzteres adressiert die "single sign-on" Problematik (also, sich nur einmal auf einer Site einzuloggen, und damit auf vielen weiteren Sites automatisch ebenfalls angemeldet zu sein). Dieser Ansatz hier versucht kein "single sign-on".

Aufbau der ID

Wie bei microid besteht die eigene Identität aus einer Prüfsumme, die aus zwei oder mehr Komponenten gebildet werden kann. Im Gegensatz zu microid ist jedoch zwingend eine der Komponenten ein Passwort. Dieses Passwort stellt sicher, dass der User, der einen Beitrag veröffentlichen möchte, auch der ist, der er zu sein vorgibt. Der generelle Aufbau einer ID gestaltet sich also, analog zu microid, wie folgt:

Komponente1+Komponente2+password:Methode:Prüfsumme

Dabei sind die einzelnen Komponenten wie folgt definiert:

Die Reihenfolge der Komponenten einschließlich des Passworts kann beliebig sein! So sind alle folgenden Möglichkeiten valide:

Komponente1+Komponente2+password:Methode:Prüfsumme Komponente1+password+Komponente2:Methode:Prüfsumme password+Komponente1+Komponente2:Methode:Prüfsumme

Benutzername

Diese ID kann optional auf einen bestimmten Benutzernamen beschränkt werden. Wenn sie nicht beschränkt ist auf einen Benutzernamen, kann die Zuordnung zu einer Person ausschließlich über die anderen Komponenten vorgenommen werden, zum Beispiel die URL.

Generierung

Die ID kann zum Beispiel wie folgt generiert werden:

#!/bin/bash MAILTO=`echo "mailto:siegfried@rorkvell.de" | sha1sum | cut -d' ' -f1` HTTP=`echo "http://www.rorkvell.de/" | sha1sum | cut -d' ' -f1` PW=`echo -n "ganzgeheim" | sha1sum | cut -d' ' -f1` ID=`echo -n "$MAILTO$HTTP$PW" | sha1sum | cut -d' ' -f1` echo "<meta name=\"myID:Siegfried\" content=\"mailto+http+password:sha1:$ID\" />"

Veröffentlichung

Die eigene ID wird veröffentlicht auf einer Webseite. Unter der Annahme, dass nur der Besitzer einer Webseite diese auch ändern kann, ist sicher gestellt, dass die Person X auch diejenige ist, der die Webseite gehört. Die Veröffentlichung sollte ganz ähnlich wie bei microid vorgenommen werden:

meta name="myID" content="Komponente1+Komponente2+password+Methode:Prüfsumme / meta name="myID:Joker" content="Komponente1+Komponente2+password:Methode:Prüfsumme /

Die erste Variante stellt keine Beziehung zu einem bestimmten Usernamen her. Die zweite Variante korreliert diese ID mit dem Usernamen "Joker". Es sind beliebig viele solcher Angaben mit verschiedenen Usernamen möglich, so lange die Usernamen verschieden sind. Eine Angabe ohne Usernamen ist dabei ein Fallback, ein Sammelschlüssel für alle möglichen sonstigen Usernamen (des Besitzers dieser Webseite).

Indirektion

Es ist möglich, die ID nicht in der Web Resurce zu führen, die im Kommentarformular angegeben wurde, sondern stattdessen dort auf die Web Resource mit dieser ID zu verweisen. Dazu dient das link Element:

link rel="myID" href="https://www.rorkvell.de/priv/auth" /

Der Vorteil solch einer Indirektion kann sein, im Kommentar einen Link auf z.B. die eigene Startseite oder das eigene Blog einzutragen, die Datei mit den IDs zentral unabhängig davon an anderer Stelle zu halten. Desweiteren erübrigt sich dadurch die Notwendigkeit, die URL im Kommentarformular auch immer genau so einzugeben, wie sie zur Bildung der ID eingegeben wurde. Zur Bildung der ID wird die URL der Web Resource verwendet, in der auch die IDs stehen. Dazu muss diese URL im link genau so enthalten sein, wie sie zur Bildung der ID verwendet wurde.

Authentifizierung

Scenario

Nehmen wir an, eine Person X mit dem Usernamen ypsilon will einen Kommentar zu einem Blogbeitrag verfassen. Dazu gibt diese Person im Kommentarformular neben dem Kommentar zumindest ein Passwort und eine URL an.

Server Aktionen

  1. Der Server lädt zunächst die Webresource, die mit der URL angegeben wurde. In dieser Webresource (generell eine HTML- oder XHTML-Seite) wird nun nach der Metaangabe mit einem Namen der Form "myID:ypsilon" oder "myID". Wenn eine Metaangabe mit passendem Usernamen gefunden wird, dann wird diese zur Auswertung herangezogen. Wenn nicht, wird die Angabe ohne Usernamen verwendet.

    Anmerkung: Formatspezifikationen für andere Dateiformate wie RDF stehen noch aus.

  2. Wenn statt der ID ein Verweis auf die Web Resource, die die ID enthält, gefunden wird, so wird eben diese geladen und bei Punkt 1 fortgesetzt.
  3. Wenn das Laden wegen fehlender Authorisierung scheitert, ist diese Web Resource vermutlich passwort geschützt. In diesem Fall kann versucht werden, diese Datei zu laden unter Angabe der eingegebenen User Name und Passwort. Falls dies gelingt, muss die ID in dieser so geschützten Web Resource nicht mehr notwendigerweise die password Komponente enthalten. In diesem Fall reduziert sich der Aufwand auf die Verwendung einer normalen microid. Bei so geschützten Web Resourcen kann also auch alternativ eine microid verwendet werden.
  4. Aus der gefundenen ID wird nun die Bildungsvorschrift extrahiert. Die Bildungsvorschrift ist das erste durch ":" getrennte Feld des Inhalts des "content" Attributes. Die einzelnen Felder der Bildungsvorschrift sind durch "+" getrennt.
  5. In der in der Bildungsvorschrift angegebenen Reihenfolge werden nun die Komponenten zunächst einzeln gehashed, danach werden die Hashsummen in genau dieser Reihenfolge aneinander gehängt und davon ebenfalls der Hashwert berechnet.
  6. Zur Bildung der Prüfsummen wird das im vorletzten Feld angegebene Verfahren verwendet.
  7. Stimmt das berechnete Ergebnis mit der auf der Webseite gefundenen überein, kann der User als authentifiziert gelten. Eine eventuelle Authorisierung kann dann anhand lokaler Regeln erfolgen.
  8. Das eingegebene Passwort sollte nur zur Prüfung einmal verwendet werden und danach nicht gespeichert werden! Der Server sollte das Psswort nach der User Identifikation (erfolgreich oder nicht) sofort löschen.

Spamschutz

Eine konsequente Anwendung dieses Verfahrens verhindert nicht direkt Spambeiträge. Da die Verfasser der Beiträge aber identifizierbar werden, können Spambeiträge eventuell in Rechnung gestellt werden.

Zusammenfassung

Weiterführende Ideen

Folgende Ideen sind lediglich als Anregung hier aufgeführt und nicht Bestandteil dieser Spezifikation: