Слать при регистрации\авторизации в браузере хэш пароля это плохая мысль?

https вообще не безопасен, доверять левым дядям безопасность...

И всетаки мне ненравится идея отсылать на сервер пароль в plaintext.

Начнем с того что у вас, похоже, пароли и в базе плейнтекстом лежат, это так?

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

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

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

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

Не кажется

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

Может ограничение на количество попыток входа тогда рассмотреть как вариант

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

но вот есть ли в этом смысл?

Если клиент отправляет хэш, который вы солите и сравниваете с БД, то это то же самое, что и пароль плейнтекстом.

Вам нужно делать так - в БД лежит хэш с солью. На стороне пользователя форма логина также генерирует хэш с солью. Только сначала сервер передает какой-то «сессионный» хэш (то есть он разный всегда), пользователь добавляет к нему хэш своего пароля с солью и берет хэш полученной строки, и потом его отправляет на сервер. На сервере сравниваете пришедшие данные по тому же алгоритму (соленый хэш пароля у вас в базе, сессионный вы знаете), ну и в ответ возвращаете какой-нибудь сессионный токен. (Ехал хэш через хэш, ага). Таким образом перехватив данные от клиента не получится повторно их использовать. Плюс для сессионных данных добавляете проверку по айпишнику, юзерагенту или чего там еще придумаете, чтоб минимизировать возможность угона сессии.

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

И то что вы используете SSL это вообще само собой разумеется, это необходимо вообще во всех случаях без исключения.

И то что вы используете SSL это вообще само собой разумеется, это необходимо вообще во всех случаях без исключения.

поддержу. это нужно даже в том случае, если никакой авторизации на сайте вообще нет

поддержу. это нужно даже в том случае, если никакой авторизации на сайте вообще нет

А зачем? Вот зачем https на сайтах новостей, на anekdot.ru, даже на linux.org.ru без авторизации?

1. Из-за нечестивых провайдеров, например. Они могут вставлять рекламу и т. д.

2. Скорость. https://www.httpvshttps.com/

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

Прекрати страдать хернёй и шли текстом.

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

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

micronekodesu, Goury
всем спасибо!

Cleartext in TLS

за неуловимого Джо знаешь?