Как правильно хранить логин и пароль для использования с API?

Question

[ikutin]

Есть сервис, где пользователь регистрируется, у этого сервиса есть свои API, API привязываются к этому пользователю, по-этому при каждой отправки запроса требуется передавать логин и пароль в открытом виде, со стороны сервиса нет никакой доп защиты, как правильно хранить этот логин и пароль на стороне сервера?

Answer 1

[Иван Шумов]

Используйте openId с jwt токенами. И будет вам счастье. А что касается хранения то я бы посмотрел в сторону keycloak. Хранится все в шифрованном виде, но отдается нужному пользователю в нормальном

Comments

[abmanimenja]

Зачем так сложно?
OpenID - имеет смысл тогда, когда сервер аутентификации/авторизации - отдельное ПО.

[Иван Шумов]

abmanimenja, вообще не играет роли отдельное или нет. Можно вообще взять сервис такой как Auth0. Это не сложно, это куба проще, безопаснее и позволяет сосредоточиться на разработке фич, вместо прокрастинации

[abmanimenja]

вообще не играет роли

Ну как не играет?
Зачем вы предлагаете создавать ненужную сложность на пустом месте?

[ikutin]

это все подразумевает некую авторизацию, но авторизации так таковой нет, есть просто логин и пароль от его учетной записи
Ситуация: требуется разработать форму поиска для сайта, которой могут пользоваться все в частности не авторизированные пользователи, но все запросы API происходят используя логин и пароль хозяина сайта

[Иван Шумов]

abmanimenja, это не ненужная сложность и даже не сложность, а разделение ответственности. Не буду говорить про "а я что раз так делал", но все кто слушал этого совета остались только довольны

[Иван Шумов]

ikutin, вы путаете авторизацию и аутентификацию

[ikutin]

Иван Шумов, авторизация-это ввод логина и пароля
аутентификация-это определение кто вошел в систему вроде так, может я что то путаю
по сути мне наверно нужен второй вариант без авторизации

[Иван Шумов]

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

[ikutin]

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

[Иван Шумов]

ikutin, во-первых ssl, во-вторых OpenId/OAuth2 потому как они обеспечивают токен, который живёт ограниченое время. + Вы получаете отдельный сервис в котором проверяется логин и пароль. Подумайте про это внимательнее, посмотрите ролики и почитайте статьи. Да и вообще, "взломали сервер" это вообще другого уровня проблема

[Дмитрий]

ikutin, Если API ваш собственный, то просто уберите аутентификацию для поиска (раз уж он должен быть доступен для всех).

Answer 2

[abmanimenja]

Зачем там пароль и логин?
Достаточно токена.

Comments

[Иван Шумов]

Человек пока не умеет в токены)

[abmanimenja]

Иван Шумов, это же проще пароля

[Иван Шумов]

abmanimenja, нет) прочитайте про OAuth2, OpenId и все такое

[abmanimenja]

Иван Шумов,

нет) прочитайте про OAuth2, OpenId и все такое

По моему вам нужно почитать ликбез.

Токен - это проще пароля.

То о чем пишете вы - это целая система накрученная поверх идеи токенов.
Для данной задачи - это не нужно.

[Иван Шумов]

abmanimenja, вас стоит прочитать про безопасность и ротацию токенов

[abmanimenja]

Иван Шумов,

вас стоит прочитать про безопасность и ротацию токенов

а за свой счет готовы сделать эти ненужные работы?

зачем в простейший сервисах накручивать уровень безопасности "как в банке"?

[Иван Шумов]

abmanimenja, успехов вам так дальше и думать. Это не стоит ничего, кроме отдельной слабенькой виртуалки.

[abmanimenja]

Иван Шумов,

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

В смысле?
Вам за эту работу и платить не потребуется?

Вы, будучи джуном, еще не понимаете просто.

Ротация токенов нужна в заведомо недружелюбной среде.
Навроде веба.

Если обращение по API идет, скажем, из другой банковской системы - то токен может и годами жить.

[Иван Шумов]

abmanimenja, простите, мне надоело. В банковской среде другие правила игры и другие требования к безопасности. Там с этим все хорошо, но токены все-равно ротируются.

[abmanimenja]

Иван Шумов,

простите, мне надоело.

Ваши знания настолько поверхностны, что вы не способны вести дискуссию?
Видимо, вы понахватались верхушек знаний, но не понимаете еще о чем речь.
Учитесь, джун, учитесь.
В ИТ учатся вечно.

[abmanimenja]

Иван Шумов,

В банковской среде другие правила игры и другие требования к безопасности. Там с этим все хорошо, но токены все-равно ротируются.

Это называется "слышал звон, но не понял о чем он".
Перечитайте еще раз внимательно то, что вы рекомендовали - и об JWT и об oAuth.

Это для распределенной аутентификации/авторизации в недоверенной среде.
Когда сервер аутентификации/авторизации - отдельный.

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

Зачем делать распределенную систему если у тебя небольшой проект?
Ресурсы девать некуда?
Или ваше время бесплатно?

В единой неделимой среде - ничего это не нужно - ни oAuth, ни JWT

[Иван Шумов]

abmanimenja, проекты, которые так начинаются в будущем, при развитии, вынуждены быть переписанными. Зачем делать работу дважды?

[abmanimenja]

Иван Шумов,

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

Если взлетит высоко - перепишут.
Быть переписанным - это нормально. Позволяет подстроится под изменившиеся бизнес-процессы.

А вот если не взлетит (большинство, кстати)? Зачем вкладывать ненужные ресурсы времени разработчиков?

Бизнесу нужно здесь и сейчас.
Время = деньги.

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

[Иван Шумов]

abmanimenja, полтора часа времени на все про все это дорого, вы считаете?

[abmanimenja]

Иван Шумов,

полтора часа времени на все про все это дорого, вы считаете?

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

[Иван Шумов]

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

[abmanimenja]

Иван Шумов,

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

Если это решение нужно - то да.

Иначе - лишняя сложность, затраты на которую не заканчиваются установкой готового ПО сервера аутентификации/авторизации.

[Иван Шумов]

abmanimenja, 1:1. В принципе, оба правы. Мы оба не знаем что там за приложение и не в курсе о его будущем. Могут быть разные исходы, но человек поднял вопрос о безопасности, а это то что самостоятельно сделать куда дороже

Answer 3

[sim3x]

Как хранить пароли пользователей?