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

Question

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

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

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

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

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

Answer 1

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

Из Википедия http://en.wikipedia.org/wiki/CRAM-MD5

Протокол

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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