От подмены пароля на лету? От кроссдоменной атаки?

Или просто не хочешь передавать пароль в открытом виде

да ладно, чтобы не один не обеспечивал безопасность ??? Опасность только в подборе пароля по определённым критериям, если они открыто передаются в эндпоинт или они могут перехватываться: снифферами и прочими скриптами на серваке. Способов взлома, что касается перехвата и подбора пароля не мало. Так что просто я ищу базовую широко применимую практику, а точнее как обычно девы делают безопасную замену пароля, если ты просто хочешь создать форму на ангуляре, где ты вводишь пароль, повторяешь его ввод, сабмит этого и летит пароль или инфа о нём в бек, т.е. бек узнает как-то о пароле и кто его замену запрашивает, а не кто-то левый с улицы

Ты говоришь про сброс пароля?

Или именно про замену?

сброс пароля и есть замена. А точнее переписание одного на другой

в БД хранится хеш от него

а на серваке проверка пароля именно по хешу

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

некоторые говорят юзать подтокен для пароля( соль ), чтобы его передавать можно было в бек

больше ничего годного в гугле

Сброс пароля неавторизованным пользователем - восстановление.

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

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

От чего ты пытаешься защититься так и не ясно

понятно. Ну счас http пока. https ещё не настроен у меня.

Сертификаты поганые нужно внедрить

ааа если так тогда чисто восстановление

восстановление пароля

Юзер авторизован:
Принял пароль на беке, сделал хеш, посолил положил в бд.

Юзер неавторизован: сгенерил токен для восстановления, записал в базу вместе со временем(можно в него сразу записать чтобы не делать отдельное поле), отправил на почту ссылку с токеном.

блин. Я так и знал, что без проверки через БД не обойдётся

спасибо огромное