Какая-то мутная схема.
Если искать по хвидам есть вероятность что он совпадет для абсолютно рандомного компа, и тот сможет легко им пользоваться без аккаунта вовсе или его даже можно брутфорсить.
Сперва нужно находить аккаунт и только потом получать список подписок для пользователя и сравнивать его хвид (их может быть и несколько для одной подписки).
Такая схема при запросе точно подверждает владение данными для входа и право на лицензию.
Так же не вижу смысла делать какие-то несколько частей, если сервер одобряет выдачу длл то какой смысл во втором запросе, сервер и так должен пришить дллку к конкретному железу и времени, а затем выдать ее.
Про никто не сможет отправить запрос на скачивание вообще не ясно, если кто-то узнал хвид юзера так ему нахрен не нужно делать запросы у него есть доступ к целому пк.
Ну я в своем стиле, как обычно, не договариваю вещи до конца. Это да, система авторизации сама по себе предразумевается как стандарт и дефолт. Это первое, что должно происходить на клиенте. А потом идёт та логика, что я описал выше. Мы ищем записи по учетке + хвид, что б с другого ПК не смогли получить доступ. А по поводу рандомного совпадения вариант исключён, если хвид тянуть из многих компонентов комплектующих. Можно взять за основу MAC адрес и оперативную память. Оперативка вроде досих пор бывает несовместима с разными комплектами даже одного и тоже объема и производителя. Нужна именно одна серия и желательно в одной упаковке. Обычно хвид к диску привязывают, но я не знаю как там дела с ССД дисками обстоят, поэтому тут не могу ничего сказать.
По поводу двух запросов - это нужно делать для верификации клиента. Все проверки и генерацию доступа нужно делать на сервере, клиент получает токен лишь для верификации что не происходит подмены данных, он же этот токен должен будет вернуть обратно и сервер сверит эти данные ещё раз, тем самым констатируя факт реального запроса от клиента на сервер и обратно.
Опять же, тот же хвид можно попробовать установить спуфером в случае, если атака происходит с участием владельца акка и взломщиком, но это другая история.
Не знаю как объяснить, но токен должен выступать в качестве подписи, то бишь неизменность данных при пересылке с помощью перехвата данных. Поэтому токен генерируется на основе полученных данных ( логин, пароль, хвид и тд )
Главное не доверять данным клиента. И никаких важных проверок на уровне клиента не делать. От слова вообще. Что б даже лоадер с открытым исходным кодом мог полноценно выполнять свою функцию. Тогда это будет считаться хорошим и надёжным способом верификации.
