Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

RFC: Algorithm::CouponCode

by grantm (Parson)
on Apr 07, 2011 at 09:43 UTC ( #897992=CUFP: print w/ replies, xml ) Need Help??

I've been working on a tool for use in situations where a special code needs to be passed to a person in printed form (e.g.: account activation code in a letter to a customer; giveaway cards for WIFI access; etc) and then needs to be typed into a web form by the recipient.

The paper-to-web-form path provides a number of ways for errors to creep in and opportunities for us to autocorrect some errors, highlight others and avoid some errors altogether.

The fruits of my labours can be viewed on this demo page (requires JavaScript).

There's a Perl module for generating easy-to-type codes and validating/correcting/cleaning up the codes submitted. There's also a JavaScript plugin to do client-side validation, correction and instant feedback on mistyped codes.

Feedback is welcome on the concept, the implementation and anything else that you want to comment on.

Comment on RFC: Algorithm::CouponCode
Re: RFC: Algorithm::CouponCode
by jethro (Monsignor) on Apr 07, 2011 at 10:44 UTC

    Your demo is not working if javascript is turned off. I assume this is only a characteristic of your demo site. But you might check if your library works even when there is no javascript that for example adds those '-' characters

    UPDATE: Removed wrong statement

      Thanks for taking a look.

      Sorry, I should have mentioned that JavaScript is required for the demo. I've updated the link.

      In a live app, the JavaScript is optional and the backend validation routine doesn't care if you enter the '-' characters or not.

      I don't really get what you mean about the highlighting decreasing the security. If the box is red the user made a typo - the aim is to help the user. Having the box go green doesn't mean you typed the right thing it just means you typed one of the 32768 possible codes that would make that box go green.

      I haven't yet decided whether the green is useful. The red to indicate a keying error is kind of the whole point but the green is optional.

        Sorry, after I had read the more detailed description further down the webpage I realized my error. You saw my old post.

Re: RFC: Algorithm::CouponCode
by RMGir (Prior) on Apr 07, 2011 at 11:08 UTC
    Can you avoid 1's and O's (that's the letter oh) as well?

    It looks like you're not using I's and 0's (eyes and zeros :) ) but removing all the possible glyph confusions will probably help reduce errors, and it doesn't cost you that much of the space.

    I just read the "About Couponcode" tab - the autocorrect is a very nice feature, but it might be worth mentioning that feature on the front page, so the customer doesn't worry while reading the code...


    Mike
      After reading all the docs, I'm impressed. You've covered all the bases very nicely!

      I'd mention the auto-correction and the meaning of the green highlighting on the front page, to keep people from leaping to the same conclusions that jethro and I did.


      Mike

        Thanks - I've added a mention of the auto-correction on the front page of the demo.

        In a real application I'm not sure that I'd bother mentioning it. It would be nice if there was some easy way to reassure people that they didn't need to stress about upper/lower case and whether it's a '0' or an 'O' but that would take words and people don't read words.

Re: RFC: Algorithm::CouponCode
by chrestomanci (Priest) on Apr 07, 2011 at 11:44 UTC

    Very cool and most impressive.

    I am currently working on a project that will involve typing coupon codes into web forms using a mobile phone based browser, so the user will be able to type numbers much more easily than mixed numbers and letters.

    Could we have an extension or flag to your module for numeric only CouponCodes. (But still with the JavaScript based validation).

      I take your point about the ease of entering numbers on phones - although that may become less relevant as smart phones take over the world (on my low-end Android phone for example it's easier to enter letters rather than numbers in web forms).

      My CouponCode algorithm embodies a number of trade-offs. I went for a base-32 encoding scheme to increase information density while avoiding having to use upper and lower case characters. The checkdigit on each part then adds extra data entry overhead but hopefully the instant feedback benefits outweigh that.

      With a numbers only code, the base-10 encoding would significantly reduce the information density. So a 4-digit part could only encode a key-space of 1000 possible codes vs 32768 for my alphanumeric codes. To get the same keyspace as my three part codes (XXXX-XXXX-XXXX) a numeric-only code would need 5 parts (XXXX-XXXX-XXXX-XXXX-XXXX) which is probably a bit unweildy.

Re: RFC: Algorithm::CouponCode
by december (Pilgrim) on Apr 07, 2011 at 13:30 UTC

    Looks pretty solid to me. I'd make sure to test it without javascript before employing. I believe I've seen some OTP implementations floating around that generate word-like combinations, which might be a good idea if you want to use longer codes than that.

    I'm a bit disappointed you removed words like POOP though it's nuggets like these that make one's day.

      I'm a bit disappointed you removed words like POOP though it's nuggets like these that make one's day.

      To be honest, the only reason I included P00P in the list was so I had an inoffensive example I could use in the docs :-)

Re: RFC: Algorithm::CouponCode
by sundialsvc4 (Abbot) on Apr 07, 2011 at 15:39 UTC

    Nicely done.   I would also suggest of course that the range of characters used in the codes omit certain characters such as “Oh” and “El” and “Ess” so that substitutes zero, one, and five (respectively) can be automagically substituted.

    I would further suggest that the text be as large as you can make it, and that the difference between acceptable and unacceptable responses be more than “red and green.”   My dad, and a couple of my aunts(!), could not tell the difference between the two colors.   (They drove into one town where the traffic lights were inexplicably mounted upside-down and almost had a wreck.   The same thing happened when the lights were mounted sideways.   Clues such as texture, or a background difference such as a red “X” vs. a green “check-mark,” are also helpful.

      Unless I misunderstand your first paragraph, I am already doing that.

      The issue you raise with the accessibility issues for Red/Green is a very good point. I might experiment with your cross/check-mark suggestion.

      Thanks

      There is some difference between accepted and rejected parts apart from the color: if the part of the code is accepted, the javascript automatically selects the next input field, and the code you just entered is uppercased and "O" is changed to "0". Still, some other indication for a mistyped part might not hurt.
      I finally got time to look at the whole red/green visual feedback issue. The new version has updated Javascript+CSS to include a tick/cross icons as per your suggestion - thanks.
Re: RFC: Algorithm::CouponCode
by Mr. Muskrat (Abbot) on Apr 08, 2011 at 18:45 UTC

    Since you are using JavaScipt, I recommend that you allow people to paste a complete code into the first blank. So pasting 'ti3pzlmpeobs' would get changed into the three blanks filled out with 'TI3P', 'ZLMP' and 'EOBS' respectively.

      That's a good suggestion. It is on my ToDo list but hasn't been a high priority since I'm focussed on the "transcribe from print" scenario. Thanks.
Re: RFC: Algorithm::CouponCode
by roho (Monsignor) on Apr 09, 2011 at 14:30 UTC
    Good job! I noticed on the demo page my cursor did not automatically advance after entering four characters in the second box (I'm using IE 8 with JavaScript enabled). I had to press tab to advance or click in the last box. Also, the first box does not turn red after the first character is entered, like the other boxes do.

    "Its not how hard you work, its how much you get done."

      It turns out that my Javascript was not properly aligned with the focus change events generated by IE. The input boxes should not have been going red or green until all 4 characters had been entered - that bug should be fixed now. I wasn't able to reproduce your problem with the cursor failing to auto-advance from the second box. Thanks for the feedback.

Re: RFC: Algorithm::CouponCode
by SimonClinch (Chaplain) on Apr 26, 2011 at 12:23 UTC
    Whereas you don't publish the divisors and remainders used to check each field, the fact that a correct field is highlighted in green on completion means that the experimentation required to crack these values is very light. It takes less than half an hour to crack the whole system. I would force the user to finish entering all 12 characters before giving the green (or red) light.

    I suggest also changeing the divisors and remainders when you have secured the system.

    One world, one people

      Whereas you don't publish the divisors and remainders used to check each field, the fact that a correct field is highlighted in green on completion means that the experimentation required to crack these values is very light. It takes less than half an hour to crack the whole system. I would force the user to finish entering all 12 characters before giving the green (or red) light.

      I think you misunderstand my intent with this coding scheme. The fact that it's trivially easy for someone to generate a "well formed" code (i.e.: a code that makes all the boxes go green) is irrelevant. An organisation using this system would generate a code and then a) store it in their database and b) send it to their customer. Ultimately the only thing that matters is that the customer enters a code which is in the database.

      The main purpose of the coloured highlighting is to alert the user that they have entered a sequence of characters which cannot possibly be part of a valid code. The client-side implementation might only use the red highlight (meaning "definitely wrong") and not bother with the green (meaning "possibly right").

      An 'attacker' could definitely generate random codes and calculate valid checksums for them so that all the boxes were green (or at least not red); but that would do them no good because the chances of generating a code which happens to be in the database are slim (there are about 35 trillion possible 3-part codes).

      I suggest also changeing the divisors and remainders when you have secured the system.

      That sounds like an attempt at "security through obscurity". Which of course is doomed to fail since the client-side Javascript routines would need to know the correct values.

        That sounds like an attempt at "security through obscurity"

        I am not theorising here - you have unwittingly compromised an existing government system - what algorithm I personally would use is neither offered nor relevant - it is more important to understand the impact of leaving it as is.

        One world, one people

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: CUFP [id://897992]
Approved by Arunbear
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-09-23 07:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (210 votes), past polls