Vorschlag für einen Softwarestandard
Version 1.2/3.0, 11.01.2009
Problembewusstsein
Nebenziele, positive Nebeneffekte, weitere Betroffene
Realisierung, mögliche Probleme
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.
Die Problematik sollte jedem Vieltelefonierer persönlich bekannt sein.
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.
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.
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.
Zeichensatz
Die nächstliegende ist die der Codierung als UTF-8 (natürlich nur für die Hashberechnung; die Applikation muss nicht das Format anpassen, in dem sie Daten speichert).
Transkription
Für den Fall, dass entweder UTF-8 nicht zur Verfügung steht oder die gewünschten (fremdsprachigen) Zeichen nicht (sofort) eingegeben werden können, sollte eine eindeutige Alternativdarstellung definiert werden; idealerweise diejenige, die allgemein verwendet wird. Der Empfänger muss etwa ue
tippen, weil er ü
nicht auf seiner Tastatur hat. Die Applikation des Senders berechnet neben dem Hash für die Variante mit ü
auch eine mit ue
, so dass der Sender den passenden Hash vorlesen kann (der einen international eindeutigen Namen haben sollte).
Textnormalisierung
Texte sind keine Binärdaten. Es gibt typischerweise viele Möglichkeiten, dieselbe Information auszudrücken. So spielt die Anzahl von Leerzeichen in der Regel keine Rolle, ebenso deren Ersetzung durch Tabulatoren. Groß-Klein-Schreibung ist für das Problem der Übermittlungsfehler ebenfalls irrelevant. Dann gibt es bei Telefonnummern noch diverse Zeichen, die (alternativ und optional) zur Aufteilung verwendet werden und für das Ergebnis irrelevant sind (030/123456
, 030-123456
, (030) 123456
, ++(0)30 123456
, 030/12345-6
). Es bietet sich daher an, datentypspezifische Normalisierungen zu verwenden, wobei die entgegennehmende Applikation den Anwender darauf hinweisen sollte, wenn er die Daten in einer Weise eingibt, die die Normalisierung nicht abdeckt.
Man brächte also klare, international einheitliche Bezeichnungen für:
das System an sich
die gewünschte Normalisierung
die gewünschte Darstellung des Hashs
eventuell noch für die Länge des Hashs, denn bei Fehlern kann vielleicht erst ein langer Hash die sichere Bestimmung der Fehler durch den Eingabecomputer ermöglichen
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 |
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.
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:
Das Passwort des Kunden, das dem IT-System des Anbieters unmittelbar bekannt ist, lautet 3yE0Bt.
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).
Der Kunde verbindet nun Passwort und challenge zu 3yE0Bt7Z und lässt sich den Hash dazu anzeigen: 71be36961402cfe616ff3adf2e5a2d27
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.
Die Hashfunktion kann auch Leuten helfen, die sich nicht mehrere Passwörter für unterschiedliche Dienste merken wollen:
Der Anwender hat nur ein "richtiges" Passwort: DtwnTu9L.
Für jeden Dienst konstruiert er ein eigenes Zwischenpasswort aus diesem und einer passenden Bezeichnung, zum Beispiel DtwnTu9L-ebay, DtwnTu9L-sparkasse, DtwnTu9L-email.
Wenn er ein Passwort zur Authentifizierung benötigt, erzeugt er den Hash des Zwischenpassworts, also etwa b51c206094d29970b8e2f86a43ae06e0 (für DtwnTu9L-ebay).
Aus dem Hash nimmt er dann einen bestimmten Block (der Einfachheit halber wohl immer denselben), etwa die Zeichen 10 bis 3: 490602c1.
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.
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)?
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).
Ü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.
hinzugefügt: Abschnitt positive Nebeneffekte
Rechenfehler korrigiert
hinzugefügt: Abschnitt Erweiterungen → Erleichtert challange-response-Authentifizierung "außerhalb" von Computern
hinzugefügt: Abschnitt Erweiterungen → vereinfachter Umgang mit unterschiedlichen Passwörtern