"Sicherer" Gutscheincode

[Quetschi]

Im Moment erstelle ich ein kleines System für die Online-Bestellung eines Gutscheins. Der Gutschein muss dann natürlich mit einem Code versehen sein und hier mach ich mir grad etwas Gedanken: Wie soll der Code aufgebaut sein?

- Er darf natürlich nicht erratbar sein, also nicht einfach nur aus einer fortlaufenden ID oder so bestehen, da käme ja jeder mir nix dir nix dahinter.
- Andererseits sollte er nicht zu lang und zu kryptisch sein, damit er leicht per Telefon durchgegeben werden kann, oder damit eine Kassiererin nicht eine halbe Stunde damit verbringen muss, den Code korrekt in das Abgleich-System einzutippen.

Ich denke da an sowas wie z.B.:
mind. 5-stelligen ID zu Beginn - jjmmdd - 5-stellige zufällige Buchstabenfolge. Er könnte also so aussehen:

24567-100122-BXDHS

Kritik, Vorschläge? Ich weiß grad nicht ob ich da grad zuviel Gedanken dran verschwende usw...

[AmicaNoctis]

Hallo,

vom Grundprinzip her finde ich deinen Ansatz in Ordnung, aber um es noch leichter zu machen, kannst du auch gängige zusammengesetzte Substantive mit einer Zahl verbinden. Das lässt sich am Telefon noch besser kommunizieren. Das Wort ist bekannt und Ziffern sind weniger verwechselbar als Buchstaben. Ein paar Beispiele:

Kirschbaum4312
Sommerreifen7689
Tellerrand1425

Ich finde, dass das genau so schwer zu erraten ist, aber leichter zu merken bzw. am Telefon weiterzugeben.

Gruß,

Amica

[onemorenerd]

Wie viele Gutscheincodes brauchst du? Wie viele Gutscheine willst du in Umlauf bringen?
Von wem und wie wird der Code verwendet?
-> Kann man ihn öfter verwenden? Dann sollte er leicht merkbar sein.
-> Muss man ihn in einem Computer eingeben? Dann sollten bestimmte Zeichen wegen Verwechslungsgefahr vermieden werden, die Prüfung case insensitive sein und die Bindestriche optional.

Das hat alles Einfluss darauf, wie lang der Code wird. Als Beispiel: Du brauchst 1000 Gutscheine. Der Code darf nur aus a-hjkm-ux-z2-9 bestehen. => Der Code kann kein Datum enthalten (1 ist nicht erlaubt). Der Code muss mindestens 3stellig sein, denn 30^2 < 1000. Mit 30^3 = 27000 ist die Chance einen gültigen Code zu erraten 1 zu 27, mit 4 Stellen 1/810. 4 Stellen kann man auch mit einem Blick erfassen, merken und abtippen. Ab 5 Stellen neigen Menschen dazu, es in Blöcke zu zerlegen, die einzeln abgetippt werden, wodurch sich die Fehlerrate erhöht.

Wieso soll eigentlich ein Datum in den Code? Sobald du Informationen in den Code packst, schränkst du dich unnötig ein. Die Information kann auch woanders gespeichert werden mit einer Zuordnung zum Code.

Wozu sind die Gutscheine eigentlich gedacht? Wenn damit etwas vergünstigt gekauft werden kann und beim Kauf ohnehin eine Lieferanschrift angegeben werden muss, lohnt sich der Aufwand vielleicht gar nicht. Dann genügt ein Aktionscode für alle Teilnehmer. Über die Lieferanschrift kann dann sichergestellt werden, dass eine Person den Code nur einmal verwendet.

[unset]

Denk dir ein Prüfziffer-Algorithmus aus (Inspiration kannst du dir zum Beispiel hier holen), und markiere Benutzte Codes. Je nach Anwendungsfall würde ich aber in der Tat zu onemorenerds Vorschlag mit dem Aktionscode tendieren.

[Quetschi]

Es handelt sich um Geschenkgutscheine für Hotels.

Person A bestellt online den Gutschein, führt die Bezahlung auf der Seite per Kreditkarte durch, nach erfolgter Zahlung erhält Person A den Gutschein nach Wahl als PDF per Mail oder fertig auf postalischem Weg zugesandt und im System wird der Gutschein-Datensatz als bezahlt und noch nicht abgegolten markiert.

Person A verschenkt Gutschein dann an Person B, welche den Gutschein dann im Hotel einlöst. Weder Person A noch Person B sollte (da Gutschein ja evtl. selber druckbar) nun einen evtl. gültigen Code erraten können und sich damit selber noch nen Gutschein ausstellen.

Das kann bei genauerem überlegen schon gar nicht mehr so einfach passieren, da selbst wenn jemand einen gültigen Code erraten würde, er dazu auch noch den passenden Betrag erraten müsste - von daher schmelzen die Chancen eh schon ein gutes Stück dahin.


@onemorenerd
Wegen deinem Einwand zum Datum: Ist das tatsächlich nicht erlaubt? Der Gutschein verfällt selbstverständlich nicht - hat das evtl. den Hintergrund wegen Schindluder mit verfallenen Gutscheinen?

[TobiaZ]

Ich kann zwar nicht erkennen, wo onemorenerd geschrieben hat, dass ein (verfallsdatum) nicht erlaubt sei, jedoch ist es wahr, dass bezahlte gutscheine nicht verfallen dürfen.

letztendlich ist ein Gutschein nichts anderes als ein Passwort. Die Daten des Beschenkten kannst du sicher nicht speichern, von daher bleibt dir nichts anderes als den code so zufällig wie möglich zu machen.

Den Sinn einer Prüfziffer erkenne ich an dieser Stelle übrigens nicht direkt. Vorausgesetzt ich errate den Code, so muss ich so oder so den gesamten Code erraten. Ein Hash würde das ganze ja noch eher berechenbar machen. (zu dem Zeitpunkt war aber auch noch nicht bekannt, dass die Codes gespeichert werden.)

[Quetschi]

Ich kann zwar nicht erkennen, wo onemorenerd geschrieben hat, dass ein (verfallsdatum) nicht erlaubt sei, jedoch ist es wahr, dass bezahlte gutscheine nicht verfallen dürfen.

=> Der Code kann kein Datum enthalten (1 ist nicht erlaubt).

Evtl. hab ich das nur falsch interpretiert.

Im ersten Post war ich mit Details noch zu geizig

Im Prinzip hast du Recht - es ist eigentlich einfach ein Passwort das unique sein muss. Es soll wie gesagt nicht zu kryptisch aussehen - in Kombination mit dem Gutscheinbetrag ist es ohnehin nicht mehr sehr leicht einen gültigen Gutschein zu erstellen - Bsp:

AAAA - 500 EUR
AAAB - 400 EUR
AAAC - 200 EUR

Selbst wenn der Code jetzt simpel fortlaufend wäre und dies einer erkennen würde, müsste er schon noch den Betrag zum Code wissen, denn falls jetzt einer einen Gutschein AAAB einlösen möchte, dieser allerdings über 300 EUR lautet ist schon klar, dass hier eine Fälschung vorliegt. Ich denke ein Zusammensetzung aus z.B. 3 zufälligen Ziffern und 3 zufälligen Buchstaben ergeben genug Möglichkeiten, ist leicht zu lesen und kann wohl kaum noch dazu mit dem richtigen Betrag erraten werden.

Edit:
@onemorenerd
Jetzt hab ich das erst richtig gesehen - wegen der Verwechslungsgefahr von ilIL1 sollten die nicht vorkommen und deshalb kann er kein Datum enthalten, weil 1 eben rausfällt. Soweit so gut - aber warum wird v und w ausgeschlossen? Wo ergeben sich hier Verwechslungsmöglichkeiten?

[TobiaZ]

die wahrscheinlichkeit kannst du ja selber ausrechnen. Mir wärs noch etwas zu wenig, vor allem weil zahlen max. 10 möglichkeiten pro ziffer liefern.

Auf den Geldbetrag würd ich auch nicht zu viel geben. 75,84 werden wohl nur die wenigsten verwenden. 100 oder 250 sicher mehr.

[Quetschi]

Die Wahrscheinlichkeit ist im konkreten Fall sowieso eine Sache für sich. onemorenerd ging da noch von einem anderen Ansatz aus, nämlich das jetzt z.B. einfach 1000 Codes verschickt werden. Wie groß die Chance ist eine momentan gültigen Code zu erraten ist hier aber nicht im vorraus zu erkennen, da nicht bekannt ist wie viele Gutscheine bestellt werden. Zudem verringert sich mit jedem zwischenzeitlich eingelösten Gutschein wieder die Wahrscheinlichkeit einen gültigen Code zu erraten.

IMHO bleibt der Code noch leichter zu lesen (und auch zu tippen), wenn er aus Blöcken besteht, die entweder nur Buchstaben oder nur Ziffern enthalten:
2345-ABCD
Selbst wenn man nun die Möglichkeiten pro Stelle wegen Verwechslungsgefahr einschränkt (v und w hab ich immer noch nicht verstanden - eher müsste aber O noch ausgeklammert werden) und man von 1000 gültigen Codes im System ausgeht kommt man noch auf knapp 1 zu 1.000.000 .

Ob ich die Einschränkung überhaupt vornehm, da bin ich mir eh noch nicht sicher - was das durchgeben am Telefon angeht, müsst man da weitere Buchstaben ausschließen: h und k ist am Telefon schwer auseinanderzuhalten, auch m und n, sowie f und s. Zumindest fallen mir die auf Anhieb ein. Wo fängt man da an und wo hört man auf? Die Verwendung eines halbwegs tauglichen Fonts sollte da bei der Lesbarkeit die gröbsten Zweifel beseitigen.

[wahsaga]

was das durchgeben am Telefon angeht, müsst man da weitere Buchstaben ausschließen: h und k ist am Telefon schwer auseinanderzuhalten, auch m und n, sowie f und s.

„Eins-Zwo-Drei-Vier, Hugo-Karl-Martha-Norbert”

Also da sehe ich eigentlich überhaupt kein Problem.

[unset]

Im Osten sieht das alles natürlich vollkommen anders aus … SCNR

[onemorenerd]

V und w habe ich ausgeschlossen, weil je nach verwendetem Font zwei aufeinanderfolge v wie ein w aussehen. Das gilt manchmal sogar für n und m, allerdings viel seltener, da die meisten Fonts bei diesen Buchstaben eine Serife am Grundstrich haben oder zumindest überhaupt einen erkennbaren Grundstrich.
Die Null habe ich wegen Verwechslungsgefahr mit Gross-Oh ausgeschlossen. Zwar sind Großbuchstaben generell ausgeschlossen, aber das weiß der Kunde ja nicht.
Das hängt natürlich alles vom Font ab. Bei dessen Auswahl muss man allerdings auch bedenken, dass sich die Kunden den Gutschein selbst ausdrucken sollen. Also entweder eine Systemschrift wählen oder PDF mit eingebettetem Font generieren.

Von der Idee, den Wert des Gutscheins im Code zu kodieren, würde ich Abstand nehmen. Ich sehe darin keinen Mehrwert. Der Kunde weiß davon nichts, kann daher aus dem Code nicht den Wert ableiten. Sobald er es kann, z.B. weil er genügend Codes gesehen hat und das System erkannte, kann er den Code auch fälschen.

Die Anforderungen sind klar: Ein Code muss einen Datensatz in der DB eindeutig identifizieren und möglichst les- und sprechbar sein. Das ist ziemlich einfach. Mach es nicht komplizierter.

Für gute Lesbarkeit sollte übrigens kein Zeichen mehr als zweimal hintereinander vorkommen. Das habe ich in meinem ersten Beitrag ganz vergessen und es reduziert natürlich die Anzahl möglicher Codes.