Должен ли я изменить вывод моего Лицензионного ключа с чистого вывода 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 шестнадцатеричных цифр.

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

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