Shipping a DB that requires an activation key

[EddyB]

Hi all,

I'm after a few ideas on how to go about creating an activation key in FM.

I've no problem with expiring the DB after 30 days if no key has been provided by the user. My problem is how to check a key is valid.

The only solution I can think of at the moment is to "hide" in the solution a list of thousands of keys, when a user enters a key, it checks it against the "hidden" list for verification that it is a legitimate key.

There really has to be an easier way than this! How do activation keys work in off-the-shelf software? I presume by some complex calculation that takes place when you enter the key, is this the way I should be heading?

Many thanks for your thoughts and ideas

Cheers

Ed

[stanley]

Eddy:

I once saw a FileMaker database that would check to see if a credit card number was valid, without going online. Apparently all the big credit card companies use a calculation to create/validate their numbers. I don't think I bothered to keep it, but if I find it, I'll post the calculation...

-Stanley

[EddyB]

Hi Stanley,

Thanks for your reply. I had to write in credit card validation to a solution that I provided so I had to research all the algorithms etc. I think I still have this info somewhere so I could problably work off that to come up with a suitable algorithm.

Just needed a push in some direction, my mind was blank on this one! Cheers Stanley

[EddyB]

OK, just for info, in case anyone ever needs to do this, here are the rules for the major credit card validations.

Obviously this does not authorise credit card payments, but it checks the number on a credit card is correct, before sending the details off to be authorised.

The first things to check are prefix and the length of the number...

Mastercard - Prefix: 51-55 - Length: 16

Visa - Prefix: 4 - Length: 13,16

Amex - Prefix: 34,37 - Length: 15

Diners Club/Carte Blanche - Prefix: 300-305,36,38 - Length: 14

Now the algorithm - all these cards use the mod10 check-digit algorithm

STEP 1

Double the value of alternate digits of the card number beginning with the second digit from the right

STEP 2

Add the individual digits comprising the products obtained in Step 1 to each of the unaffected digits in the original number

STEP 3

The total obtained in Step 2 must be a number ending in zero (30, 40, 50, etc) for the account number to be validated

For example:

To validate the card number 49927398716:

Double every alternate digit starting with the second from the right (the 1 in this case)

4 9 9 2 7 3 9 8 7 1 6

1x2 =2

8x2 =16

3x2 =6

2x2 =4

9x2 =18

------------------------

Step 2: 4+(1+8)+9+(4)+7+(6)+9+(1+6)+7+(2)+6

Step 3: Sum = 70 : Card number is validated

Card is validated because the 70/10 yields no remainder

This may be total useless information, but someone may need it one day

Ed

[EddyB]

OK this is proving quite hard, or maybe it's just late (nearly 1am and still working on this!)

I can easily write the validation formula into a solution once I have decided on my algorithm. But actually reversing this and coming up with a key based on that algorithm is quite tricky. I suppose once I sit down in the light of day this will come to me. In the meantime if anyone has anymore pointers/ideas, I'd be very grateful for your wisdom

For this example whilst I get my head round things I'm using this algorithm:

Length is always 16

The 4th digit is always 7

Then the algorithm continues as in the credit card explanation above (multiply every 2nd digit by 2 starting with the 2nd digit from the right... add up all the values as explained above, result must be divisible by 10)

How on earth do you come up with a serial key from this! Or more to the point hundreds of serial keys, all unique!!

[stanley]

Eddy:

I kind of thought I'd be opening a can of worms with my suggestion; it sounds fairly straightforward at first, but after three seconds it clearly turns into a miasma...

Okay, because every other digit is garbage, you could randomize those (odd) digits. Then, you could come up with packages of digits which arrive at the right mod-10 check-digit solution. For example, the set: 2,5,1,8,1,6,3,4 does the job. If you had, say, twenty of these packages, I'd think you could set a script to run through them, with the other digits randomised, and you'd come up with as many combinations as you'd want, all of which would work... You could overdo it (make fifty thousand, say) and then run a script to check for uniqueness...

I'm sure I have probably missed something obvious, but it's a start.

-Stanley

[Fenton]

I don't know that you need to worry about the algorithm for validating credit cards for getting your validation ID. It's kind of different thing.

From what I've seen, you just make something up, using the various calculation functions of Filemaker. You could base it off the credit card. That's a good way to do it. But you want letters as well, and you don't want it to resemble the credit card# in any way.

The Choose() function, loaded with the alphabet, will give you a letter. Yeah, it's tedious to use a function for each letter/number, but that's the way.

You must absolutely guard the final calculation with your life; not only so you can deal out IDs, but so you can restore an ID to a legitimate customer if they lose theirs (if that's possible).

Here's a kind of flakey one I pulled out. It's using the Date to build an ID:

(Mod(Date_, Day(Date_)) + 1) * WeekofYear(Date_) &

Choose( Int(WeekofYear(Date_)/2) -1, " A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z") & Middle("ABCDEFGHIJKLMNOPQRSTUVWXYZ", Abs(Int(WeekofYear(Date_)/2) - DayofWeek(Date)_), 1)

Which produces, for today: "10EC"

You'd need more, but basically Mod, Choose and Middle are your tools, with Left and Right used sparingly. It doesn't really matter what the calculation is, as long as it produces something that can't be easily reverse engineered, and you don't lose it.

[EddyB]

Hi Stanley,

Thanks for helping out on this one!

I'm a bit confused though as the "odd" numbers are not garbage, they are used in step 2 of the formula - they are added to the individual digits obtained from multiplying the other digits by 2. These numbers could not then be randomised as the result of the multiplied numbers added to the random numbers does not guarantee a result that is divisible by 10. I thought you had it there for a minute though!

AAGGHHHH I think I may be going insane! I tried sleeping but I have algorithms flying around in my head! At least I'll appreciate the work that's gone into creating a serial number next time I purchase software!

Hmmm, maybe a Jack Daniels or 2 may help...

Ed

[stanley]

I agree with Fenton about using letters, but I think you want to lock your codes down in a database before you start distributing them, for precisely the reason Fenton gave - so you can restore a number to a legit user... The problem with using a date calculation (cool as it is) is that then part of the validation number is going to depend on the day you're entering the code, in which case someone out there will figure out that part of your code is a variable - also then you couldn't hard-store the codes because they'd constantly change...

-Stanley

[stanley]

Eddy:

Quite right, I skipped part of the validation when reading it (I'm on my eleventh straight hour staring at the machine, so going a bit loopy over here) and thus thought only every other digit was part of the actual validation.

However, that's the credit card example. You COULD skip every other, and only base your validation on half the actual data. In a sense, while it would make the codes LOOK more random, it actually would make them more hackable by someone randomising, because there's half as many digits to guess right (if I'm making any kind of grammatical sense there.)

I saw some really straightforward algorithms for precisely this purpose on a RealBasic CD a year or two ago - if I can dig that disc up, I'll see if I can find the right files...

-Stanley

[EddyB]

Thanks for your posts guys, I think things are getting a bit clearer, I'll probably wake in the middle of the night with the algorithm I want!

Just one question though on the formula Fenton gave, this would most certainly give me a key, but what calculation would be needed in the database to validate the key I had generated for the user?

Cheers

Ed.

[andygaunt]

I have an idea

http://www.nightwing.com.au/FileMaker/KeyCodeMaker/

Yes you have to buy it, but it is very much worth it.

[Fenton]

To answer a couple questions on my calculation. I just happened to use the date. If you had a credit card number, you could use that. The rest of the calculation should be whatever you need to scramble it, using mostly Middle and Choose, Substitute, whatever.

And yes, you'd have to have the same calculation in the file the user was using, for it validate it. So, if you were giving them total access, they could conceivably take the calculation and use it to figure out someone else's serial code. Not very likey.

[EddyB]

Thanks for all your suggestions. I think I am going to take the easy way out on this one and go with KeyCodeMaker. Not just because it's the easy way out, but because it's a hell of good program that Ray has produced here. Andy, I agree with you it looks like it is going to be worth every penny, thanks for drawing my attention to it.

Cheers all

Ed.

[BobWeaver]

One thing that you have to be careful about with credit card validation algorithms is that if they only have a single check digit, the user only has to try 10 different ones before finding one that will work. I posted a sample file a while back that uses a one-way hash to implement a custom login. You could use a variation of that for your authentication. I think that' s what Ray's software does as well. His is quite a bit more complete than what I posted.

http://www.fmforums.com/threads/showflat.php/Cat/0/Number/68165/page/4/view/collapsed/sb/5/o/all/fpart/1

I kinda hate to dredge this link up, because I got into a snarling cat fight with mse, and Djukic Goran hacked a couple of the first versions, but I think the final version that I posted was reasonably secure.

[EddyB]

Hi Bob,

Thanks for the link, that's a very interesting read. I've downloaded your attachment and I'm going to got through this and look if I can use this to implement the key system.

It's going to take me some time to get my head around it all though, I'm no mathmatician!

Thank again

Best regards

Ed