нужно подтверждение о безопасности с https, jwt и bcrypt - PullRequest
0 голосов
/ 19 сентября 2019

У меня есть вопрос о безопасности в приложении для входа / аутентификации:

  • если я отправляю пароль через https он зашифрован моим публичным ключом?
  • , если этов случае, если я могу совершенно точно передать то, что я хочу, в моем запросе https, не боясь забот?Это хорошая практика?
  • на самом деле я использую JWT, как это, это нормально?:
    • пользователь дает имя пользователя и пароль
    • мой фронт отправляет https почтовый запрос с именем пользователя и паролем (простой текст)
    • моя спина проверяет, еслипользователь существует
    • , если это так, моя спина выдает bcrypt.compare пароль, заданный пользователем в виде простого текста, и зашифрованный пароль, указанный в db
    • , если все в порядке, моя спина отправляетjwt
  • простого перенаправления с http на https в моем виртуальном хосте достаточно, чтобы избежать передачи открытого текста?

1 Ответ

1 голос
/ 19 сентября 2019

HTTPS - это не серебряная пуля или, точнее, ее часть TLS, которая имеет отношение к вашему вопросу.

В том смысле, что его необходимо правильно настроить и развернуть.

Итак, если все правильно, то ДА, все, отправленное (или полученное по этому вопросу) через HTTPS, зашифровано, будь то пароль, токен, текст и т. Д. Не «вашим публичным ключом», поскольку все сложнее, чем это., но подведем итог: сертификаты используются в начале рукопожатия для обеспечения аутентификации, после чего некоторые ключи сеанса вычисляются и будут использоваться для шифрования любых обмененных данных.

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

Тогда кажется, что вы смешиваете безопасность в транспорте с безопасностью в покое: вы можете обменять пароль с HTTPS, он зашифрован во время транспортировки, отлично.Но когда он достигает удаленного конца, что делает с ним удаленный?Использует ли он его только для вычисления, а затем отбрасывает или хранит в другом месте?Если он должен хранить пароль, то вам нужна безопасность в состоянии покоя: способ сохранить пароль, чтобы даже если кому-то удастся получить к нему доступ, он не сможет вернуться к реальному текстовому паролю.То, как вы это сделаете, зависит от того, какой пароль используется, но если он нужен для классической аутентификации, на самом деле вы должны обратить внимание на bcrypt / scrypt / argon и в более общем плане то, что называется PBKDF2.Не слушайте людей, которые говорят, что вам просто нужно хешировать пароль, проблема больше, чем эта.

Что касается «простого перенаправления с http на https в моем виртуальном хосте, достаточно, чтобы избежать передачи открытого текста?», Вероятно,нет, но ваш вопрос не хватает деталей.Клиент должен отправить свой запрос, прежде чем узнает, что это перенаправление.Если в запросе уже была какая-то конфиденциальная информация в некоторой полезной нагрузке, то она будет отправлена ​​в виде простого текста, а затем снова может быть зашифрована позже при переключении на HTTPS.

Так что, очевидно, что-то делать не нужно.В настоящее время вы можете даже полностью отключить HTTP и просто прослушивать HTTPS, особенно если речь идет о трафике между приложениями, нет необходимости поддерживать прослушиватель HTTP.

...