Should I change my License Key output from pure md5 output to a common “XXXX-YYYY-ZZZZ” type code?

Question

I'm creating a simple license key system to "keep honest people honest". I don't care about especially stringent cryptography.

If they get to annoyed with the demo limitations, they go to my registration website, pay, and give me their email. I give them a license key.

I'm keeping things really simple, so:

license_key = md5(email + "Salt_String");

I have PHP and C# functions run that same algorithm and get the same key.

The problem is that the output of these functions is a 32-character string like:

A69761CF99316358D04771C5ECFCCDC5

Which is potentially hard to remember/type. Yes, I know about copy/paste, but I want to make it REALLY easy for all paying customers to unlock the software.

Should I somehow convert this long string into something shorter?

Lets say I use only the first 6 digits, so: A69761

There are obviously way more cryptographic collisions in that, but will it matter at all in practical use?

Any other ideas to make the thing more human readable/typeable?

Answer 1

To left 6-10 symbols will be enough - the user anyway will not be able to guess the code, and it would be easy to type in. Also good idea would be to register each license on your server, so that you will be able to check that user is really honest, and didn't give a license key to another person.

Answer 2

In my experience, asking the user to type or copy/paste a 30-character code indeed leads to frustrated customers. It's not that it's so difficult. It's simply a hurdle that people don't care for.

The solution I've used for my business is to have separate trial and purchased downloads. To get their licensed copy, the customer types in their email address and a short user ID on the download form. Entering only the email automatically resends the user ID. You didn't ask about this, but a system to automatically look up whatever code the customer needs is even more important than having a simple system. The download system looks up the user's details in the database and serves a SetupSomeProductCustomerName.exe that has the user's license embedded in it. This setup installs the customer's licensed copy without requiring any further identification or server connections.

This system has worked really well for us. The customer has only one file to back up and no serial numbers to lose to make sure they can reinstall the software in the future.

That said, if you prefer to use a system using a one-way hash, simply use an algorithm that generates a smaller hash. E.g. CRC-32 results in 8 hexadecimal digits.

There's no point in the hash being cryptographically secure. A cracker will simply walk through your code, copy the entire block of code that mutates the email address into the license key, and paste that into their keygen. Then they can generate license keys for any email address. They can do that regardless of how complex your hashing algorithm is.

If you want to prevent this, you need to use public key encryption, which results in keys that are far too long to type in. If you go that route, you'll either need to annoy your customers with long keys to paste in or separate key files, or use the personalized download system I described above.