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.
Gerade ähnliche Zeichen sind auch immer wieder ein Grund von Fehlern.. 0 und O und l und I sind da schöne Kandidaten..
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.