Software Registration Keys

Software is digital through and through, and yet there's one unavoidable aspect of software installation that remains thoroughly analog: entering the registration key.

This is a companion discussion topic for the original blog entry at:

Also, make it easy for us to move it to a different computer. Please. I’m going to get a new computer, if I have to re-buy your software, I’m going to go looking for something else.

If you do 5 textboxes, than make the focus automatically switch to the next box, once the box is full.

Also, is that Vista Key real? :stuck_out_tongue:

Quick! Is that an ‘O’ or an ‘0’? A ‘6’ or a ‘G’? An ‘I’ or an ‘l’? A
’B’ or an ‘8’? At least have the courtesy to scour your registration
key character set of those characters that are commonly mistaken for
other characters.

Slow down! What’s the rush? You paid hundreds of pounds for that software, and you only have to enter it once.

Keys are long so the ratio of correct to invalid keys is high, so you can’t just guess valid ones. That also explains “Tell me as soon as I’ve entered a bad value in the key”. That’s the last thing you want to do. Remember, the user is entering it once only. Entering 20 characters is no more taxing than entering 2 or 3 passwords.

We struggled for a long time with this when deciding how to license blendables. We ultimately went with a product key and activation model. While many people don’t like this idea of “activating” we knew that the ease of “sharing” would ultimately lead to abuse. We’re a new player in the space and we’re always looking to adjust the model but I do feel without ANY type of enforcement people would just “share” across an org.


“Tell me as soon as I’ve entered a bad value in the key. Why should I have to go back and pore over my entry to figure out which letter or number I’ve screwed up? You’re the computer, remember? This is what you’re good at.”

Doesn’t that make it easy to “guess” or figure out a key by trial and error? All you’d have to do is start with a character then keep typing characters until it says you messed up. Go back and change the last character until you get it right and then continue.

Hi, can I ask for clarification of your statement:

“I’ll choose biased data over no data whatsoever, every time.”

At first glance, that seems to me like a bad idea - at least with no data, you KNOW you don’t know anything, whilest with biased data, you can very possibly draw some very bad conclusions?

Other than that, I agree with your article (well, except for what Dave pointed out :-D).

Not only must the font be readable, it’s got to be BIG ENOUGH to read. I’ve had keys that I literally could not read without a magnifying glass.

“Tell me as soon as I’ve entered a bad value in the key. Why should I have to go back and pore over my entry to figure out which letter or number I’ve screwed up? You’re the computer, remember? This is what you’re good at.”

Let’s do the same with passwords! It’ll make it much less annoying.

Wait, I feel like there might be a problem with changing the difficulty of guessing from “Guess the whole key” to “Guess the next digit”.

Mr Brain not on yet today?

“Tell me as soon as I’ve entered a bad value in the key. Why should I have to go back and pore over my entry to figure out which letter or number I’ve screwed up? You’re the computer, remember? This is what you’re good at.”

This confuses me. Wouldn’t it be trivial for a human (even me) to continue to type in digits and/or letters until receiving an “All Clear”? Tedious, sure, but how long would it take you to make enough money to pay for 3ds max (which actually is a terrible example because it makes use of Autodesk’s ridiculously bad activation system AND a code, which can be any 10-digit number)

Also, how many of the 14 million possible representations of the 10-digit key are supposed to be valid? I’m sure it’s not just a big ol’ table of good ones that the installer is checking against, and rather is an algorithm of some kind, so even if the company sold, say, MinerVGA, the algorithm might accept 10 million or more.

Also also, I love the idea that on the older microsoft one, they have a barcode, presumably to ease entering the code, but the barcodes on the newer sticker are not relevant, and are just IDs. Points for not even bothering to obscure those. I think the Yellow MS one is probably Microsoft Bob and therefore no good to anyone anyway, am I right?

Er, obvious duplication while I penned my post, and also need to correct where it says “sold, say, 5 million copies of MinerVGA”

Ok,i think that’s the ‘don’t tell users when they enter a bad character’ angle covered now guys!

You seriously want it to tell you when you’ve messed up as soon as you hit a wrong key? Uhh yeah, that’ll make it hard to figure out a valid key. :slight_smile: Second of all, valid keys are based on THE WHOLE KEY (if the system is any good). You can’t tell if a key is valid until the whole thing is entered. So I assume anyway. I haven’t implemented such a system before.

Ditto what Tutko said. Telling you as soon as you’ve entered an invalid string makes it possible to heuristically figure out a key. Actually, it can get even worse- Write a program to enter the key into the textbox, detect dialog boxes indicating your invalid key, and use those to go back and try again. Then you can write a keygen without even understanding the algorithm that generates a correct key.
It also lets you cut down the keyspace exponentially- For example, alpha-numeric keys, which have 62 possible characters (26 + 26 + 10) , with a key of length 10, go from 62 ^ 10 to 62*10, since you only have to go through each character in each position in the sequence once.

I wish I could remember the name of the computer, but a few years ago in an OS class, our professor was discussing the fine art of Paging virtual memory, and told us about a bug on an old computer that would use Paging exceptions to guess the password- Basically it entered the password one character from the end of a “page”- If the password didn’t start with that character you got an “invalid password” messege- if it did, you got a “Paging Exception” first. Move the password 1 byte back in memory, and try again… and BAM- Password.

As far as “This key appears to be valid”- This happens a lot with shareware- They use a complicated algorithm to generate valid keys, put a giant number of generated keys in an online database, and then puts the algorithm IN THE SOFTWARE to check for those keys. “This Key appears to be valid” really means “This key meets the algorithm, but we might not have issued it to you.” It’s a second level of protection against keygens. I feel like this is valid, it falls under the same “necessary evil” clause that validation keys themselves do.

On the other hand, there’s such a thing as going too far. I read once about a disk scrubber that securely deleted files, but if you entered a key that ‘met the algorithm’ but didn’t match a key in the database, would only PRETEND to work. Another case was a popular CD burning program that would do the same thing, but churn out coaster after coaster and pretend the burn was successful. I don’t really approve of these tactics- A software developer that likes to play headgames with their customers is either too self-righteous or morally flexible for me to be comfortable running their code on my box.

“Where’s the #$%ing key?” - That’s the one that really resonated with me. I wish they’d put a second copy of the serial ON the disc- That way as long as we had the disc we could have a copy of the serial (for writing down elsewhere later on, obviously)- it doesn’t seem like there’s any way pirates could take advantage of this, nor could it make it more convenient for anyone to pirate- the backup serial solution is still completely analog.

Perhaps the best serial key I am yet to see was a really long one (512 characters). But instead of having to type it in, you simply double-clicked the key file and it worked. No chance of a typo.

Everyone knows the real reason Vista is pirated less is because people want it less. Duh.

“Unless you oppose the very concept of commercial software, there has to be some kind of enforcement in place.”

I’d be inclined to disagree, and willing to bet that just about everyone who’d be willing to pirate something in the first place isn’t going to be stopped by simple serial number validation, the only viable alternatives to which are ridiculously flawed/intrusive/whatever schemes like WGA that inconvenience everyone and drive the price of software even higher. The customer isn’t the enemy.

I wish more companies would take Apple’s stance – not only has the OS never required a serial, but the few apps of theirs that ever have are slowly but surely having the requirement removed (the latest version of Logic being the latest to come to mind). And it’s not because they’re a “hardware company.”

For BitBacker ( - my startup company, which is building super secure, Mac-only backup software), we were faced with a similar problem. We use 128-bit AES encryption, which means our keys are really long and annoying - 32 characters long when printed in hex. And not only do the users sometimes have to type them in, but they have to write them down on paper. (We can’t store the key on our servers because then we’d be able to read the user’s files; and we obviously can’t trust it to their hard drive because that’s what we’re backing up.)

So we generate these random 128-bit keys, but I found a pretty good way to present them to the user. We use RFC 1751, which defines a “Convention for Human-Readable 128-bit Keys” - basically just a mapping of bit blocks to strings of words. Here’s an example in Python (apologies if this gets mangled by Jeff’s blog software):

key = os.urandom(16) # Generate 16 random bytes (128 bits)
’a\xaa\xe4:^\x7f\xdbK\x86\xa4\x89{R\xa0\xdc' print bin_to_hex(key) # Print the key in hex (32 characters) 61aa60e43a5e7fdb4b86a4897b52a0dc y = RFC1751.key_to_english(key) y # The key in words - it's longer than the hex, but easier to read and write 'BUSY BARN RUB DOLE TAUT TOOK ALTO PRY KIT WALL MUG CURT' RFC1751.english_to_key(y) # The transformation is always reversible 'a\xaa\xe4:^\x7f\xdbK\x86\xa4\x89{R\xa0\xdc’

The keys are still very long, of course, and this is unavoidable for our application. But when translated to words, it’s easier to write them down or type them in without making a mistake. In BitBacker’s case, we actually make the user re-enter the generated pass phrase he wrote down, and pasting is disabled for that text box. This is quite annoying, but it’s a heck of a lot better than losing your pass phrase, which would make your backups inaccessible!

Despite its “128-bit” title, RFC 1751 works on arbitrary string lengths. Or at least, the implementation in the “pycrypto” library does.

The less annoying key I have seen so far looks like a block of ascii armored text, almost like if it is a security certificate. The key holds the name of the owner, the type of license and how many concurrent copies can run in the local subnet. To enter the license you simply copy the encrypted block of text and paste it into a box in the “about” menu.

I’m not going to comment on the obvious brain fart you had with that “tell me as soon as I make a mistake”, I’m sure with all the other comment’s you can figure out the difference between 3,656,158,440,062,976 different possibilities and 360 different possibilities.

What I do however not get is how you could put that Microsoft quote about stealing software there without at least a mention of the fact that the vast majority of the early Microsoft business has been due to stolen code, stolen features and stolen interfaces. DOS and Unix, anyone ?