Эмм, нет, это просто намёк на то, что пользователь мог ошибиться в написании логина.
Ну просто сайт не может определить, правильно ли юзер написал свой логин, так как он и определяет юзера по логину. И пароль он сравнивает с логином, а не наоборот, так что ему изначяльно всё равно, правильный ли у тебя пароль, или нет.
Подбирать логины по паролю менее оправдано, чем пароли по логину. А базу логинов как правило можно подбирать при регистрации, ловя "извините, данный логин уже занят"
Ну просто сайт не может определить, правильно ли юзер написал свой логин, так как он и определяет юзера по логину. И пароль он сравнивает с логином, а не наоборот, так что ему изначяльно всё равно, правильный ли у тебя пароль, или нет.
Подбирать логины по паролю менее оправдано, чем пароли по логину. А базу логинов как правило можно подбирать при регистрации, ловя "извините, данный логин уже занят"
Нет же, сначала можно отгадать логин, пока ошибка не сменится с "неправильный логин" на "неправильный пароль", а потом уже перебирать пароли из базы данных самых популярных паролей. Если логин неизвестен и ошибка не говорит, что у вас не так - логин или пароль - то это дополнительный уровень безопасности. Перебирать приходится на много порядков большое вариантов.
Ну обычно оправдывается введение этой фичи как раз против подбора пароля под логин. Да, часто через регистрацию можно и так чекнуть логин, но это не рассматривается в рамках этой задачи.
Вообще мимо. Уже очень давно проверка делается так: 1) получить из БД соль и хеш пароля для данного пользователя, 2) с этой солью захешировать пароль, 3) сравнить с хешем из базы.
Но даже без соли все равно элементарно проверить, что неверное - логин или пароль. Запрашивать надо хеш из БД, если вернулось 0 записей - ошибка в юзернейме, иначе надо сравнить хеш. Все так же один запрос к БД.
Но даже без соли все равно элементарно проверить, что неверное - логин или пароль. Запрашивать надо хеш из БД, если вернулось 0 записей - ошибка в юзернейме, иначе надо сравнить хеш. Все так же один запрос к БД.
Глупость. От того, что соль хранится в том же поле, что и хеш, как в bcrypt, ничего не меняется. Соль все также есть. И она все также передается на вход функции хеширования. Не получив ее из базы вы никак по пользовательскому паролю хеш не посчитаете, чтобы его использовать в запросе. Проверка, действительно делается одним запросом, ибо и хеш и соль можно получить за сразу, даже если они хранятся в разных полях. И никаких принципиальных проблем с проверкой на неправильный логин это не создает.
Как в старинном анекдоте, для порносайтов - да!
А по факту сайты отличаются по оформлению, поэтому спутать сильно сложнее, если это не фишинг, но там явно предупреждать не будут. А вот логины на достаточно крупных сайтах, особенно где бывают баны и набеги ботов - часто выбраны очень плотно.
Вполне логично и просто просить пользователя перепроверить введенные данные.
А по факту сайты отличаются по оформлению, поэтому спутать сильно сложнее, если это не фишинг, но там явно предупреждать не будут. А вот логины на достаточно крупных сайтах, особенно где бывают баны и набеги ботов - часто выбраны очень плотно.
Вполне логично и просто просить пользователя перепроверить введенные данные.
Сайт: Да.
Через гуглпочту зайди и все
И чаще всего такая мутора с паролями на сайтах,на которые максимум 2 раза зайдешь
Чтобы написать коммент, необходимо залогиниться
Отличный комментарий!