#c# #language-agnostic #encoding #cryptography
Вопрос:
Поэтому мне нужно сгенерировать код, который может быть привязан к конкретному пользователю/потенциальному клиенту со встроенной в него суммой в долларах. Он должен быть обратимым, чтобы клиентское приложение могло подтвердить действительность кода и применить скидку, которую намеревается предоставить менеджер.
Я бы хотел сделать код как можно короче, но он должен быть хорошо запутан, чтобы продавцы не могли начать возиться с ним самостоятельно.
Я могу придумать что-нибудь сам, перепрыгивая числа, деля на число пи и преобразуя в шестнадцатеричное число и все такое, но мне действительно были бы интересны идеи или лучшие практики сообщества.
Я делаю это на C#, но я ожидаю, что методы с любого языка могут быть переведены.
правка: для уточнения. Я не могу хранить все это заранее, коды должны быть созданы на лету и нести с собой всю информацию.
например, продавец 14 звонит по поводу клиента 773 и хочет дать им 500 долларов от их заказа. 14, 773 и 500 должны быть указаны в коде купона и могут быть извлечены в клиентском приложении после ввода продавцом ключей в коде.
Комментарии:
1. не могли бы вы уточнить здесь протокол? Похоже, у вас есть несколько сторон, продавец, клиент (клиент?) C, центральная база данных D и клиентское приложение A. Кто с кем разговаривает и в каком порядке, и какая сторона говорит какой другой стороне что? Без этого трудно ответить на ваш вопрос.
Ответ №1:
Создайте пару открытого/закрытого ключа для подписи. Подпишите цифровым способом комбинацию идентификатора пользователя и стоимости купона, используя закрытый ключ. Опубликуйте значение купона подпись в качестве кода купона, закодированного, например, с использованием букв и цифр. Клиентское приложение проверит код, воссоздав комбинацию данных, которые были первоначально подписаны (например, добавив идентификатор пользователя к значению купона), а затем подтвердив цифровую подпись.
Комментарии:
1. Примечание: вам все равно придется в торговых точках сообщать, какие купоны использовались довольно часто, чтобы свести к минимуму риск использования купона дважды.
2. Конечно, обеспечение того, чтобы код купона использовался только один раз, остается для читателя в качестве упражнения. Кроме того, подписанные данные должны содержать дополнительную информацию, чтобы можно было выдавать несколько купонов по одной и той же стоимости и для одной и той же комбинации клиент торговый представитель.
3. Для получения дополнительной информации, en.wikipedia.org/wiki/Public-key_cryptography и поиск в Google полезен.
4. Укажите номер заявки на продажу или POS, чтобы гарантировать действительность только на этом POS или по этой заявке на продажу. Укажите временной код, чтобы купон можно было ввести только в течение определенного периода времени.
5. Работает отлично, но имейте в виду, что коды будут довольно длинными.
Ответ №2:
Звучит как пример асимметричного шифрования. Вы могли бы выдать открытый ключ всем желающим, тем самым предоставив им информацию для проверки купона, но возможность создания купона будет зависеть от владельца закрытого ключа (= вас).
Я бы создал класс купона, который сериализуется в xml, а затем зашифровал строку xml. Проверка будет заключаться в расшифровке строки и проверке того, является ли она допустимым xml (я рекомендую не десериализовывать объект, не проверив это ранее).
Ответ №3:
Я бы использовал код клиента и дату истечения срока действия купона. Что касается проверки, вы можете просто сохранить действительные купоны в своей базе данных и проверить это. Вы можете сканировать таблицу купонов один раз в день, чтобы удалить просроченные коды.
Комментарии:
1. Есть страны (например, Швейцария), где по закону срок действия купонов никогда не истекает (хотя на купоне обычно указана дата истечения срока действия). Затем замените дату истечения срока действия датой выпуска.
2. Мне нравится этот ответ, потому что он предлагает хорошую альтернативу всем другим ответам, основанным на криптографии. Единственное, что следует отметить в этом решении, — это то, что вы не можете проверять коды купонов в автономном режиме.
3. Немного более чистое решение, приводящее к более коротким кодам купонов, состоит в том, чтобы генерировать совершенно случайные короткие идентификаторы купонов (например, длиной 8 буквенно-цифровых цифр), хранить их в базе данных вместе со всей соответствующей информацией о купоне, такой как идентификатор клиента, идентификатор представителя, стоимость купона, срок действия…
4. @Александр, ты прав, это было бы короче. С моим предлагаемым решением каждый код купона был бы уникальным, но это не является заявленной целью проблемы.
Ответ №4:
Насколько умны ваши продавцы (или женщины)? Не могли бы вы просто кодировать значение на базе 64?
Проверьте здесь, как кодировать и декодировать base64:
http://arcanecode.wordpress.com/2007/03/21/encoding-strings-to-base64-in-c/
Кроме этого, я бы зашифровал значение с помощью ключа, известного вам и клиентскому приложению.
Комментарии:
1. Временами они удивительно умны. особенно когда от этого зависит их комиссионные.
2. Тогда шифрование-это правильный путь, предложение Треба сработает.
Ответ №5:
Я предполагаю, что из того, как вы сформулировали вопрос, вы не хотите хранить коды в базе данных (если бы вы это сделали, вы могли бы просто проверить каждый код в базе данных)
Итак, что вы могли бы сделать, так это взять всю соответствующую информацию о том, что содержится в купоне, а затем хэшировать ее вместе с секретной солью, чтобы предотвратить подделку.
Таким образом, предположим, что вам нужен купон для пользователя 23 стоимостью 200 долларов, вы можете создать строку типа «23_200» и вычислить хэш MD5 с секретной солью «BillTheLizard», чтобы получить 2671519131e974ee6fc746151e98f4a8, таким образом, полный код, который вы даете клиенту, составляет 200_23_2671519131e974ee6fc746151e98f4a8
Теперь, когда вы получили код, вы разбираете его на части и проверяете, что md5(«200_23» секрет) = 2671519131e974ee6fc746151e98f4a8, чтобы проверить значение
Правка: Если 32-символьный хэш слишком длинный, вы всегда можете его обрезать, например, сокращение его до 8 символов все равно даст вам 4294967296 разных значений хэша.
Комментарии:
1. По моему опыту, (продавцы)люди пойдут на многое, чтобы вмешаться в такую систему ради личной выгоды. Например, они наймут кого-нибудь, чтобы узнать секрет соли из клиентского приложения. Асимметричная криптография в этом сценарии несколько более надежна.
2. MD5 уязвим для атак с расширением сообщений: существуют способы, с помощью которых продавец может изменить данные купона таким образом, чтобы не изменять результирующий хэш, чтобы он мог взять купон и создать другие аналогичные, которые все еще действительны. Безопасный способ сделать то, что вы предлагаете, — это использовать существующий метод проверки подлинности сообщений , а не создавать свой собственный. Одной из широко доступных возможностей является HMAC .
Ответ №6:
Стив Гибсон рассказывает о одноразовых паролях на своем веб-сайте, но нет причин, по которым вы не могли бы использовать его для создания одноразовых кодов купонов: http://grc.com/ppp
Ответ №7:
Это просто для того, чтобы подвести итог ответам на данный момент. Существует два основных различных способа генерации таких кодов купонов:
- Централизованное решение: информация о каждом купоне хранится в вашей базе данных. Затем код купона может быть сгенерирован случайным образом и коротким-это просто ссылка на запись в вашей базе данных, которая содержит всю необходимую информацию, такую как стоимость купона, идентификатор клиента, идентификатор представителя. Для проверки такого кода требуется онлайн-доступ к вашим серверам.
- Децентрализованное решение: купон представляет собой автономную часть информации, которую можно проверить в автономном режиме, без доступа к какому-либо из ваших серверов. В результате код купона должен содержать некоторую (или даже всю) информацию. Самый безопасный способ-использовать асимметричную криптографию или Код аутентификации сообщения, чтобы никто, кроме владельца закрытого ключа (вас), не мог генерировать купоны.