Hi.
Ich habe sogenannte ASCII Tokens.
Diese Ascii Tokens werden auf dem Display angezeigt, und der User
schreibt diese ab.
Der verfügbare Zeichensatz sind die ASCII Codes HEX 20 bis HEX 5F.
(Leerzeichen bis Unterstrich)
Es werden 5er Gruppen aus Zahlen und Buchstaben genutzt. Das - Zeichen
ist das Trennzeichen. Nicht benutzte Zeichen am Ende werden mit
Leerzeichen (Ascii HEX 20) aufgefüllt.
Die maximale Länge sind 32 Zeichen.
Die Tokens kann der User dann später wieder eingeben, um die
Konfiguration wiederherzustellen.
Nun woltle ich aber Schreibfehler / Zeichendreher usw abfangen und würde
gerne Prfzeichen einsetzen. Welches Verfahren würdet ihr empfehlen?
Viellecht Irgendwas auf Modulo Basis? Oder ehr ein CRC Verfahren?
Sven schrieb:> Viellecht Irgendwas auf Modulo Basis? Oder ehr ein CRC Verfahren?
Modulo klingt doch gut, denn selbst die Banken nutzen fuer die
IBAN-Text-Kontonummern Modulo:
Generierung der Prüfziffer erfolgt gemäß ISO 7064 per Modulo 97-10
http://www.iban.de/iban-pruefsumme.html
Sven schrieb:> Nicht benutzte Zeichen am Ende werden mit> Leerzeichen (Ascii HEX 20) aufgefüllt.
Das würde ich nicht machen. Es ist für den Anwender einfacher Fehler
selbst zu erkennen wenn der Token immer die gleiche Form und Länge
aufweist. Grad bei Leerzeichen ist das erkennen der richtigen Anzahl
schwierig, wenn Du Füllzeichen nutzen willst, dann doch eher X, | oder
0.
Leerzeichen, nichts und Nullen führen oft zu Irrtümern.
Modul 9 Prüfrest 5 ist auch eine Variante, die sich früher schon gegen
Zahlendreher und Tippfehler relativ bewährt hat. Falls NUR Zahlen
vorkommen, wäre schon die einfache Summe ANZEIGEN ein erster Hinweis auf
Fehler, leider nicht auf Zahlendreher wie 78 und 87. Zwei verschiedene
Prüfmethoden haben natürlich den Vorteil, daß gewisse Zahlen nicht durch
das Sieb fallen können. Deshalb wäre die simple Summe als 2. Prüfung
durchaus schon nützlich.
Man könnte sich an den "wundervollen" MS-Lizenzschlüsseln orientieren.
Mehrere 5er-Gruppen à la
XD65G-HBS71-6DQG7-BRMM0-AB103
Auf das Abtippen von solchen Dingen sind die Leute bereits
konditioniert.
Ich wuerd erst mal ueber den Zeichensatz gehen und die zu Aehlichen
rausschmeissen. Und dann strikt auf gleichlangen Font gehen, dh auf
Courier New. Keine Spaces, da geschehen Fehler, zB wird ein String da
umgebrochen usw.
Oder D. schrieb:> Und dann strikt auf gleichlangen Font gehen, dh auf Courier New.
Consolas ist besser, da sind die Glyphen für 0 und O sowie für I1l
deutlich voneinander zu unterscheiden, auch bei kleinen ppem-Werten.
("Gleichlang" nennt man üblicherweise "monospaced", "fixed pitch" oder
Nicht-Proportional)
@rufus: Ja, genau so ähnlich soll es aussehen.
Grundsätzlich soll die Form des Tokens bei der Vergabe / beim encoding
bestimmt werden und dann auch so als String in der DB abgespeichert
werden
Das heißt, Trennzeichen zur besseren Lesbarkeit, wie z.B. "-" sollen
auch mit in die Checksumme verpackt werden.
Und der String wird intern am Ende mit leerzeichen aufgefüllt, so dass
die Checksumme sich über 32 Zeichen erstreckt auch wenn er kürzer ist.
Sofern eine feste Länge für die Prüfsumme gebraucht wird, sonst kann man
auch die tatsächliche Länge nehmen.
Neben den 5er Gruppen soll es auch "Readable Text Tokens" geben, welche
für bestimmte Anlässe oder Default Konfigurationen benutzt werden und
nicht der üblichen Form entsprechen müssen.
Die Form dann z.B. "TEST Q1/2016".
Das Token ist ansonsten einfach nur ein zufällig erzeugter Wert.
Die Zahl der möglichen Werte muss aber so groß sein, dass sie nicht
einfach nur fortlaufende Nummern sind. Weil man dann schnell durch
einfaches "Nummern durchprobieren" einen fremden Account erreichen
könnte.
Und das Token soll halt durch eine Checksumme gegen Schreibfehler
geschützt werden.
Das Token kommt dann zum Einsatz, wenn sich ein User gegen eine
Registrierung entscheidet.
Es ersetzt dann Passwort+Username beim Login.
Der User muss das Token dann aufschreiben oder ausdrucken.
Wenn der User dann wieder kommt, kann er das Token dann von Hand
eingeben um die Sitzung wieder her stellen.
Achja, bei der Tokenerzeugung könnte man I und O auch einfach auslassen,
um eine Verwechselung mit 0 und 1 zu vermeiden.
Man könnte sogar ein "Buchstabieralphabet" zugrunde legen, und
"kritsche" Zeichen ebenfalls auslassen.
Nun könnte man also hingehen, und jedes einzelne Zeichen per Random
Funktion auswürfeln. Wenn ein "Gesperrter" Buchstabe dabei heraus kommt,
wird nochmal gewürfelt. Außerdem könnte man sagen, dass bestimmte Muster
nicht vorkommen dürfen.
Also ein Zeichen darf nicht 2 mal hintereinder gleich sein, es dürfen
auch keine direkt angrenzenden Zeichen sein.
Damit keine Tokens wie AAAAA oder ABCDE rauskommen können, weil ein
Angreifer solche Konstellationen wohl als erstes ausprobiert.
Und alle 5 Zeichen wird "Fest" ein - eingefügt, der besseren Lesbarkeit
wegen.
Anschließend wird in der Datenbank geschaut, ob ein gleiches Token schon
existiert. Wenn ja, wird ein neues erzeugt, ansonsten wird es an den
User herausgegeben.
Allerdings bringt eine Checksumme nichts. Entweder das Token ist
gueltig, dh entspricht einem Eintrag in der Datenbank oder eben nicht.
Falls nicht, bringt die Feststellung von einem Schreibfehler leider gar
nichts.
Wenn ich solche Tokens benoetige, verwende ich eine Systemfunktion :
bin2hex(openssl_random_pseudo_bytes(10)
oszi40 schrieb:> Modul 9 Prüfrest 5 ist auch eine Variante, die sich früher schon gegen> Zahlendreher und Tippfehler relativ bewährt hat. Falls NUR Zahlen> vorkommen, wäre schon die einfache Summe ANZEIGEN ein erster Hinweis auf> Fehler, leider nicht auf Zahlendreher wie 78 und 87.
Das gilt leider auch für Modulo 9, wenn die Eingabe als Dezimalzahl
erfolgt:
761 % 9
Ans = 5
671 % 9
Ans = 5
167 % 9
Ans = 5
Prüfrest ist immer 5... Modulo 11 ist da schon besser.
Aber wie "Oder Doch" gesagt hat, braucht man überhaupt eine Prüfung des
Tokens, wenn eine Liste der Tokens(Konfigurationen) im Speicher liegt?
Sven schrieb:> Wenn der User dann wieder kommt, kann er das Token dann von Hand> eingeben um die Sitzung wieder her stellen.
Das ist ja auch nichts anderes als ein vom System erzeugtes Passwort -
dafür gibt es fertige und vor allem bewährte Routinen. So was sollte man
nicht selbst versuchen, da können sich zu leicht Schwächen
einschleichen. Kryptographie ist nichts für Anfänger.
Ich benutze so einen Passwortgenerator für kritische Anmeldungen. Da
gibt man die Länge und die zulässigen Zeichen vor (Buchstaben, Zahlen,
Sonderzeichen).
Eine Prüfziffer ist nicht nur völlig unnötig, sondern kontraproduktiv:
die erleichert Brute-Force-Angriffe erheblich.
Georg
