Je remue-méninges pour un système de numéro de série. Est-ce que je fais mal?

Question

Format du numéro de série:

• 24 octets représenté par 24 hex caractères plus pour traits d'union readibility

• par exemple. D429-A7C5-9C15-8516-D15D-3A1C

  • 0-15: {email + hachage maître}
  • 16-19: {id}
  • 20-23: {} horodatage

email + algorithme de hachage maître:

• générer hachage md5 du mail de l'utilisateur (32 octets)
• générer hachage md5 de clé principale non divulguée
• XOR ces deux hash
• supprimer les octets impairs, réduction de la taille à 16
• par exemple. D429A7C59C158516D15D3A1CB00488ED -> D2AC9181D531B08E

id:

• d'abord 0x00000000, puis avec chaque licence incrémentée vendu

timestamp:

• horodatage généré lorsque la licence est achetée

Validation:

• pour enregistrer le produit, l'utilisateur doit entrer 1) adresse e-mail et 2) le numéro de série
• générer email + hachage maître et vérifiez qu'il correspond 0-15 de série
• horodatage extrait de série et vérifiez qu'il est = première date licence est vendu

Answer 1

Je ne suis pas expert en la matière, mais il y a quelques choses qui pourraient poser problème avec cette approche:

1. L'utilisation MD5 ne semble pas être une bonne idée. MD5 a connu des failles de sécurité et quelqu'un avec assez de temps sur leurs mains pourrait facilement arriver à une sorte de collision de hachage. Selon la façon dont vous utilisez le numéro de série, quelqu'un pourrait facilement forger un numéro de série qui ressemble à elle correspond à un autre numéro de série. En utilisant quelque chose de la famille SHA pourrait empêcher cela.
2. Votre XOR du hachage email de l'utilisateur avec une clé maîtresse est pas particulièrement sécurisé -. Je pouvais récupérer le hachage de la clé maître facilement par XOR le numéro de série avec un hachage de mon email
3. Dropping chaque octet intrus d'une pause de hachage sécurisée la garantie que le hachage est sécurisé. En particulier, toute fonction de hachage avec une bonne garantie de sécurité exige généralement que tous les octets dans le hachage là dans la sortie. À titre d'exemple, je pourrais trivialement construire une fonction de hachage sécurisée de toute fonction de hachage sécurisée existante en prenant la sortie de ce premier hachage, intercalant entre 0 dans tous les anciens octets, sortie le résultat. Il est sûr que si vous pouviez briser l'une des propriétés de sécurité de mon nouveau hachage, il serait équivalent à la rupture des propriétés de sécurité du hachage d'origine. Toutefois, si vous laissez tomber tous les octets paires du nouveau hachage, vous obtenez tous les zéros, ce qui est pas du tout sécurisé.
4. est-il suffisant quatre octets pour l'id? Cela ne vous donne 2 ^ 32 différents ids.

Answer 2

Quelques points à ajouter à templatetypedef's répondre:

1. Si vous devez combiner hash pour l'e-mail et votre clé maître, hachage la concaténation des deux. Mieux encore, email de hachage + id + touche même pour « mieux » la sécurité dans le cas où quelqu'un achète deux ou plusieurs licences et voit le motif.

2. Utilisez une fonction de hachage qui vous donne seulement 16 octets. Si vous devez utiliser MD5, troncature est tout aussi mauvais, donc il suffit de prendre les 16 premiers octets.

3. Votre identifiant est jamais utilisé dans la validation.

4. Vous ne sera pas protégé de partage des clés (par exemple des sites warez).

Un numéro de série vous protège des attaques très peu. D'une manière ne perdez pas votre temps et d'effort.