Добрый вечер всем. Вопрос : 1. Я от фронта принимаю пароль

при аутентификации, хеширую в sha256 и записываю хеш в базу, отдаю пару jwt
2. Возник вопрос: а с фронта пароль в чем приходит? Какая практика считается "стандартной" ?

если делаете сами: 1) при авторизации пользователь на своей стороне хеширует пароль солью, и через асимитричное шифрование (простого rsa хватит) передает хэш+соль на сервер 2) сервер сохраняет соль + хэш в базу, при этом не зная совершенно, какой был реальный пароль, да это в общем то и не нужно. 3) при авторизации, сервер шлет клиенту сессионную соль, которую оба будут использовать, клиент повторно хеширует свой хеш, с сессионной солью и отправляет на сервер в открытом виде 4) сервер делает то же самое и сверяется. итог: mitm невозможен априори, если обезопасить открытый ключ, и клиент и сервер оба могут чекнуть пароль, даже его никогда не увидев.

Мы авторизуемся с помощью jwt

а какая разница, если все равно пароль надо передавать? у вас по ключу или по паролю аутентификация проходит?

по паролю, https

scrypt/bcrypt. Не используйте голые хэши

этими либами и хеширую

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

Это не либы, а алгоритмы

кто его перехватит?

тот же вопрос

если использовать хеш без соли, то можно просто хеш передавать серверу и им авторизовываться

еще раз, кто перехватит плейнтекст пароль через https?

вариантов всего два: 1. на сервере хранится хеш, пароль ходит в открытом виде (по шифрованному каналу, если не тупить) 2. пароль ходит хешированным (digest-аутентификация). проблема в том, что хранить его тогда надо в открытом виде

Благодарю.

эмммм, скам-прокси? я сам так делал и не раз)

Внутренний нарушитель

внутреннему нарушителю пароль не нужен

приведете кейс? я не понимаю просто

какой скам прокси?

Зависит от доступов. Возможно он может только снифать трафик, но не имеет доступа на сервер

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

ну чушь же.

> подмена сертификатов на вай-фай точке > подмена сертификатов на устройстве че

Проще тогда на редирект и забрать пароль, а потом трафик скопировать

вот так вот можно и другими способами, но я других не видел

и что это даст? вариантов, повторю, два или пароль ходит в открытом виде, или он хранится на сервере в открытом виде

так стоп, мы кажется о разном говорим: а почему на сервере нельзя хранить не сам пароль "some_password" а его хеш "51348ab117bad55f0ea40090f07acfa3"?

можно, но, чтобы проверить такой пароль, его придется прислать на сервер в открытом виде

второй вариант выглядит как единая точка теоритического глобального краха)))

неправда.

нет, правда. можете попробовать доказать обратное, рапсписав алгоритм

но я же расписал...

....