Должен ли я изменить вывод моего Лицензионного ключа с чистого вывода md5 на общий код типа "XXXX-YYYY-ZZZZ"?

Question

Я создаю простую систему лицензионных ключей, чтобы "держать честных людей честными". Меня не волнует особо строгая криптография.

Если их раздражают демо-ограничения, они идут на мой регистрационный сайт, платят и дают мне свою электронную почту. Я даю им лицензионный ключ.

Я держу вещи действительно простыми, поэтому:

license_key = md5(email + "Salt_String");

У меня PHP и C# функции запускают тот же алгоритм и получают один и тот же ключ.

Проблема в том, что выходные данные этих функций представляют собой строку из 32 символов, например:

A69761CF99316358D04771C5ECFCCDC5

Который потенциально трудно запомнить / напечатать. Да, я знаю о копировании / вставке, но я хочу, чтобы все платящие клиенты ДЕЙСТВИТЕЛЬНО легко разблокировали программное обеспечение.

Должен ли я как-то преобразовать эту длинную строку во что-то более короткое?

Допустим, я использую только первые 6 цифр, поэтому: A69761

Очевидно, в этом есть гораздо больше криптографических коллизий, но будет ли это вообще иметь значение при практическом использовании?

Любые другие идеи, чтобы сделать вещь более читабельной / печатной?

Answer 1

Слева будет 6-10 символов - пользователь в любом случае не сможет угадать код, и его будет легко набрать. Также хорошей идеей будет зарегистрировать каждую лицензию на вашем сервере, чтобы вы могли проверить, что пользователь действительно честен, и не дал лицензионный ключ другому человеку.

Answer 2

По моему опыту, запрос пользователя ввести или скопировать / вставить 30-символьный код действительно приводит к разочарованию клиентов. Это не так сложно. Это просто препятствие, о котором люди не заботятся.

Решение, которое я использовал для своего бизнеса, состоит в том, чтобы иметь отдельные пробные и купленные загрузки. Чтобы получить лицензированную копию, клиент вводит свой адрес электронной почты и короткий идентификатор пользователя в форме загрузки. При вводе только электронной почты автоматически отправляется идентификатор пользователя. Вы не спрашивали об этом, но система автоматического поиска кода, который нужен клиенту, даже важнее, чем простая система. Система загрузки ищет сведения о пользователе в базе данных и предоставляет файл SetupSomeProductCustomerName.exe, в который встроена лицензия пользователя. Эта установка устанавливает лицензионную копию клиента, не требуя дополнительной идентификации или подключения к серверу.

Эта система отлично сработала для нас. У клиента есть только один файл для резервного копирования и нет серийных номеров, которые можно было бы потерять, чтобы он мог переустановить программное обеспечение в будущем.

Тем не менее, если вы предпочитаете использовать систему, использующую односторонний хэш, просто используйте алгоритм, который генерирует меньший хэш. Например, CRC-32 дает 8 шестнадцатеричных цифр.

Нет никакого смысла в криптографической безопасности хэша. Взломщик просто пройдет по вашему коду, скопирует весь блок кода, который изменяет адрес электронной почты, в лицензионный ключ и вставит его в свой кейген. Затем они могут генерировать лицензионные ключи для любого адреса электронной почты. Они могут сделать это независимо от того, насколько сложен ваш алгоритм хеширования.

Если вы хотите предотвратить это, вам нужно использовать шифрование с открытым ключом, что приводит к слишком длинным ключам для ввода. Если вы идете по этому пути, вам нужно либо раздражать своих клиентов длинными ключами для вставки, либо отдельные ключевые файлы или используйте персонализированную систему загрузки, описанную выше.