Кодирование ключа продукта

Question

Хорошо, это вопрос о концепции кодирования.Я видел много вопросов о том, как реализовать ключ продукта, и я знаю, как это сделать, этот вопрос относится к тому, что, чем как.

Хорошо, вот предыстория того, что я делаю, и затеммой вопрос.Мое приложение Ultimate Diagnostic Suite готово к тестированию.Я хочу реализовать ключ продукта (я знаю, как это сделать).Я разрываюсь между тем, как это сделать.

Ключ продукта: 7FD8-S89D-8746G-HUSJ

Ключ продукта: example@example.com

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

Однако, если я воспользуюсь формой ключа продукта по электронной почте, и кто-то загрузит приложение, оно будет иметь цифровую подпись и пропустит этот файл ключа продукта на 1 миллион строк.У меня такой вопрос:

Если я воспользуюсь формой электронной почты (цифровая подпись), как бы я отсеял спам.Также я знаю, что у меня будет несколько событий для авторизации.Мне просто нужна отправная точка.Это для окончания после символа @, например:

У вас будет два текстовых поля, одно текстовое поле будет txtUser.Text, а другое для сравнения с текстовым файлом окончаний электронной почты будет txtEmailEndings.TextКороче говоря, если в письме есть окончание:

*@163.com 
*@aichyna.com 
*@berahe.info 



if (txtEmailEndings.Text == dbNotAllowed.Text)
{
  messagebox.Show("Please use a valid email, i.e, Gmail, Outlook, AOL");
}
else if (txtEmailEndings != dbNotAllowed.Text)
{
  // do something to allow access to full program
}

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

Единственный другой вариант, который у меня был бы, это фиксированная плата, которая вернулась бы к Flat Fee = Product Key.С нескончаемыми линиями Product Keys.Я не хочу иметь только один ключ продукта по той причине, что его можно использовать.

Это не в каком-либо конкретном приложении, таком как WinForms или WPF, концепцию можно использовать для обоих.Вот почему теги перечислены.

Любые вопросы или комментарии будут очень полезны.Я использую концепцию с цифровой подписью, как Microsoft перешла с ключей продукта на цифровые подписи.

Answer 1

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

Система децентрализована и будетБудьте склонны к утечке файлов лицензий пользователями, но при проверке обновлений вы можете отправить идентификатор машины в веб-интерфейс, и если вы обнаружите, что множество разных компьютеров используют один и тот же guid лицензии, вы помечаете лицензию как неактивную.

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

Посмотрите на этот проект: https://github.com/dnauck/Portable.Licensing/blob/develop/README.md

Вы можете защитить от спама электронные письма с помощью Recaptcha и проверки электронной почты.

Вы также можетевыдавать случайные ключи продукта, которые ваши API конвертируют в подписанный файл лицензии.Эти ключи имеют ограниченную активацию (хранятся на стороне сервера) и привязаны к идентификатору машины.