in reply to RFC: Algorithm::CouponCode

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

Replies are listed 'Best First'.
Re^2: RFC: Algorithm::CouponCode
by grantm (Parson) on Apr 28, 2011 at 01:01 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 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

        I'm sorry, I have read and re-read your comment but I don't understand what point you're trying to make. Perhaps you could rephrase it.

        It certainly sounds like I need to update the documentation of my module to discourage further misunderstandings.