Vor ungefähr drei Monaten hatte ich mir schon mal Gedanken zu den Schwierigkeiten der MicroID-Verifizierung gemacht:

Eine URL kann man auf zu viele verschieden Weisen schreiben, als dass sie eine valide ID abgeben könnte.

Schwierigkeiten bereiten die Seiten, die unterschiedliche URLs zulassen…

  • http://example.com
  • http://www.example.com
  • http://example.com/

…da sie zusammen mit der E-Mail – Adresse drei unterschiedliche Hash-Werte ergeben.

Ein möglicher Lösungsansatz wäre eine URI-Normalisierung, wie sie z.B. OpenID vorschlägt, einzusetzen.

Eine viel einfachere und fehlerunanfälligere Lösung ist das dynamische zusammenbauen der MicroID über die direkt aufgerufenen URI als Identifier:

  • http://example.com -> 19358536d8c443614bc7d861f4b050ee34a549b9
  • http://www.example.com -> 05c732700bfa89cd234bb7fc08cb673f7c0d88b8
  • http://example.com/ -> 9275b4dcd7cc2c997b2a5249420b422e937d36e0

(Benutzte E-Mail – Adresse: mustermann@example.com)

Beim verifizieren bräuchte man sich also nur noch auf die E-Mail – Adresse konzentrieren anstatt alle in Frage kommenden URI/E-Mail – Kombinationen durchspielen zu müssen.

15 Kommentare zu “MicroID ohne URI-Normalisierung

  1. Hi,
    Du hast zwar Recht mit der URL, aber trotzdem glaube ich, Du verwechselst da was. Die URL wird doch von Demjenigen eingegeben, der eine solche Verifizierung wünscht. Derjenige weiss doch, welche URL er selber dafür benutzt hat, um den Hashwert zu bilden. Es liegt also schlicht in dr Verantwortung Desjenigen, in einem Formular die URL auch genau so einzugeben, wie er das getan hat, als er den Hashwert gebildet hat. Das ist ähnlich wie ein Passwort. Wenn man sich bei einem Buchstaben im Passwort vertippt, geht das eben auch schief. Genauso hier.

    Ein Dienst, der eine Verifizierung über URL und e-mail Adresse vie MicroID vornimmt, braucht nur die Eingaben, so, wie sie vom Benutzer kommen, entsprechend zu verwenden. Und zwar genau so, wie sie kommen. Wenn eine Verifizierung fehlschlägt, dann hat sich der Benutzer z.B. bei der URL vertippt. Kann ja vorkommen.

    Der Benutzer weiss jedoch, wie die eigene URL richtig einzutippen ist. Von einer Normierung würde ich daher absehen. Es sollte lediglich darauf hingewiesen werden, dass der Benutzer bei der Erstellung seiner MicroID auf genau diese Dinge achtet. Dass er also seine URL in Formularen auch genau so eintippt, wie er sie zur Bildung der MicroID eingetippt hat. Nichts weiter.

  2. Hallo Siegfried,

    In deinem Fall (User erstellt seine MicroID selbst) hast du natürlich recht, aber dieser Idealfall trifft leider nicht immer zu.

    Nehmen wir das Beispiel myBlogLog:

    Die MicroID bei myBlogLog wird automatisch generiert, da kann ich nichts dran drehen und ich weiß (leider) auch nicht mit welcher URL sie generiert wurde (mit „www“ ohne „www“ mit Trailing Slash oder ohne). Nehmen wir an myBlogLog verwendet folgende URL hardcoded für meine MicroID:

    https://web.archive.org/web/20110415105452/http://www.mybloglog.com:80/buzz/members/pfefferle/

    Ich benutze aber (weil ich es nicht besser weiß) die URL ohne den Trailing Slash:

    https://web.archive.org/web/20110415105452/http://www.mybloglog.com:80/buzz/members/pfefferle/

    um sie bei ClaimID zu claimen. Die URL lässt sich problemlos aufrufen, kann aber durch den fehlenden Trailing Slash nicht verifiziert werden.

    Deshalb mein Vorschlag die URL immer so zu verwenden wie sie aufgerufen wurde…

  3. Ah so. Gut, in dem Fall stimmt das.

    Eine gewisse Normierung könnte nicht schaden. Also einen trailing slash hinzufügen wäre nicht verkehrt. Und ggf. ein Protokoll wie http:// hinzuzufügen wäre auch nicht falsch. Alle weiteren Normierungen würde ich eher als kontraproduktiv ansehen.

    Die Korrekte Form einer URL müsste dann aber in die Spezifikation mit rein.

    Was meinst Du konkret mit „immer so verwenden, wie sie aufgerufen wurde“? Was heisst aufgerufen? Von wem wo wie?

  4. Naja, dass die MicroID nicht immer mit er URL:

    https://web.archive.org/web/20110415105452/http://www.mybloglog.com:80/buzz/members/pfefferle/

    gebildet wird, sondern immer mit der URL die ich zum verifizieren angebe.

    Gebe ich bei ClaimID die URL: https://web.archive.org/web/20110415105452/http://www.mybloglog.com:80/buzz/members/pfefferle/ an, soll MyBlogLog die URL https://web.archive.org/web/20110415105452/http://www.mybloglog.com:80/buzz/members/pfefferle/ verwenden, geb ich die URL: https://web.archive.org/web/20110415105452/http://www.mybloglog.com:80/buzz/members/pfefferle/ soll MyBlogLog diese URL verwenden.

    MyBlogLog erkennt ja über welche URL ich auf die Seite gekommen bin…

    Somit wäre keinerlei Normalisierung notwendig…

  5. Hmmm, anscheinend habe ich noch größere Verständnisschwierigkeiten, was eine solche Art der Authentifizierung angeht.

    Zunächst mal geht es ja darum, dass ich als User „Siegfried“ irgendwo einen Kommentar eintragen will. Dazu gebe ich im Kommentarformular u.A. meine e-mail Adresse und die URL zu meiner HP ein. Jetzt ist die Frage, was der Server, der diese Daten erhält, macht.

    Ich denke mal, er lädt die Seite der angegebenen URL. Dort findet er die Metaangabe und weiss so, wie er die Prüfsumme zu bilden hat, und weiss, wie das korrekte Ergebnis lauten muss. Er bildet nun diese Prüfsumme wie in der Metaangabe angegeben, und vergleicht das Ergebnis mit der Vorgabe.

    Stimmen Beide überein, weiss der Server, dass ein User Namens „Siegfried“ in der Tat Eigentümer der Seite ist, die unter URL angegeben wurde. Was er jedoch nicht weiss, ist, ob der Kommentator auch tatsächlich derjenige ist, der er zu sein vorgibt. Jeder X-Beliebige könnte sich aus einem meiner Kommentare die URL zu meinr HP rausfischen. Dort findet er einen Link zu meinem Impressum und dort meine e-mail Adresse. Nun hat er beide Informationen, um sich als ich auszugeben.

    Ich denke mal, hier kommen jetzt irgendwie diese externen Dienste wie ClaimID ins Spiel. Wie eigentlich?

    Dabei wäre die Lösung eigentlich super simpel. Man müsste die ID aus 3 Komponenten aufbauen. Eine davon muss ein selbst gewähltes Passwort sein. Dieses wird nirgendwo gespeichert, steht also einem ID-Klauer nicht zur Verfügung. Der Server bildet die Prüfsumme mit allen drei Komponenten, und wenn’s stimmt, kann das Passwort sofort wieder vergessen werden.

  6. So wie du das Szenario schilderst gibt es in der Tat wenig Schutz, da ich ja wirklich einfach jede E-Mail – Adresse ausprobieren kann. Die Absicherung sollte deshalb auf Serverseite passieren.

    Deshalb ist (nach meinem Verständnis) MicroID so ausgelegt, dass nur verifizierte E-Mail – Adressen verwendet werden sollten. Das ist in einem Blog (wie meinem) ein Problem, da jeder eine x-beliebige E-Mail – Adresse angeben kann.

    Bei ClaimID läuft das z.B. anders, hier musst du dich zuerst anmelden und deine E-Mail – Adresse verifizieren (ClaimID schickt dir ne E-Mail mit Bestätigungslink). Wenn ClaimID jetzt die URL zu deinem Blog und deine verifizierte E-Mail – Adresse nimmt um die MicroIDs zu vergleichen, kann man davon ausgehen dass es auch wirklich dein Blog ist…

  7. Hmmm, nein, kann man nicht. Das Einzige, das man zusätzlich weiss, ist, dass die e-mail Adresse existent ist.

    Nach wie vor könnte jeder in einem beliebigen Blog unter meinem Namen einen Kommentar verfassen, indem er meine korrekte und verifizierte und öffentlich zugängliche e-mail Adresse angibt, sowie meine URL, die aus jedem meiner Blogkommentare herausgefischt werden können. Dass die e-mail Adresse durch ClaimID als existent verifiziert wurde, hilft hier nicht wirklich weiter.

    Zum Beweis, dass der User vor dem Bildschirm, der da gerade kommentiert, auch wirklich derjenige ist, der er zu sein vorgibt, ist unbedingt eine Komponente notwendig, die Niemandem zugänglich ist ausser dem Kommentierer selber. Das kann im einfachsten Fall ein Passwort sein. Das kann ein GPG-Schlüssel sein (wobei hier allerdings anders vorgegangen werden müsste), dies kann eine Chipkarte sein, naja eben Irgendwas wirklich persönliches. Etwas, das der ID-Klauer nicht haben kann.

  8. Jetzt hast du mich falsch verstanden…

    Noch mal zum Verständnis: ClaimID ist keine Verifizierungs-Instanz für MicroIDs… sie verwenden nur MicroID um die URLs, die ich zu meinem Profil http://claimid.com/pfefferle hinzufügen will, zu prüfen. Ich habe ClaimID nur als Beispiel erwähnt da es einer der wenigen Dienste ist, die eine MicroID-Authentifizierung unterstützen.

    Noch mal zu deinem Beispiel… natürlich hast du bei deinem Blog-Beispiel recht… es gibt keine Möglichkeit zu prüfen ob der Siegfried der hier kommentiert auch wirklich du bist.

    Deshalb ist MicroID auch nur eine Lösung für Systeme mit einer zwingenden Registrierung.

    Nehmen wir an, du meldest dich bei flickr an und du bekommst eine E-Mail mit einem Bestätigungslink welchen du akzeptierst, dann weiß flickr dass diese E-Mail – Adresse dir gehört. Wenn du jetzt deine Blog-URL auf deinem flickr-Account anzeigen lassen willst, kann flickr sicher sagen ob die URL dir gehört oder nicht, da die MicroID mit deiner bestätigten E-Mail – Adresse und der Blog-URL überprüft wird. Kein anderer kann so deinen Blog bei flickr verifizieren, da er deine E-Mail – Adresse nicht bestätigen kann.

  9. Oh, ich habe Dich schon verstanden. Aber Dein flickr-Beispiel zeigt auch genau das Problem auf: Zwar kann der flickr-Server tatsächlich verifizieren, dass die angegebene e-mail Adresse _mir_ gehört. Aber er kann nicht verifizieren, dass auch tatsächlich _ich_ einen Beitrag schreibe.

    Die Anzeige meiner URL in meinem Profil oder bei meinen Beiträgen, ja, die kann verifiziert werden. Es kann also verifiziert werden, ob ich (oder jemand Anders) die zu meinem Namen und meiner e-mail Adresse korrekte URL angegeben hat. Aber es kann nicht verifiziert werden, ob ich auch tatsächlich den Beitrag, bei dem mein Username, meine URL und meine e-mail Adresse steht, selber verfasst habe. Dies kann Irgendjemand getan haben.

    Es ist eigentlich sogar noch schlimmer: Angenommen, irgendwo steht ein Beitrag, ein Kommentar zu einem Blogartikel. Username und HP-URL stimmen. Und auf der Seite (auf dem Blog) wird per microid geprüft, ob der User „Siegfried“ die angegebene URL auch tatsächlich besitzt. Dann wird zur Zeit angenommen, dass verifiziert sei, dass der User „Siegfried“ den Artikel auch tatsächlich verfasst hat. Und genau das ist falsch.

    Um z.B. bei Robert Basic in Deinem Namen einen Kommentar abzugeben, sollte es reichen, einen echten Kommentar von Dir zu finden. Dann habe ich die URL. Dann suche ich Deine e-mail Adresse. Dein Username steht ebenfalls in dem Kommentar. Angenommen nun, Robert Basic lässt solche Kommentare per microid prüfen. Die Prüfung stellt nun fest, dass der User „Mathias Pfefferle“ tatsächlich die URL „http://www.claimid.org/pfefferle“ besitzt und verifiziert den Kommentar als von Dir. Und schon bist Du angeschissen, da die Meisten davon ausgehen, dass es durch microid-Prüfung erwiesen ist, dass _Du_ den Artikel verfasst hast.

    Und jetzt musst Du Dir dann nur noch vorstellen, dass der Kommentar rechtlich relevante Statements enthält…

  10. Siegfried, wir reden aneinander vorbei… Du vermischst meine Beispiele.

    Klar kann flickr oder ClaimID deine Blog-Kommentare nicht verifizieren, das wollte ich auch gar nicht damit sagen… was ich erklären wollte ist: wenn du deine E-Mail – Adresse vorher bestätigst ist MicroID ein wirksames Mittel.

    MicroID funktioniert also nur bei Blogs bei denen du dich zuvor anmelden und deine E-Mail – Adresse verifizieren musst.

  11. Ich glaube auch, dass Ihr Beiden ein Verständigungsproblem habt.

    Für Blog – Kommentare ist MicroID gänzlich ungeeignet, da natürlich jeder mit schon eingegebenen Email-Adressen und Domains ausprobieren kann, bis es passt.

    Für geschlossene Bereiche und vor allem den Datenaustausch zwischen den Diensten ist es allerdings eine gute Sache und funktioniert tadellos. Matthias hat das mit seinem Flickr – Beispiel sehr gut erläutert, auch wenn, wie schon gesagt, dass Blog-Kommentar-Problem damit nicht gelöst ist. Aber hierfür gibts ja dann auch immer noch open ID 🙂

  12. Nein, selbst dann funktioniert es nicht. Nur die Anmeldung/Registrierung als Solche funktioniert. Sobald in solch einem Blog mindestens ein echter Kommentar vorhanden ist, kann Jeder beliebige Kommentare unter meiner ID verfassen. Das ist das Problem.

    Eine funktionierende Authentifizierung sollte zweierlei tun:
    1. Es muss sicher gestellt werden, dass die ID existent ist. Dies bewältigt microID.
    2. Es muss sichergestellt werden, dass der existente User mit der existenden ID X auch tatsächlich den jeweiligen Beitrag verfasst. Dies bewältigt microid leider nicht.

    Ein Kommentator kommt ja nicht immer von der selben URL. Der referer ist alles Andere als zuverlässig und kann problemlos gefälscht oder unterdrückt werden. Das ist also absolut kein Kriterium, das irgendwie in die Authentifizierung mit einfließen kann. Zur Authentifizierung dienen nur die Eingaben des Users, also Username, e-mail Adresse und URL.

    Wenn ein User sich erst einmal bei einem Blog registriert hat, und er als existent und tatsächlich eben dieser User identifiziert wurde, und dieser User mindestens ein mal einen Beitrag verfasst hat, dan kann danach jeder dessen ID stehlen und missbrauchen. Auch und gerade mit microid.

    Anders wäre es, wenn diese Bestätigungsmail mit Bestätigunglink jedes Mal verschickt würde, bei jedem einzelnen Beitrag. Denn diese Bestätigungsmail würde nur der rechtmäßige Besitzer dieser ID empfangen. Aber das ist wohl ein wirklich unzumutbarer Umstand.

  13. @Snirgel: Gut, für komplett geschlossene Bereiche kann das funktionieren. So lange Niemand an die notwendigen Daten wie URL und e-mail Adresse rankommt, kann das problemlos funktionieren. Aber sobald Beides öffentlich zugänglich wird, wird’s problematisch.

  14. So, ich habe mal meine Idee einer Passwortgestützten, microid ähnlichen Authentifizierung in einen Text gegossen und online gestellt. Momentan ist es einfahc mal so ins Blaue hinein hingeschmiert, ohne große Strukturierung, ohne Beispiele. Das sollte Alles noch nachgerüstet werden. Und momentan ist es auch nur auf Deutsch zu haben. Die englische Übersetzung muss ich gelegentlich noch vornehmen.

    https://web.archive.org/web/20131009181241/http://www.rorkvell.de/tech/specs/myID.xhtml.de
    und
    https://web.archive.org/web/20131008203343/http://www.rorkvell.de/tech/specs/myID.html.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert