Как я могу использовать Delphi для создания визуального запроса / ответа для восстановления доступа к приложению?

Question

Я заинтересован в создании процесса типа "вызов / ответ" в Delphi.Сценарий таков...у нас есть 2 компьютера ... 1 принадлежит пользователю, а 1 - специалисту службы поддержки.

Пользователь заблокирован от определенной программы, и для того, чтобы получить доступ 1 раз, я хочу:

1. Пользователю должна быть представлена фраза вызова, такая как "28394LDJA9281DHQ" или какой-либо тип разумно уникального значения
2. Пользователь позвонит в службу поддержки и ознакомится с этим запросом (после того, как сотрудники службы поддержки подтвердят его личность).
3. Сотрудник службы поддержки введет это значение запроса в программу в своей системе, которая сгенерирует ответ, такой же уникальный, как и сам ответ, например "9232KLSDF92SD".
4. Пользователь вводит ответ, и программа определяет, является ли это допустимым ответом.
5. Если это так, пользователю предоставляется 1-кратный доступ к приложению.

Теперь, как это сделать - вот мой вопрос?У меня будет 2 приложения, которые будут нет иметь сетевой доступ друг к другу.Есть ли какие-либо функции в Windows, которые могут помочь мне с этой задачей?

Я считаю, что я могу использовать некоторые функциональные возможности внутри КриптоАПИ, но я действительно не уверен, с чего начать.Я был бы признателен за любую помощь, которую вы могли бы предложить.

Answer 1

Я бы реализую аутентификацию на основе на основе MD5.

От Википедия http://en.wikipedia.org/wiki/cram-md5.

Протокол

1. Задача: в аутентификации Cram-MD5 сервер сначала отправляет строку вызова клиенту.
2. Ответ: Клиент отвечает на имя пользователя, за которым следуют пространственный символ, а затем 16-байтовый дайджест в шестнадцатеричном обозначении. Дайджест представляет собой выход HMAC-MD5 с паролем пользователя в качестве секретного ключа и оригинальной проблемой сервера в качестве сообщения.
3. Сравнение: сервер использует тот же метод для вычисления ожидаемого ответа. Если данный ответ и ожидаемый ответ ответ, то аутентификация прошла успешно.

Это обеспечивает три важных типа безопасности.

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

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

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

Важно: у него есть некоторые недостатки, тщательно оценивайте, как они могут повлиять на вас.

Answer 2

Что касается стратегии вербального вызова / ответа:Мы использовали этот подход для лицензирования специализированного приложения на пяти тысячах рабочих станций по всему миру в течение более чем десяти лет.Наша команда поддержки назвала это "Коды запуска ракет" из-за его сходства с классическим процессом аутентификации при запуске ракет, который можно было увидеть в старых фильмах.

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

Ваша ситуация / контекст могут отличаться.Возможно, вы будете пользоваться им не так часто, как мы.Но вот несколько предложений:

1. Внимательно изучите длину и содержание кода:большинство пользователей (и сотрудников службы поддержки) возмущаются, набирая много символов.Многие пользователи - плохие машинистки.Подумайте, не является ли длинная строка, включающая знаки препинания и чувствительность к регистру, чрезмерно обременительной по сравнению с дополнительным уровнем безопасности.

2. После нескольких лет использования вербальной реализации вызова / ответа мы оставили ее на месте (в качестве запасного варианта), но добавили простую автоматизированную систему.Мы решили использовать FTP, а не более сложный веб-подход, так что нам не нужно было запускать какое-либо программное обеспечение на нашем внутреннем сервере (или иметь дело с нашим ИТ-персоналом!).

По сути, мы используем FTP-файлы для выполнения обмена, который ранее выполнялся по телефону.Сервер размещает файл на FTP-сервере, содержащий фразу запроса.Имя файла - это имя клиента.У наших сотрудников службы поддержки есть программа, которая автоматически создает этот файл на нашем ftp-сайте.

Наши сотрудники инструктируют клиента нажать горячую клавишу, которая считывает FTP-файл, аутентифицирует его и помещает файл ответа обратно на сервер.

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

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

Данные в файлах могут иметь те же ключи MD5, которые вы использовали бы устно, так что они настолько безопасны, насколько вам хотелось бы.

Слабым местом этой системы является то, что пользователь должен иметь доступ по FTP.Мы обнаружили, что большинство наших пользователей (все предприятия) имеют доступ к FTP.(Конечно, ваша клиентская база может и не ...) Если наше приложение в полевых условиях не может получить доступ к нашему FTP-сайту, оно четко сообщает о проблеме, чтобы наш клиент мог обратиться к своему ИТ-персоналу с просьбой открыть доступ.А пока мы просто возвращаемся к вербальным кодам.

Мы без проблем использовали простые ванильные инструменты Indy FTP.

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

Извините, если все это не имеет к вам отношения.Надеюсь, это вам немного поможет.