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


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

09.10.2020 12:59:19 Просмотров 21 Источник

У меня сейчас диллема ..

Я создаю приложение на VueJS и NodeJS .. и во время аутентификации мне нужно проверить, совпадают ли пароль и имя пользователя (очевидно).

Проблема в том, что я не хочу отправлять открытый текстовый пароль из FE (VueJS) в BE (NodeJS), но уже зашифрованный с помощью bcrypt

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

Как вы, ребята, решаете эту проблему?

У вопроса есть решение - Посмотреть?

Ответы - Как не отправить простой текстовый пароль, чтобы быть и все же проверить его / How to NOT send a plain-text password to BE and still verify it

Является ответом!
Asim Khan

09.10.2020 01:41:59

Это стандартная практика отправки паролей "открытым текстом" по протоколу HTTPS. Пароли в конечном счете не являются открытым текстом, так как связь клиент-сервер зашифрована в соответствии с TLS.

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

Maarten Bodewes

09.10.2020 02:09:03

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

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

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

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

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

Помочь в развитии проекта:
Закрыть X