Базовая аутентификация HTTP против секретного ключа

После создания довольно простого API я начал изучать аутентификацию, при которой базовая HTTP-аутентификация через SSL с использованием только комбинации имени пользователя и пароля может показаться слабой для того, кто ее использует, хотя различные обсуждения здесь предполагают, что это должно быть нормально.

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

Пример:

https://github.com/Arie/serveme/blob/master/spec/fixtures/vcr/HiperzServer/_restart/visits_the_Hiperz_restart_URL.yml

Как &api_key=hiperz_api_key&gs_id=3873 args предлагает дополнительную безопасность, помимо пароля имени пользователя? Я определенно хотел бы реализовать что-то более сильное, чем просто пользовательская / проходная базовая HTTP-аутентификация, и предоставить конечному пользователю какой-либо тип токена / ключа для использования для доступа, но я не вижу дополнительной силы в таких подходах.


authentication php api-key basic-authentication http-authentication
person David Anderson    schedule 11.09.2015    source источник
comment
Почему бы вместо этого не использовать дайджест-аутентификацию?   -  person Anthony    schedule 12.09.2015
comment
Я не встречал этого за все время чтения. Кажется, все предлагает хеши, ключи, секреты и т. Д. Для истинной безопасности аутентификации, от чего у меня кружится голова. Подходит ли дайджест больше, чем базовая аутентификация http?   -  person David Anderson    schedule 12.09.2015
comment
если вы хотите пройти аутентификацию в начале запроса, а не после установления SSL-соединения, то да, вам нужен дайджест.   -  person Anthony    schedule 12.09.2015
comment
@Anthony, я не думаю, что дайджест-аутентификация - действительно хорошая альтернатива. Он основан на устаревшем алгоритме хеширования (MD5) и по-прежнему требует, чтобы клиент знал имя пользователя и пароль.   -  person MvdD    schedule 13.09.2015

Ответы (3)


arrow_upward
0
arrow_downward

Обычная проверка подлинности не рекомендуется для защиты API, как я пытался объяснить в мой ответ здесь.

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

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

В любом случае, независимо от того, есть ли у вас доверенный клиент, например веб-приложение (живущее на защищенном сервере) или ненадежный клиент, например приложение JavaScript или мобильное приложение (живущее в сфере пользователя), схемы аутентификации на основе токенов (например, OAuth2) обеспечивают более безопасный способ защиты вашего API, чем обычная аутентификация. См. мой ответ здесь для получения дополнительной информации о различных способах получения токенов с помощью OAuth 2.0.

person MvdD    schedule 13.09.2015
comment
Большое спасибо за ответ, это многое прояснило. Разница между паролем и ключом была моей главной проблемой, когда то, как вы это объясняете, имеет гораздо больше смысла. - person David Anderson; 14.09.2015

arrow_upward
1
arrow_downward

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

person Abbas Baydoun    schedule 11.09.2015
comment
Хотя я, безусловно, ценю двухэтапную аутентификацию, я пытаюсь создать систему, которая не слишком сложна для пользователя. Воспроизведение этого из аналогичных решений было бы оптимальным, однако они используют ключи API, и я не вижу, чем это отличается от простого пароля. - person David Anderson; 12.09.2015

arrow_upward
0
arrow_downward

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

person Michael O Meara    schedule 11.09.2015
comment
Проблема в том, что я до сих пор не вижу разницы между ключом и паролем. Со всех сторон кажется, что это одно и то же, если только я чего-то не упускаю. - person David Anderson; 12.09.2015
comment
Вот моя интерпретация, пожалуйста, поправьте меня, если я ошибаюсь. Если вы используете свое имя пользователя и пароль для доступа к API, и если кто-то взломает запрос, они могут получить ваши полные данные для входа и полный доступ к вашей учетной записи. Используя ключи API, если хакер взломал запрос к API, у них будет только ключ API, который имеет ограниченную область действия и может быть легко вызван повторно. Можно создать ключи API, которые ограничивают доступ пользователя к API. - person Michael O Meara; 12.09.2015