Vorschlag für einen Softwarestandard

Hauke Laging, Peter-Vischer-Straße 29, 12157 Berlin, Tel.: 030/32603660, mobil: 0172/7630883, E-Mail: hauke@laging.de, WWW: http://www.hauke-laging.de/

Hashwerte als Diktierhilfe

Version 1.2/3.0, 11.01.2009

Inhalt

Ausgangslage – das Problem – Übersicht

Auch heute noch werden viele Daten telefonisch übermittelt. Man spricht mit jemandem, und der teilt einem Namen, Telefonnummern oder E-Mail-Adressen mit. Dabei kann man sich leicht vertun, ganz besonders bei Gesprächen in einer Fremdsprache. Missverständnisse sind bei Namen peinlich, bei Telefonnummern und E-Mail-Adressen fatal.

In vielen Fällen werden die übermittelten Daten sowohl einem Computer (im weitesten Sinn, inkusive normales Mobiltelefon) oder einer Liste entnommen als auch in einen Computer eingetragen; noch größer ist der Teil der Fälle, in denen dies möglich wäre.

Für Computer sind Übermittlungsfehler auf allen Ebenen seit jeher ein wichtiges Thema; dementsprechend hat man Gegenmaßnahmen entwickelt. Typischerweise überträgt man zusätzlich zu den Daten eine Prüfsumme, deren Qualität von Parity-Bit bis zu einem "richtigen" Hashwert (z.B. MD5) reicht. Deren Erzeugung und Überprüfung sind trivial. Entscheidend ist auch auf technischer Ebene, dass Sender und Empfänger sich über die Art der Prüfsumme einig sind.

Problembewusstsein

Die Problematik sollte jedem Vieltelefonierer persönlich bekannt sein.

ZielÜbersicht

Das Problem der telefonischen Übermittlungsfehler ließe sich leicht dadurch lösen, dass die Software, die die Daten anzeigt oder entgegennimmt, eine solche Prüfsumme berechnet und anzeigt. Je länger die Prüfsumme, desto geringer ist die Wahrscheinlichkeit, dass Fehler unentdeckt bleiben und automatisch behoben werden können.

Der Sender der Information würde dann den (passenden) Hashwert mit angeben. Auch dabei wäre es natürlich möglich, dass ein Missverständnis auftritt, aber das würde immerhin sofort bemerkt. Außerdem kann man denselben Hash unterschiedlich codieren, so dass man etwa auf Ziffern ausweichen könnte, falls man die Buchstaben nicht versteht.

Dieser Ansatz setzt natürlich voraus, dass jede Software dasselbe System verwendet. Es ist nicht zu befürchten, dass sich unterschiedliche Systeme etablieren (sofern das erste nicht mangelhaft ist); das Problem ist, dass dieses System nur dann nützlich ist, wenn es hohe Verbreitung erlangt. Und leider werden sehr viele Adressen von Software verwaltet, die von der Firma Microsoft kommt, die sich notorisch nicht darum schert, was der Rest der Welt macht und was ihre Software taugt (speziell die hierfür relevante). Andererseits ist der Aufwand gering, so etwas umzusetzen, so dass Hoffnung besteht, dass einige Hersteller das machen.

Nebenziele, positive Nebeneffekte, weitere Betroffene

Eingabe nicht verfügbarer Zeichen

Durch die Angabe mehrerer Hashwerte, der für unterschiedliche Normalisierungen, ist es insbesondere möglich, den Eingaberechner solche Zeichen erkennen zu lassen, die seine Tastatur (o.ä.) nicht direkt zur Verfügung stellt. Wenn also jemand auf einer ausländischen Tastatur statt Müller ersatzweise Mueller einträgt, dann zeigt ihm der Hash der Transkriptionsnormalisierung, dass er sich nicht vertippt hat, und zeigt dem Eingabecomputer der Hash der UTF-8-Normalisierung, dass es eigentlich Müller heißen muss, so dass der Rechner die Eingabe automatisch korrigieren kann.

technische UmsetzungÜbersicht

Realisierung

Der einfachste Teil ist die Festlegung des Prüfsummenverfahrens, das lediglich die zwei Kriterien erfüllen muss, dass es mathematisch brauchbar und frei verfügbar ist. An solchen Verfahren herrscht kein Mangel. Man könnte einfach eine etablierte Hashfunktion nehmen und die ersten Ziffern verwenden, weil der Gesamthash natürlich zu lang ist. Bei vier Ziffern (0-9 + A-F) hätte man einen Werteraum von 65536. Das ist nicht nur ausreichend, um Fehlübermittlungen zu erkennen, sondern – je nach Fall – auch genug, um den Computer bei Fehlern das wahrscheinlich richtige Ergebnis raten zu lassen.

Das praktische Problem ist die Codierung der Eingangsdaten. Hashfunktionen interessieren sich nur für die Binärdarstellung. Damit kann der Vergleich schon am Zeichensatz scheitern. Es wäre also auf jeden Fall erfoderlich, eine oder mehrere Normalisierungen anzubieten. Beide Applikationen würden alle Hashvarianten anzeigen.

Man brächte also klare, international einheitliche Bezeichnungen für:

Beispiel

Der Anwender sähe dann etwa folgendes (Eingabe in latin9; erste vier Stellen von MD5):

Eingabe normalisierte Eingabe Hashwerte (Hexadezimaldarstellung) Hashwerte (Dezimaldarstellung)
 Michael  Müller  [keine] 14A1 5281
[UTF-8] 50DF 20703
michael müller [UTF-8] C5F6 50678
michael mueller [UTF-8/ASCII] 12BF 4799

mögliche Probleme

Verbreitung

Wie schon erwänt, hat auch die eleganteste technische Lösung immer noch mit dem Praxisproblem der Verbeitung zu kämpfen. Es handelt sich hier um einen Netzwerkeffent: Dass man selber das System nutzt, ist an sich wertlos. Es bringt nur was, wenn (viele) andere es auch nutzen. Und wenn der Marktführer mit seinen Qualitätsprodukten auch hier zehn Jahre braucht, um standadisierte Techniken zu integrieren, dann ist das für diejenigen, die dieses System nutzen wollen (unabhängig davon, welche Software sie nutzen), ein Problem.

Allerdings hindert nichts einen Anwender schlechter Software daran, sich ein kleines Zusatzprogramm zu installieren, das (ohne Integration in seine Software) diesen Zweck erfüllt. Man könnte die gewünschten Daten sehr schnell und einfach über die Zwischenablage in ein Hilfsprogramm kopieren (oder dort eintippen), das die Hashwerte erzeugen kann. Der Sender bekommt so die Möglichkeit, die Hashwerte mit zu übermitteln, der Empfänger kopiert die Daten nach der Prüfung in sein Programm.

Es bietet sich an, so ein Hilfsprogramm so zu schreiben, dass es mit mehreren Zeilen, also einem ganzen Datensatz, auf einmal gefüttert werden kann. So müsste der Sender nur einmal Daten kopieren (wenn seine Anwendung es ihm erlaubt, die Daten gemeinsam zu kopieren), was bequemer und schneller wäre.

Für jemanden, der diese Funktion in seine Kontaktverwaltungssoftware (für Windows) integriert, sollte es trivial sein, diese funktion in ein eigenständiges kleines Programm zu integrieren.

Einwände, Anmerkungen und Bewertungen von DrittenÜbersicht

ErweiterungenÜbersicht

Erleichtert challange-response-Authentifizierung "außerhalb" von Computern

Hashwerte kann man auch zur Authentifizierung nutzen. Es ist oftmals wünschenswert, nicht das Passwort selber zu übermitteln (bei Zugriffen auf geschützte Ressourcen über ungesicherte und unverschlüsselte Verbindungen; beim Onlinebanking und jeder anderen telefonischen Authentifizierung). Es reicht für den gewünschten Zweck aus nachzuweisen, dass man im Besitz des Passwortes ist. Das kann man machen, indem die Gegenstelle (die das Passwort im Klartext kennt), einem einen Wert (challenge) nennt, den man mit dem Passwort verrechnen muss. Das Ergebnis wird dann zurückgeschickt. Jemand, der die Übertragung belauscht (und auch der Mitarbeiter im Callcenter, der die telefonische Authentifizierung entgegennimmt), kann aus dem abgehörten Inhalt nicht das Passwort ermitteln. Diese Vorgehensweise kann man im Zusammenhang mit dem hier vorgeschlagenen Hashsystem für Authentifizierungszwecke nutzen:

  1. Das Passwort des Kunden, das dem IT-System des Anbieters unmittelbar bekannt ist, lautet 3yE0Bt.

  2. Der Anbieter übermittelt dem Kunden (telefonisch oder übers Web) den challenge-Wert 7Z (wichtig ist nur, dass dieser Wert sich nie wiederholt (bei unverändertem Passwort); drei alphanumerische Zeichen mit Groß- und Kleinschreibung erlauben 3844 Varianten – so viele Zugriffe hat man telefonisch und manuell über Internet bei normalen Anwendungen nie).

  3. Der Kunde verbindet nun Passwort und challenge zu 3yE0Bt7Z und lässt sich den Hash dazu anzeigen: 71be36961402cfe616ff3adf2e5a2d27

  4. Von dem Hash kann sich der Anbieter dann so viele Stellen nennen lassen, wie er sicherheitstechnisch für sinnvoll hält.

Wenn das Hauptkonzept allgemein akzeptiert wird, dann wird man es sehr schnell auch auf Mobiltelefonen finden (kein nennenswerter technischer Aufwand). Damit wäre diese Erweiterung auch unterwegs gut zu nutzen.

vereinfachter Umgang mit unterschiedlichen Passwörtern

Die Hashfunktion kann auch Leuten helfen, die sich nicht mehrere Passwörter für unterschiedliche Dienste merken wollen:

  1. Der Anwender hat nur ein "richtiges" Passwort: DtwnTu9L.

  2. Für jeden Dienst konstruiert er ein eigenes Zwischenpasswort aus diesem und einer passenden Bezeichnung, zum Beispiel DtwnTu9L-ebay, DtwnTu9L-sparkasse, DtwnTu9L-email.

  3. Wenn er ein Passwort zur Authentifizierung benötigt, erzeugt er den Hash des Zwischenpassworts, also etwa b51c206094d29970b8e2f86a43ae06e0 (für DtwnTu9L-ebay).

  4. Aus dem Hash nimmt er dann einen bestimmten Block (der Einfachheit halber wohl immer denselben), etwa die Zeichen 10 bis 3: 490602c1.

  5. Dieser Block ist das Passwort, das er für den jeweiligen Dienst verwendet. Weniger bequem wird es allerdings, wenn er dieses Passwort (auf Veranlassung des Anbieters) mal ändern muss, denn dann muss er aus dem einheitlichen System ausbrechen (auf z.B. -ebay2 oder einen anderen Block umsteigen).

Ein ähnliches Verfahren gibt es bereits als Browsererweiterung.

Und was denken Sie?Übersicht

Schreiben Sie mir, was Sie von den oben ausgeführten Überlegungen halten!

Wenn Sie Ihre Meinung über dieses Konzept (im Sinne einer Bewertung des Verfassers, der "Qualität" des Grundgedankens) maximal vereinfachend zusammenfassen, finden Sie es dann eher gut oder eher schlecht (unabhängig davon, ob sie glauben, dass die Details korrekt sind und es so insgesamt funktioniert)?

eher gut eher schlecht

Das ist natürlich erfreulich... Nehmen Sie das doch zum Anlass, sich anzusehen, zu welchen anderen Themen ich Vorschläge veröffentlicht habe. Auch wenn Sie diesen Text positiv bewerten, gibt es sicher Details, die Sie anders sehen. Ich freue mich, wenn Sie mir Ihre Anmerkungen per E-Mail mitteilen.

Und wenn Sie Unternehmer oder in geeigneter Position in einem Unternehmen tätig sind, das an Innovationen interessiert ist, dann sind vielleicht meine kommerziellen (nicht veröffentlichten) Konzepte für Sie von Interesse. Ich freue mich in dem Fall über Ihre Kontaktaufnahme.

Ihre Einschätzung ist für mich natürlich bedauerlich. Aber auch wenn ich wahrscheinlich nicht zu Ihrer Ansicht wechseln werde, möchte ich Sie doch ermuntern, mit per E-Mail mitzuteilen, was Sie problematisch finden (und ggf. warum).

Änderungen am Dokument und alte VersionenÜbersicht

Übersichtsseite aller Versionen dieses Dokuments mit digitalen Signaturen

Wenn in Ihrem Browser Javascript aktiviert ist, können Sie die Absätze, die sich von Version zu Version geändert haben, farblich markieren lassen, um auf einen Blick zu sehen, was zu lesen sich lohnt, wenn Sie einen ältere Version dieses Dokuments bereits kennen.

nichts markieren

1.0 (15.12.2008)

1.1 (17.12.2008) – Änderungen markieren / Markierung aufheben

1.2 (11.01.2009) – Änderungen markieren / Markierung aufheben