3

serial number format:

  • 24 octets represented by 24 hex characters plus hyphens for readibility

  • e.g. D429-A7C5-9C15-8516-D15D-3A1C

    • 0-15: {email+master hash}
    • 16-19: {id}
    • 20-23: {timestamp}

email+master hash algorithm:

  • generate md5 hash of user's email (32 bytes)
  • generate md5 hash of undisclosed master key
  • xor these two hashes
  • remove odd bytes, reducing size to 16
  • e.g. D429A7C59C158516D15D3A1CB00488ED --> D2AC9181D531B08E

id:

  • initially 0x00000000, then incremented with each licence sold

timestamp:

  • timestamp generated when license is purchased

validation:

  • in order to register product, user must enter 1) email address and 2) serial number
  • generate email+master hash and verify that it matches 0-15 of serial
  • extract timestamp from serial and verify that it is < current timestamp and >= date first license is sold
bretttolbert
  • 984
  • 1
  • 9
  • 16

2 Answers2

3

I'm no expert on this, but there are a few things that might be problematic with this approach:

  1. Using MD5 doesn't seem like a good idea. MD5 has known security weaknesses and someone with enough time on their hands could easily come up with some sort of hash collision. Depending on how you use the serial number, someone could easily forge a serial number that looks like it matches some other serial number. Using something from the SHA family might prevent this.
  2. Your XOR of the user email hash with a master key isn't particularly secure - I could recover the hash of the master key easily by XORing the serial number with a hash of my own email.
  3. Dropping every odd byte out of a secure hash breaks the guarantee that the hash is secure. In particular, any hash function with a good security guarantee usually requires that all of the bytes in the resulting hash be there in the output. As an example, I could trivially construct a secure hash function from any existing secure hash function by taking the output of that first hash, interspersing 0s in-between all the old bytes, then outputting the result. It's secure because if you could break any of the security properties of my new hash, it would be equivalent to breaking security properties of the original hash. However, if you drop all the even-numbered bytes from the new hash, you get all zeros, which isn't at all secure.
  4. Is four bytes enough for the id? That only gives you 2^32 different ids.
templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
1

Some points to add to templatetypedef´s reply:

  1. If you must combine hashes for the email and your master key, hash the concatenation of both. Even better, hash email+key+id for even "better" security in case someone purchases two or more licenses and sees the pattern.

  2. Use a hash function that gives you only 16 bytes. If you must use MD5, any truncation is equally bad, so just take the first 16 bytes.

  3. Your id is never used in the validation.

  4. You will not be protected from key sharing (e.g. warez sites).

A serial number protects you from very few attacks. It´s probably not worth your time and effort.

Emilio Silva
  • 1,942
  • 14
  • 17