Настройка веб-приложения для автоматического запуска аутентифицированных звонков по HTTP на удаленный веб-сайт без повторной аутентификации человека - PullRequest
0 голосов
/ 06 января 2011

Я хочу иметь возможность настроить веб-приложение для автоматической (т.е. при запуске cron) отправки запроса POST на удаленный веб-сайт.Удаленный веб-сайт требует, чтобы комбинация имени пользователя и пароля была отправлена ​​как часть данных POST.Я хочу, чтобы веб-приложение могло отправлять POST-запросы удаленного веб-сайта, не требуя от пользователя предоставлять пароль для отправки с данными POST каждый раз, когда выполняется запрос.

Мне кажется,что единственный способ сделать это - сохранить пароли непосредственно в базе данных, чтобы cron run мог выполнить запрос POST, включающий пароль как часть своих данных POST.Без сохранения пароля в какой-либо форме в базе данных представляется невозможным предоставить его в данных POST, если только пользователь не предоставляет его каждый раз при выполнении запроса.

Вопрос 1: Я ошибаюсь икак-то упускать из виду что-то логичное?Вопрос 2: Предполагая, что я должен хранить пароли в базе данных, какова самая безопасная процедура для этого?(MD5 и аналогичное одностороннее шифрование явно не будут работать, потому что я должен отправить незашифрованный пароль в запросе POST.)

Спасибо за вашу помощь!

Ответы [ 4 ]

1 голос
/ 06 января 2011

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

b.если вам нужно знать пароль - вам нужно сохранить его расшифрованным способом - следовательно - менее надежно.

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

d.если вы не защищаете деньги / ракетостроение, вам необходимо зашифровать пароль, сохранить его в БД и расшифровать его каждый раз перед использованием, по крайней мере, вы защищены от кражи БД.

e.убедитесь, что вы проходите аутентификацию по безопасному каналу (как https), чтобы пароль не отправлялся в виде открытого текста.

0 голосов
/ 16 января 2011

К счастью, Tumblr теперь реализует OAuth, который решает эту проблему.

0 голосов
/ 06 января 2011

Учитывая, что вы должны отправить пароль в виде открытого текста и делать это многократно без взаимодействия с пользователем, вам нужно будет сохранить и извлечь его из хранилища данных (файл / база данных / память).

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

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

Решите эту проблему, задокументируйте ее (это становится вашей политикой безопасности для приложения), а затем внедрите ее.

Безопасность - это только уровень сложности, который вы реализуете, чтобы уменьшить риск.

0 голосов
/ 06 января 2011

Одним из хороших решений, вероятно, является использование SSL (то есть HTTPS). Вы можете создать центр сертификации на стороне сервера, а затем попросить этот центр сертификации подписать сгенерированный вами сертификат клиента. Убедитесь, что сервер HTTP настроен на доверие к вновь созданному центру сертификации.

Как только это будет сделано, вы должны установить сертификат на стороне клиента. Клиент должен представить сертификат при разговоре с HTTP-сервером. Вы должны настроить HTTP-сервер так, чтобы при размещении на защищенных URL-адресах запрашивался доверенный сертификат.

Потрясающий пример того, как это сделать с Apache HTTPD, опубликован прямо здесь !

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

Это хорошее решение, потому что:

  • пароли не хранятся в открытом виде
  • если закрытый ключ сертификата клиента украден или скомпрометирован, вы можете отозвать его на стороне сервера

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

...