Jump to content

Shipping a DB that requires an activation key


EddyB
 Share

This topic is 6530 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 smile.gif

Ed

Link to comment
Share on other sites

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 wink.gif

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!!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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! smile.gif

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

Ed

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 6530 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.