"Sicherer" Gutscheincode

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • "Sicherer" Gutscheincode

    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...
    Ihr habt ein Torturial durchgearbeitet, das auf den mysql_-Funktionen aufbaut?
    Schön - etwas Geschichte kann ja nicht schaden.
    Aber jetzt seht euch bitte php.net/pdo oder php.net/mysqli bevor ihr beginnt!

  • #2
    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
    [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
    Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
    Super, danke!
    [/COLOR]

    Kommentar


    • #3
      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.
      Zuletzt geändert von onemorenerd; 22.01.2010, 18:37.

      Kommentar


      • #4
        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.
        [FONT="Helvetica"]twitter.com/unset[/FONT]

        Shitstorm Podcast – Wöchentliches Auskotzen

        Kommentar


        • #5
          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?
          Ihr habt ein Torturial durchgearbeitet, das auf den mysql_-Funktionen aufbaut?
          Schön - etwas Geschichte kann ja nicht schaden.
          Aber jetzt seht euch bitte php.net/pdo oder php.net/mysqli bevor ihr beginnt!

          Kommentar


          • #6
            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.)

            Kommentar


            • #7
              Zitat von TobiaZ Beitrag anzeigen
              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.
              Zitat von onemorenerd Beitrag anzeigen
              => 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?
              Zuletzt geändert von Quetschi; 22.01.2010, 20:54.
              Ihr habt ein Torturial durchgearbeitet, das auf den mysql_-Funktionen aufbaut?
              Schön - etwas Geschichte kann ja nicht schaden.
              Aber jetzt seht euch bitte php.net/pdo oder php.net/mysqli bevor ihr beginnt!

              Kommentar


              • #8
                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.

                Kommentar


                • #9
                  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.
                  Ihr habt ein Torturial durchgearbeitet, das auf den mysql_-Funktionen aufbaut?
                  Schön - etwas Geschichte kann ja nicht schaden.
                  Aber jetzt seht euch bitte php.net/pdo oder php.net/mysqli bevor ihr beginnt!

                  Kommentar


                  • #10
                    Zitat von Quetschi Beitrag anzeigen
                    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.
                    I don't believe in rebirth. Actually, I never did in my whole lives.

                    Kommentar


                    • #11
                      Im Osten sieht das alles natürlich vollkommen anders aus … SCNR
                      [FONT="Helvetica"]twitter.com/unset[/FONT]

                      Shitstorm Podcast – Wöchentliches Auskotzen

                      Kommentar


                      • #12
                        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.

                        Kommentar

                        Lädt...
                        X