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

Question

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

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

Я держать вещи очень просто, так:

license_key = md5(email + "Salt_String"); 

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

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

A69761CF99316358D04771C5ECFCCDC5 

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

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